Do not treat a Kubernetes disruption budget as an outage guarantee

An eviction safeguard has a narrower boundary than application availability.

Source facts

A Kubernetes PodDisruptionBudget limits simultaneous unavailability during supported voluntary disruptions of a replicated application. It cannot prevent involuntary failures, though those failures count against the budget. Deleting Pods or their Deployment bypasses the budget. Workload rolling upgrades also are not limited by the PDB; their rollout behavior is controlled by the workload resource.

Source: Kubernetes documentation — Disruptions.

Applicability

Review the PDB boundary for voluntary eviction, involuntary unavailability and application updates.

DSE recommendation

DSE recommends listing every maintenance action used by the cluster team and identifying whether it uses the eviction API. Document the application’s actual minimum healthy capacity, then align its budget and rollout settings with that requirement. Include node loss and direct deletion in the risk review instead of assuming they are blocked. Make the maintenance runbook identify who can resolve a blocked eviction and what business approval is needed before accepting reduced capacity. A budget should express a deliberate operational constraint, not merely satisfy a configuration checklist.

Verification

During a controlled maintenance exercise, compare an eviction request with an application rollout and a simulated unavailable replica. Observe the budget’s allowed disruptions and the workload’s ready replicas. Do not perform destructive availability tests on an unapproved production workload. Require the exercise report to name the operation used, not just say that maintenance succeeded. Reconcile any unexpected eviction result with the controller’s desired replica count and the ready capacity at that moment.

Official reference

Kubernetes documentation — Disruptions. Reviewed October 20, 2026.