A new parks-api Pod stays Pending. kubectl describe shows FailedScheduling with Insufficient cpu, and the Pod’s requests.cpu is 4 on nodes that each have about 2 allocatable cores left. What is the most accurate diagnosis?
Select an answer to reveal the explanation.
Short Explanation
The scheduler is matching reservation sizes to free shelves. Ask for four cores when only two are free and the Pod sits Pending. That message is about requests at schedule time, not an OOM or image pull.
Full Explanation
A new parks-api Pod that stays Pending with FailedScheduling Insufficient cpu—while requests.cpu is 4 on nodes that each have about 2 allocatable cores left—cannot be placed because its CPU request exceeds remaining allocatable CPU on candidate nodes. The scheduler is correctly refusing a fit that does not exist. Municipal capacity planning must lower the request, free capacity, or add nodes before the Pod can bind.
Claiming the memory limit is too low and that the scheduler reports that condition as Insufficient cpu fails because the Event message specifically names CPU. Claiming kubelet OOMKilled the container before scheduling finished fails lifecycle order; OOMKilled applies to running containers, not Pending unschedulable Pods. Claiming ImagePullBackOff counts as Insufficient cpu when the registry is slow conflates image pull failures with scheduling resource-fit failures.
Exam caveat: allocatable is less than capacity because of system-reserved resources and eviction thresholds—always compare Pod requests against allocatable. Operational check: describe Pod Events and node allocatable versus allocated requests, reduce parks-api CPU requests or scale the node pool, and confirm the Pod schedules and becomes Running.