← Problem Library
K8s L5 K8S 1226 · 20 min

Pods stay Pending after scale-out because one topology spread rule forbids the only nodes that still have the required volume zone

Capacity exists on paper, yet scheduling never completes because topology spread and storage zone requirements cancel each other out.

K8sPlatform ReliabilityLevel 5Pro20 min
Scenario

A stateful workload scales during an incident and new pods remain Pending even though several nodes appear idle.

What to check first
  • Identify the primary failure signal in the Spread Rule vs Zone Constraint scenario.
  • Separate visible symptoms from the underlying technical dependency.
  • Describe the safest recovery path and the follow-up prevention work.
Checking checklist
  1. Summarize the current impact and the last known change.
  2. Collect direct evidence from logs, runtime state, and configuration before changing anything.
  3. Separate immediate recovery from permanent prevention work.
Recovery and prevention

Read scheduling constraints together instead of inspecting spread and storage placement separately.

Questions worth viewing together
What should you verify first when Pods stay Pending appears?

Community-field Kubernetes scheduling problem inspired by Stack Overflow cases where topology spread and PV zone constraints conflicted. A scheduler deadlock often comes from two individually valid constraints colliding.

What usually causes Pods stay Pending in production?

Teams often blame missing capacity when the real issue is an impossible placement rule set.

What should you document after resolving Pods stay Pending?

Spread rules can quietly eliminate the only zone where the volume can actually attach.