← Problem Library
K8s L4 K8S 1360 · 12 min

A PodDisruptionBudget looks correct and voluntary evictions still stall

The PDB is valid, yet upgrades freeze because the deployment's own rollout limits and autoscaling behavior leave no room for another eviction.

K8sPlatform ReliabilityLevel 4Pro12 min
Scenario

A rolling update or node drain stalls after autoscaling and rollout tuning were changed independently.

What to check first
  • Identify the primary failure signal in the The Budget Was Safe on Paper and Already Spent by Another Controller 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

Model disruption headroom across controllers before loosening the PDB itself.

Questions worth viewing together
What should you verify first when A PodDisruptionBudget looks correct and voluntary evictions still stall appears?

Community-field Kubernetes problem inspired by community patterns where a PDB stalled evictions because rollout and HPA limits had already spent the dis... Disruption budgets interact with rollout and autoscaling limits as one shared availability budget.

What usually causes A PodDisruptionBudget looks correct and voluntary evictions still stall in production?

Teams often blame an overly strict PDB when another controller already consumed the available disruption margin.

What should you document after resolving A PodDisruptionBudget looks correct and voluntary evictions still stall?

Availability controls should be reviewed together whenever HPA or rollout policies change.