<p>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.</p>
<p>Following <code>Deployment</code> manifest is used to deploy. But in this configuration one pod is receiving the traffic. But all of them queries db and performing actions.</p>
<pre><code>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
</code></pre>
<p>Here <code>mako</code> 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.</p>

Sachith Muhandiram
<h1>Availability</h1>
<p>Different levels of availability can be achieved in Kubernetes, it all depends on your requirements.</p>
<p>Your use case seem to be that only one replica should be active at the time to the database.</p>
<h2>Single Replica</h2>
<p>Even if you use a single replica in a Kubernetes Deployment or StatefulSet, it is regularly probed, using your declared LivenessProbe and ReadinessProbe.</p>
<p>If your app does not respond on LivenessProbe, a new pod will be created immediately.</p>
<h2>Multiple replicas using Leader election</h2>
<p>Since only one replica at a time should have an active connection to your database, a <em>leader election</em> solution is viable.</p>
<p>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.</p>
<p>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).</p>
<h2>Conclusion</h2>
<p>There is not much difference between a <em>single replica</em> Deployment and a <em>multi replica</em> Deployment using <em>leader election</em>. There might be small differences in the time a failover takes.</p>
<p>For a <em>single replica</em> solution, you might consider using a StatefulSet instead of a Deployment due to different behavior when a node becomes unreachable.</p>
