During a city maintenance window, kubectl drain hangs and reports that eviction is blocked for a critical pod. Which condition most often causes this drain to stall?
Select an answer to reveal the explanation.
Short Explanation
Draining a node is like closing a library wing—if a policy says 'keep at least one copy of this book on the shelf,' you cannot empty that last copy. A too-tight PDB is that policy and will stick the drain.
Full Explanation
Draining a municipal node is a controlled voluntary eviction: Kubernetes asks to remove pods while respecting PodDisruptionBudgets. If a critical library or 911 pod is protected by a PDB that would drop available replicas below the required minimum when that last pod leaves, the API refuses the eviction and kubectl drain hangs waiting. That is the most common stall condition when cordon succeeds but eviction does not complete. An expired kubelet client certificate can mark a node unhealthy or block API talk from kubelet, but it is not the typical reason drain reports eviction blocked for a specific critical pod while the drain controller waits on disruption budgets. StorageClass and PVC release semantics affect volume lifecycle; they do not freeze drain by blocking eviction of an ordinary pod whose disruption budget cannot be satisfied. Missing StorageClass is the wrong concept for a hang framed as eviction blocked. A ClusterIP Service without Endpoints can break traffic to an application, but cordon and drain are node and pod-disruption operations—they are not frozen by empty Endpoints objects. Exam caveat: drain may also wait on local data pods, unprotected DaemonSets (unless you use the right flags), or pods with long terminationGracePeriodSeconds. Still, when the message explicitly ties to disruption/eviction policy, PDB is the first concept to name. Operational check: Run kubectl describe pdb -A (or in the workload namespace), identify minAvailable/maxUnavailable versus current healthy pods, temporarily adjust the PDB or scale the workload so eviction is allowed during the maintenance window, re-run drain with an explicit timeout, and verify the node is empty before maintenance.