You are draining a Kubernetes node. Eleven pods evict cleanly, the twelfth is refused by the eviction API and the drain hangs. What is happening, and what do you do?

1. Identify the mechanism: a PodDisruptionBudget defines a floor of available replicas, and evicting the last remaining replica would breach it, so the API refuses on purpose. 2. Confirm the diagnosis by inspecting the PDB and the workload's replica count and readiness. 3. Rule out force deletion and explain the danger: for a stateful workload, force deleting removes the API object while the process may still be running, giving you two writers and data corruption. 4. Fix the actual constraint: scale up so a replacement replica becomes ready elsewhere, then the eviction satisfies the budget. 5. Check whether the pod can even be rescheduled — node affinity, taints, resource pressure, or a single-zone volume can leave nowhere to go. 6. Reframe the PDB block as correct behaviour rather than an obstacle: it is the cluster telling you the workload is not actually redundant. 7. Longer term, require minAvailable budgets and more than one replica for anything that must survive a drain.