In-place Pod Resize
A running Pod is short on CPU, so does it have to be replaced to get more? In-place resize is stable in 1.35: you patch spec.containers[].resources through the resize subresource, and the Kubelet applies the new numbers to the running container, in place or by restarting it, as resizePolicy says per resource. The API server refuses an ask above the Node allocatable, the Kubelet raises PodResizePending when it cannot apply one now, and the QoS class never moves.
Play the animation 6 steps, animated, best on a wide screen
In-place Pod Resize, step by step
-
One container runs with cpu 700m and memory 200Mi as both its request and its limit, so this Pod is Guaranteed. Changing those numbers once meant deleting the Pod and creating a replacement. In-place Pod resize is stable in 1.35 and moves them on the Pod that is already running.
Play from step 1 -
A patch through the resize subresource raises the desired cpu to 800m, and kubectl needs client version v1.32 or later to address that subresource. Only cpu and memory can be resized, and neither can be dropped once it is set. The spec carries the ask, so nothing on Node-1 has moved yet.
Play from step 2 -
The resizePolicy field answers, per resource, whether the container survives the change. NotRequired is the default and applies the new value to the running container. RestartContainer restarts it, which memory often needs because many applications cannot grow their allocation on the fly. Change two resources whose policies differ and RestartContainer takes precedence.
Play from step 3 -
The Kubelet reads the new spec off its watch and decides. It can allocate the value now, or it raises PodResizePending with reason Deferred when the Node has no room yet and keeps retrying, or Infeasible when a Node policy rules it out, such as the static CPU Manager policy for this Guaranteed Pod. Deferred retries go by Priority first, then Guaranteed before Burstable, then longest waiting.
Play from step 4 -
Once the Kubelet allocates it, PodResizeInProgress stands while the runtime rewrites the limit on the live container and cpu.max follows, then status.containerStatuses[].resources catches up with the spec. The cpu policy is NotRequired, so restartCount stays 0. Lowering a memory limit under NotRequired is best effort and is skipped while usage sits above the new value.
Play from step 5 -
The QoS class is fixed when the Pod is created and no resize may move it, so on this Guaranteed Pod every request must stay equal to its limit. A patch that would land it in Burstable is refused by the API server before the Kubelet sees it, and since 1.36 so is one that asks for more than the Node allocatable. The Pod QoS Classes card covers how the class is derived.
Play from step 6