Spreading Pods one-per-node for availability

WHAT THIS TESTS Distinguishing the scheduling primitives and knowing the hard-versus-soft trade-off when spreading replicas for fault tolerance.

A GOOD ANSWER COVERS The right tool is pod anti-affinity. In the Pod template's affinity section, add podAntiAffinity with requiredDuringSchedulingIgnoredDuringExecution. The rule contains a labelSelector matching the Deployment's own Pod labels (for example app=webapp) and topologyKey set to kubernetes.io/hostname. This instructs the scheduler that no two Pods matching that selector may be placed within the same node-level topology, so each Pod gets its own node. Using required makes it a hard constraint; if there are fewer nodes than replicas, the extra Pods stay Pending. A modern alternative is topologySpreadConstraints with maxSkew 1 over the hostname topology.

COMMON WRONG ANSWERS Reaching for nodeAffinity, which constrains which nodes a Pod can run on based on node labels, not how Pods relate to each other. Using preferredDuringScheduling when the requirement is an absolute guarantee. Forgetting the node-count implication and being surprised by Pending Pods.

LIKELY FOLLOW-UPS What if you only need best-effort spreading? Use preferred or topologySpreadConstraints with a tolerable skew. Why IgnoredDuringExecution? Anti-affinity is only evaluated at scheduling time, not enforced after a Pod is running. Cross-zone spreading? Change topologyKey to a zone label.

ONE CONCRETE EXAMPLE A three-replica Deployment labels its Pods app=webapp. The template adds podAntiAffinity required, labelSelector app=webapp, topologyKey kubernetes.io/hostname. The scheduler places each of the three Pods on a different node; if the cluster has only two nodes, the third Pod remains Pending until a third node is available.