Spreading replicas across availability zones
Designing zone-resilient placement.
use topologySpreadConstraints on topology.kubernetes.io/zone with a small maxSkew, choose DoNotSchedule or ScheduleAnyway, and confirm nodes carry zone labels.
What's really being asked
The interviewer wants to see if you can deliberately distribute replicas across failure domains for availability, not just scale a Deployment and hope.
The full answer
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.
The mistakes people make
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.
What usually comes next
Difference from podAntiAffinity (anti-affinity is binary co-location, spread constraints control proportional balance). What minDomains does. How PodDisruptionBudgets complement this during voluntary disruptions.
A 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.
Interview question
Using topologySpreadConstraints with whenUnsatisfiable set to DoNotSchedule and maxSkew 1 across zones, what occurs if a zone lacks node capacity for the next replica?
- a.The replica stays Pending until balanced placement is possibleCorrect
- b.The constraint is silently downgraded to a preference
- c.The replica schedules anyway into an overfull zone
- d.All replicas are rescheduled to rebalance the cluster
Why? this is the answer
DoNotSchedule is a hard constraint, so a pod that would violate maxSkew stays Pending. ScheduleAnyway would instead place it in an overfull zone as a best-effort preference.
Just read this? Test yourself on what you have been reading.
Read the original → kubernetes.io
- #kubernetes
- #high-availability
- #topology-spread
- #scheduling
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on kubernetes — each one lists the topics its interview covers.
See open roles