← Problem Library
K8s L4 K8S 1370 · 12 min

A PodDisruptionBudget looks safe and node drains still stall because HPA behavior and rollout limits already consume the same availability margin the PDB expects to protect

The budget is valid, yet drains freeze because another controller already spent the disruption headroom.

K8sPlatform ReliabilityLevel 4Pro12 min
Scenario

A drain or upgrade stalls after autoscaling and rollout tuning were changed independently across teams.

What to check first
  • Identify the primary failure signal in the The Budget Was Correct and Another Controller Had Already Spent It 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 shared availability headroom across controllers before loosening the PDB.

Questions worth viewing together
What should you verify first when A PodDisruptionBudget looks safe and node drains still stall appears?

Community-field Kubernetes problem inspired by community patterns where PDBs stalled drains because other controllers had already consumed the disruptio... Disruption budget math spans HPA, rollout limits, and PDBs together.

What usually causes A PodDisruptionBudget looks safe and node drains still stall in production?

Teams often blame the PDB alone when the real issue is cumulative availability policy across multiple controllers.

What should you document after resolving A PodDisruptionBudget looks safe and node drains still stall?

Any change to rollout or autoscaling limits should trigger a review of PDB assumptions.