Topology spread constraints versus pod anti-affinity

WHAT THIS TESTS This distinguishes a modern, granular spreading primitive from the older, blunter anti-affinity. The interviewer wants the why and the knobs.

A GOOD ANSWER COVERS Pod topology spread constraints distribute pods proportionally across a topologyKey such as zone or hostname. The key knob is maxSkew, the maximum permitted difference between the number of matching pods in the most populated domain and the least populated eligible domain. With maxSkew 1 the scheduler keeps domains within one pod of each other. whenUnsatisfiable decides whether violation blocks scheduling (DoNotSchedule) or is best-effort (ScheduleAnyway). Pod anti-affinity instead expresses repulsion: do not place this pod where a matching pod already runs. With requiredDuringScheduling and topologyKey hostname, it effectively caps you at one replica per node, which fails once replicas exceed nodes. Anti-affinity is binary and does not express how evenly to fill domains; spread constraints do.

COMMON WRONG ANSWERS Treating them as interchangeable misses that anti-affinity cannot say keep zones within one pod of each other. Using hard hostname anti-affinity and then being surprised pods go Pending when replicas exceed node count is a frequent trap. Forgetting maxSkew is measured against the least-populated eligible domain, not zero, is subtle.

LIKELY FOLLOW-UPS What minDomains adds. Performance cost of anti-affinity at scale (it is O(pods) and expensive). Combining spread for zones with anti-affinity for nodes.

ONE CONCRETE EXAMPLE Nine replicas across three zones with maxSkew 1 gives a clean 3-3-3. Doing the same with required zone anti-affinity would cap you at three pods total, one per zone, and leave six Pending.