A grants-intake Pod remains Pending. Events mention insufficient CPU on nodes, and a second similar Pod is Pending waiting for a PVC to bind. What should the developer do?
Select an answer to reveal the explanation.
Short Explanation
Pending is the lobby before admission—either no room (CPU) or the luggage never showed (PVC). Read the Events ticket. Fix requests, capacity, or volume binding instead of pretending the scheduler will shrug.
Full Explanation
A grants-intake Pod that remains Pending is waiting for the scheduler (or volume binding) to succeed—not running application code yet. Events citing insufficient CPU mean no node has enough allocatable CPU left for the Pod’s requests, while a sibling Pending on PVC bind means the volume has not bound (StorageClass, PVC pending, provisioning failure). The developer should inspect Events for those clues, then adjust CPU/memory requests, free or add node capacity, or fix PVC/StorageClass binding—never ignore Pending or try to bypass scheduling with destructive cluster hacks.
Force-deleting etcd Pods fails dangerously and does not “rebuild free CPU”; it risks control-plane outage and is outside CKAD application practice. Converting Pods to Privileged PodSecurity so the scheduler “ignores resources” fails because privilege does not waive resource requests or PVC binding requirements. Marking restartPolicy: Never fails because restart policy governs restarts after termination, not whether the scheduler can place a Pending Pod or bind volumes.
Exam caveat: Pending can also come from affinity/taints/PVC WaitForFirstConsumer—always read the specific Event message. Operational check: kubectl describe pod for FailedScheduling / PVC events, kubectl get pvc for Bound status, compare requests to kubectl describe node allocatable, then lower requests or fix storage so the grants Pod schedules.