<p>I have a kubernetes cluster of 3 worker nodes where  I need to deploy a <code>statefulset</code> app having 6 replicas.
My requirement is to make sure in every case, each node should get exactly 2 pods out of 6 replicas. Basically,</p>
<pre><code>node1 - 2 pods of app
node2 - 2 pods of app
node3 - 2 pods of app
========================
Total   6 pods of app        
</code></pre>
<p>Any help would be appreciated!</p>

Nish
<p>You should use <a href="https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity" rel="nofollow noreferrer">Pod Anti-Affinity</a> to make sure that the pods are <strong>spread to different nodes</strong>.</p>
<p>Since you will have more than one pod on the nodes, use <code>preferredDuringSchedulingIgnoredDuringExecution</code></p>
<p>example when the app has the label <code>app: mydb</code> (use what fits your case):</p>
<pre><code>    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: app
              operator: In
              values:
              - mydb
          topologyKey: &quot;kubernetes.io/hostname&quot;
</code></pre>
<blockquote>
<p>each node should get exactly 2 pods out of 6 replicas</p>
</blockquote>
<p>Try to not think that the pods are pinned to certain node. The idea with Kubernetes workload is that the workload is independent of the underlying infrastructure such as nodes. What you really want - I assume - is to spread the pods to increase availability - e.g. if one nodes goes down, your system should still be available.</p>
<p>If you are running at a cloud provider, you should probably design the anti-affinity such that the pods are scheduled to different Availability Zones and not only to different Nodes - but it requires that your cluster is deployed in a Region (consisting of multiple Availability Zones).</p>
<h2>Spread pods across Availability Zones</h2>
<blockquote>
<p>After even distribution, all 3 nodes (scattered over three zones ) will have 2 pods. That is ok. The hard requirement is if 1 node ( Say node-1) goes down, then it's 2 pods, need not be re-scheduled again on other nodes. When the node-1 is restored, then those 2 pods now will be scheduled back on it. So, we can say, all 3 pair of pods have different node/zone affinity. Any idea around this?</p>
</blockquote>
<p>This <em>can</em> be done with <code>PodAffinity</code>, but is more likely done using <a href="https://kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/" rel="nofollow noreferrer">TopologySpreadConstraints</a> and you will probably use <code>topologyKey: topology.kubernetes.io/zone</code> but this depends on what labels your nodes have.</p>
