A civic PDF worker Pod stays Pending with events about insufficient CPU after requesting 16 CPU on a pool of 4-CPU nodes. What should the developer do?
Select an answer to reveal the explanation.
Short Explanation
Asking for 16 CPUs on 4-CPU nodes is like needing a bus lane on a bike path—nothing schedules. Shrink the request to what nodes can offer, or run where bigger machines exist. hostPath tricks and Job parallelism don't invent CPU capacity.
Full Explanation
A civic PDF worker Pod that stays Pending with events about insufficient CPU after requesting 16 CPU on a pool of 4-CPU nodes cannot schedule because no node offers enough allocatable CPU for that request. The developer should reduce the CPU request to fit available node capacity or target a node pool large enough for the workload. Matching requests to infrastructure reality is the correct fix.
Adding a hostPath volume so the Pod supposedly bypasses the CPU scheduler and runs on every node fails—volumes do not waive CPU requests. Annotating the Pod as a critical pod to ignore requests is inappropriate and still cannot make 16 CPU fit on 4-CPU nodes. Switching the Pod to a Job with parallelism 16 so each unit implicitly gets one CPU misunderstands parallelism; it does not automatically rewrite each Pod's CPU request to one.
Exam caveat: allocatable may be less than four cores on a nominally 4-CPU node after system-reserved resources. Operational check: describe node allocatable CPU, set the PDF worker request to a fitting value or use a larger pool, apply, and confirm the Pod binds and processes PDFs. In CKAD scenarios involving q206, prefer verifying the live object with kubectl get and describe before changing cluster-wide settings.