← Problem Library
K8s L5 K8S 1224 · 18 min

PDB allows disruption on paper but drain still stalls because the controlling workload already has an unavailable revision elsewhere

Replica count and budget look safe locally, yet the workload already consumed its allowance on another node or rollout shard.

K8sPlatform ReliabilityLevel 5Pro18 min
Scenario

A node drain or maintenance window keeps failing even though the operator can count enough replicas in the cluster.

What to check first
  • Identify the primary failure signal in the Distributed Availability Budget 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

Look at rollout-wide unavailability before forcing eviction or removing the PDB.

Questions worth viewing together
What should you verify first when PDB allows disruption on paper but drain still stalls appears?

Community-field Kubernetes maintenance problem inspired by Stack Overflow cases where PDB allowance was already consumed by another unavailable revision. Local replica math can be misleading if another revision already consumed the disruption budget.

What usually causes PDB allows disruption on paper but drain still stalls in production?

Teams often assume drain is buggy when rollout churn elsewhere is the real blocker.

What should you document after resolving PDB allows disruption on paper but drain still stalls?

PDB decisions are workload-wide, not scoped to the node you happen to be draining.