# Decide when Kubernetes topology spread should block placement

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

- Canonical URL: https://update.dsesecurity.com/updates/decide-when-kubernetes-topology-spread-should-block-placement/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-10-20T18:14:44+00:00
- Modified: 2026-10-20T18:34:31+00:00
- Last reviewed by DSE: 2026-10-20
- Resource type: Guide
- DSE priority: Information
- Topics: IT, Networks & Infrastructure
- Reading time: 2 minutes

## What you need to know

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

## Potentially affected

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.

## Article

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](https://kubernetes.io/docs/concepts/scheduling-eviction/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](https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/). Reviewed October 20, 2026.

## Primary reference

- Name: Kubernetes documentation — Pod Topology Spread Constraints
- Authority: kubernetes.io
- URL: https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Decide when Kubernetes topology spread should block placement,” DSE Security, https://update.dsesecurity.com/updates/decide-when-kubernetes-topology-spread-should-block-placement/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.