An init container requests 2 CPU while the two app containers together request 500m. How do init container requests influence Pod scheduling?
Select an answer to reveal the explanation.
Short Explanation
Init containers are the warm-up act that still needs a stage big enough for their gear. Scheduling accounts for init resource needs alongside the running app containers. A hungry init can keep the whole Pod Pending even if the long-running containers look small.
Full Explanation
When an init container requests 2 CPU while the two app containers together request 500m, the scheduler must find a node that can satisfy the effective Pod request, which considers init container requirements as well as app containers. Effective CPU need is driven by the larger of init requirements versus the sum of app containers, so a heavyweight migrate init can dominate placement for municipal migrate-then-serve Pods.
Claiming init container requests are ignored for scheduling because init containers exit before the Pod is Ready fails—scheduling occurs before running and uses those requests. Claiming only the sum of app container requests matters and that init requests apply only after the Pod is bound fails the scheduling model. Claiming init requests are billed to a separate virtual node and never affect placement of app containers invents a nonexistent mechanism.
Exam caveat: after init completes, ongoing usage is the app containers, but the Pod still required a node that fit the effective request at bind time. Operational check: if Pending, describe Events, lower init CPU if the migrate step allows or target larger nodes, then confirm the Pod schedules and progresses through init.