IT lexicon › Infra & Ops › Topology spread constraint

Topology spread constraint

Infra & Ops På svenska → Updated: 2026-05-29

A Kubernetes mechanism for distributing pods evenly across topology domains (nodes, zones, regions). More modern and fine-grained than anti-affinity — you specify how much imbalance ("skew") you tolerate instead of just "same/not same".

Mechanic: you set a maxSkew (how big a difference in pod count between domains is accepted), a topology key (e.g. zone), and what should happen if the requirement can't be met (DoNotSchedule = hard, ScheduleAnyway = soft). The scheduler places new pods so the distribution stays within the skew limit. Win over anti-affinity: instead of the binary "never run two on the same node" you get "keep it roughly evenly distributed across the zones" → better balance and availability, especially across failure zones. Use case: ensure a deployment's replicas spread across three availability zones so a zone outage only takes a third. The recommended modern mechanism for HA spreading. Related to pod affinity and node affinity.

← Back to the lexicon