Controlling the Blast Radius
Affinity and Anti-Affinity are great for picking specific nodes or avoiding co-location, but they're clumsy at answering: "Spread these 12 Pods as evenly as possible across all 3 availability zones." Before Kubernetes 1.19, engineers wrote complex Pod Anti-Affinity rules to approximate this — and they were brittle, hard to reason about, and didn't handle dynamic cluster sizes well.
Topology Spread Constraints solve this directly. They let you declare: "Distribute my Pods across a failure domain (zone, rack, region) with at most N more Pods in any one domain than any other."
The key insight is the concept of maxSkew: the maximum allowed difference in Pod count between the most-loaded and least-loaded topology domain. A maxSkew of 1 means the distribution must be nearly perfect. A maxSkew of 3 means one zone can have up to 3 more Pods than another.
Key Fields Explained
A topology spread constraint combines a maxSkew, a topologyKey, a whenUnsatisfiable policy, and a labelSelector identifying which Pods it applies to.
topologyKey: The node label that defines the failure domain. Kubernetes groups nodes by this label's value. Common values:topology.kubernetes.io/zone— AWS/GCP/Azure availability zonestopology.kubernetes.io/region— geographic regionskubernetes.io/hostname— individual nodes (equivalent to node-level spreading)-
Custom labels like
rackordatacenterfor on-premises clusters -
maxSkew: The maximum allowed imbalance. With 6 Pods across 3 zones andmaxSkew: 1, the only valid distributions are 2-2-2. A 3-2-1 distribution has a skew of 2 (3 minus 1) and is forbidden. -
whenUnsatisfiable: What to do when the constraint cannot be satisfied: DoNotSchedule— Pod staysPending. Use when HA is non-negotiable.-
ScheduleAnyway— Pod schedules on the best available node. Use when uptime matters more than perfect balance. -
labelSelector: Which Pods count toward the spread calculation. This must match the Pods in your Deployment — the constraint is meaningless without it.
Multiple Constraints
You can stack multiple constraints. They are evaluated with AND logic — all constraints must be satisfied simultaneously. A pair of constraints, one keyed on zone and one keyed on hostname, both scoped to the same Pods, ensures Pods are spread across both zones AND individual nodes within each zone — the strongest possible HA configuration.
A common interview question: "How is Topology Spread Constraints different from Pod Anti-Affinity for spreading replicas?" The key differences: (1) Topology Spread Constraints are declarative about balance — you specify the allowed skew, not individual node relationships. (2) They scale better because the scheduler doesn't need to evaluate every existing Pod pair. (3) They handle dynamic cluster sizes gracefully — if you add a new zone, the constraint automatically incorporates it. Anti-Affinity rules are static and require manual updates to account for new topology domains.