Sachith Muhandiram
Sachith Muhandiram

Reputation: 2972

Single working pod from replica set in Kubernetes

We have a service which queries database records periodically. For HA we want to have replicas. But with replicas all of then queries the database records.

Following Deployment manifest is used to deploy. But in this configuration one pod is receiving the traffic. But all of them queries db and performing actions.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: db-queries 
  namespace: default
spec:
  replicas: 3
  selector:
    matchLabels:
      app: db-queries 
  template:
    metadata:
      labels:
        app: db-queries
        version: v1 
    spec:
      serviceAccountName: leader-election-test
      containers:
      - name: db-queries
        image: our-registry:5000/db-queries
        imagePullPolicy: Always
        ports:
        - containerPort: 8090
        volumeMounts:
          - readOnly: true
            mountPath: /path/to/config
            name: config-files
      - name: mako
        image: gcr.io/google_containers/leader-elector:0.4
        imagePullPolicy: Always
        args:
        -  --election=sample

Here mako container shows only one pod is working as leader holding the lock. We simply want only one pod to query database record and other two stay ideal.

Upvotes: 0

Views: 1685

Answers (1)

Jonas
Jonas

Reputation: 128797

Availability

Different levels of availability can be achieved in Kubernetes, it all depends on your requirements.

Your use case seem to be that only one replica should be active at the time to the database.

Single Replica

Even if you use a single replica in a Kubernetes Deployment or StatefulSet, it is regularly probed, using your declared LivenessProbe and ReadinessProbe.

If your app does not respond on LivenessProbe, a new pod will be created immediately.

Multiple replicas using Leader election

Since only one replica at a time should have an active connection to your database, a leader election solution is viable.

The passive replicas, that currently does not have the lock, should regularly try to get the lock - so that they get active in case the old active pod has died. How this is done depend on the implementation and configuration.

If you want that only the active Pod in a multiplie replica solution should query the database, the app must first check if it has the lock (e.g. is the active instance).

Conclusion

There is not much difference between a single replica Deployment and a multi replica Deployment using leader election. There might be small differences in the time a failover takes.

For a single replica solution, you might consider using a StatefulSet instead of a Deployment due to different behavior when a node becomes unreachable.

Upvotes: 3

Related Questions