liveBook · Manning

Unsatisfiable constraint behavior

As explained in Kubernetes for Developers

Unsatisfiable constraint behavior determines how scheduling proceeds when a topology-spread constraint cannot be met.

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.

How Kubernetes for Developers covers it

How deep it goes
Contrasts both options and their operational consequences but does not detail scheduler internals.
Examples
Uses a three-replica Deployment with hostname spreading and a full-node scheduling scenario.
What it assumes
Assumes basic Kubernetes scheduling and labels while reinforcing label selectors and node topology labels.
What you can do after
Operate/configure Deployments by selecting strict or availability-oriented behavior for unsatisfied topology constraints.
How it connects
Connects topology spread constraints with scheduling, Deployments, label selectors, and high availability.

This explainer was generated by Manning's knowledge graph from the text of Kubernetes for Developers. The section links point to the parts of the book it draws on.