A blocked eviction may be the intended safety behavior
A PodDisruptionBudget, or PDB, limits certain voluntary disruptions to a selected set of Pods. During a node drain, an eviction can be refused because the workload cannot lose another eligible healthy replica under its current budget. The refusal can be evidence that the protection is working, not a broken drain command.
A PDB does not guarantee application availability through every failure. It does not replace adequate replicas, scheduling capacity or an application-aware maintenance plan. This guide diagnoses why a particular voluntary eviction is blocked and what must become healthy before maintenance can proceed safely.
Setup: connect the node to the selected workload
Record the node, namespace, workload controller and maintenance objective. Identify the PDB that actually selects the affected Pods, including its selector and minAvailable or maxUnavailable policy. Review the workload's desired and ready replica counts rather than assuming the deployment specification equals current availability.
Read-oriented collection can include:
kubectl get pdb -n example
kubectl describe pdb example-api -n example
kubectl get pods -n example -o wide
Use the real namespace and object names. Preserve PDB status and recent workload events before modifying replicas or budgets. Also confirm that a replacement Pod could schedule somewhere other than the node being drained.
Illustrative incident: an unrelated unhealthy replica consumes the budget
In this illustrative scenario, an API normally runs several replicas, but one is already unready because a dependency is failing. A maintenance drain targets a different node. The PDB refuses another eviction because the currently healthy population cannot satisfy the budget afterward.
The team investigates the unready replica and available replacement capacity. It does not lower the budget simply because the maintenance ticket has a short window. This example explains a decision process; it does not assert a universal replica count that guarantees availability for every service.
Troubleshooting: reconcile desired, healthy and evictable
| Observation | Evidence | Decision |
|---|---|---|
| Disruptions allowed is zero | PDB status and healthy counts | Can the workload safely lose an eligible Pod now? |
| Desired replicas exceed ready replicas | Controller and readiness events | Restore the existing availability deficit first |
| Replacement Pods remain Pending | Placement and capacity evidence | Provide a valid replacement location |
| PDB selects unexpected Pods | Labels and selector | Correct the ownership or selector design through review |
Understand the difference between voluntary eviction and involuntary failure. Direct deletion and some other operations do not provide the same maintenance protection as a controller honoring the Eviction API. Forcing a drain can remove the very safeguard the team intended to use.
Plan maintenance around a demonstrated availability envelope
Restore unhealthy replicas, provide eligible capacity or adjust a demonstrably incorrect workload/PDB design through owner review. A budget change must reflect the application's real tolerance for disruption, including quorum or dependency behavior. A convenient integer is not an availability analysis.
Consider startup time, readiness, persistent storage attachment and traffic removal when choosing the maintenance sequence. If the window cannot accommodate a safe drain, defer or redesign the maintenance rather than describing a forced eviction as an equivalent operation. Record the last safe point and the person authorized to accept a wider outage risk.
Verification, alerting and SOP
Verify the approved drain completes while the application's accepted requests remain within its agreed service envelope. Confirm replacement Pods become ready in eligible locations and that the returned node follows the normal maintenance procedure. Review both application signals and controller state.
Monitor unavailable replicas, persistent zero disruption allowance and blocked maintenance separately from immediate customer-impact alerts. An internal SLO can govern maintenance completion under healthy-capacity assumptions; a contractual SLA remains a separate commitment. The SOP should identify the PDB owner, selection evidence, availability checks, replacement capacity, stop conditions and post-maintenance acceptance.
See Clouvenix containers kubernetes for a reviewed implementation and operational handover.
Technical reference
Kubernetes disruption concepts, Kubernetes PDB API reference. Reviewed 19 October 2026; use documentation for the installed product and release.