Effective Pod Resource Requests
Four containers ask for cpu, so how much does the Scheduler reserve? Not their sum: regular init containers run one at a time so the tallest counts, plus any sidecar declared before it, while the app and the sidecar run together so theirs are added, and the Pod takes the higher of those two plus any RuntimeClass overhead. The Scheduler bins on it and the Kubelet sizes the Linux Pod cgroup from it, so a short init container holds its share for the whole Pod life.
Play the animation 6 steps, animated, best on a wide screen
Effective Pod Resource Requests, step by step
-
Read this as one Pod life, left to right, with cpu up the page. First init-a runs on its own, then init-b runs on its own, and then the sidecar and the app run together for the rest of the Pod. Four containers, four cpu requests, and adding all four up gives 1750m, which is the one number this Pod is never charged.
Play from step 1 -
Everything the containers ask for stands on a floor. A Pod that names a RuntimeClass declaring overhead.podFixed carries that fixed amount for itself, 250m of cpu here for a sandboxed runtime. It pays for the sandbox rather than for anything a container asked for, and a Pod on the default runtime has no floor at all.
Play from step 2 -
Regular init containers run strictly one at a time, so at no instant do two of them hold cpu together. The effective init request is therefore the highest single one, 800m, not the 1100m they add up to, and the phase holds that 800m whichever of the two is running, which is why init-b stands as tall as init-a.
Play from step 3 -
The sidecar and the app overlap for the rest of the Pod, so their requests add up: 200m plus 450m is 650m. Being an init container with restartPolicy=Always, the sidecar is weighed in the init maximum too, where 800m wins. Declared before init-a it would run beside it and lift that maximum to 1000m: array order is part of the number.
Play from step 4 -
A Pod is charged for the tallest instant of its life, so the higher of the two envelopes wins and that is the 800m init phase, not the 650m run phase. Standing on the 250m floor it comes to 1050m, and the line runs the whole width because the reservation lasts the whole life. Limits follow the same max and sum.
Play from step 5 -
The Scheduler bins the Pod on 1050m and the Kubelet sizes the Linux Pod cgroup from the same number. By the start of the run phase init-a is finished, and for that whole phase 150m of what was reserved is asked for by nothing that is still running. Memory is counted the same way. Pod-level spec.resources, when set, replaces the container part of this number, and the overhead still adds on top.
Play from step 6