When a topology-spread constraint cannot be met—for example, because a node is full—Kubernetes chooses between two behaviors. ScheduleAnyway keeps scheduling the replica while still trying to honor the spreading preference; DoNotSchedule refuses placement that would violate the constraint. section 8.2.1
Choose the behavior according to the operational goal:
- Use DoNotSchedule when testing or when strict placement matters; an unsatisfied rule makes the scheduling problem visible and can leave a replica unscheduled. section 8.2.1
- Use ScheduleAnyway for production availability: Kubernetes still attempts balanced placement instead of leaving a replica unscheduled, making the constraint a soft preference. section 8.2.1
Three-replica deployment
A Deployment using topologySpreadConstraints with maxSkew 1, a hostname topology key, and whenUnsatisfiable: ScheduleAnyway asks Kubernetes to distribute replicas across nodes while preserving scheduling flexibility.
