Decide when Kubernetes topology spread should block placement

DoNotSchedule makes maxSkew a placement restriction; ScheduleAnyway prioritizes reducing skew.

Source facts

Kubernetes topology spread constraints compare matching Pod counts across topology domains. With whenUnsatisfiable set to DoNotSchedule, maxSkew is a hard placement restriction. ScheduleAnyway expresses a scheduling preference instead. The minDomains setting affects the global minimum used in skew calculations when too few eligible domains exist. Eligibility also depends on the configured placement rules.

Source: Kubernetes documentation — Pod Topology Spread Constraints.

Applicability

Review topology-spread scheduling constraints and the eligible domains used in their skew calculation.

DSE recommendation

DSE recommends choosing whether reduced placement availability or reduced fault separation is the more acceptable failure mode for each workload. Inventory the actual labeled domains and the constraints that make nodes eligible. Review the selector carefully so the count represents the intended application replicas. Explain the expected result when a zone is unavailable, including whether Pending is the desired signal. Keep this policy aligned with capacity planning rather than weakening it during an incident without recording the tradeoff.

Verification

Use an approved test workload to inspect placement with all domains available and with one excluded from eligibility. Compare scheduler events and matching Pod counts. Confirm that the resulting pending or colocated replicas reflect the documented policy. Write the expected eligible-domain count and skew calculation into the test plan before excluding a domain. Keep the observed count and scheduler explanation with the outcome, including an intentionally Pending replica.

Official reference

Kubernetes documentation — Pod Topology Spread Constraints. Reviewed October 20, 2026.