Spreading replicas across availability zones

WHAT THIS TESTS The interviewer wants to see if you can deliberately distribute replicas across failure domains for availability, not just scale a Deployment and hope.

A GOOD ANSWER COVERS The primary tool is topologySpreadConstraints in the pod spec. Set topologyKey to topology.kubernetes.io/zone, which cloud providers stamp on nodes automatically. Use maxSkew to define the maximum allowed difference in pod count between the most and least populated zones; maxSkew of 1 forces near-even spread. Choose whenUnsatisfiable: DoNotSchedule for a strict guarantee, where a pod stays Pending if spreading the rule would be violated, or ScheduleAnyway for a soft preference. The labelSelector inside the constraint must match the pods being counted, typically the Deployment's own pod labels. You should also confirm replicas exceed the number of zones so each zone gets coverage.

COMMON WRONG ANSWERS Saying the scheduler spreads pods automatically is weak; default soft spreading exists but offers no guarantee. Using separate Deployments pinned per zone via nodeSelector is brittle and breaks rolling updates. Forgetting that DoNotSchedule can leave pods Pending when a zone lacks capacity is a maturity gap.

LIKELY FOLLOW-UPS Difference from podAntiAffinity (anti-affinity is binary co-location, spread constraints control proportional balance). What minDomains does. How PodDisruptionBudgets complement this during voluntary disruptions.

ONE CONCRETE EXAMPLE For a six-replica payment service across three zones, set maxSkew 1, topologyKey zone, whenUnsatisfiable DoNotSchedule, labelSelector app=payment. The scheduler places two pods per zone; losing one zone leaves four healthy pods serving traffic.