In-place Pod resize is stable in Kubernetes 1.35: what it changes, and where it still restarts you

For most of Kubernetes' history, a container's CPU and memory were fixed for the life of the Pod; changing them meant deleting and recreating it [1]. In Kubernetes 1.35, In-Place Pod Resize — alpha in 1.27, beta in 1.33 — graduated to stable [1].

How it works

• CPU and memory requests and limits are mutable in a running Pod, often without a container restart [1].
• spec.containers[*].resources now represents the desired resources; status.containerStatuses[*].resources reflects what is actually configured [1].
• A resize is requested by updating the desired requests and limits through the new resize subresource [1].

What changed between beta and stable

• Memory limit decreases are now permitted. The kubelet only allows the resize if current usage is below the new limit, but that check is best-effort and not guaranteed [1].
• Prioritised resizes: when a node cannot fit every request, deferred resizes are retried by PriorityClass, then QoS class, then how long they have been deferred [1].
• New kubelet metrics and Pod events make resizes observable [1].

Where it still falls short

• Resize is prohibited with swap, the static CPU Manager and the static Memory Manager, and resources other than CPU and memory remain immutable [1].
• Java and Python runtimes do not support resizing memory without a restart [1] — so for many JVM services, raising the memory limit in place does not raise the heap the process will actually use.
• Vertical Pod Autoscaler's InPlaceOrRecreate mode, which uses the feature, is beta [1]; a pure in-place mode was still being worked on at GA [1].

What we ask

When we screen platform engineers, we ask what happens to a JVM service when its memory limit is raised in place. The answer separates engineers who have read the release notes from those who know the runtime sitting inside the container.