Kubernetes 1.36 adds beta in-place resizing for pod-level resources

An April 30 Kubernetes engineering post detailed beta in-place vertical scaling for pod-level resources introduced with Kubernetes 1.36, which was released on April 22. The feature announcement describes changing a Pod’s aggregate CPU or memory allocation without replacing the Pod, extending in-place resize beyond individual container requests.

Resize state is visible in the Pod

The beta uses conditions to separate an accepted specification change from work still happening on the node. PodResizePending means the specification changed but the node has not admitted it, for example because capacity is unavailable. PodResizeInProgress means the node admitted the resize, while cgroup changes are not yet fully reflected in the reported resources.

That distinction matters to automation. A controller should not treat an updated spec as proof that the new resources are active. It can watch conditions and the allocated and applied resource fields, then decide whether to wait, retry, or move work elsewhere.

The prerequisites narrow the first test

The feature is Linux-only and requires cgroup v2. It also needs a container runtime implementing the CRI UpdateContainerResources call, such as containerd 2.0 or later or CRI-O, plus the relevant feature gates. The Kubernetes post says future work includes Vertical Pod Autoscaler integration; the beta does not by itself make VPA perform these pod-level changes automatically.

A safe evaluation should resize a noncritical workload upward and downward while tracking Pod conditions, application latency, and node allocatable capacity. Test a rejected resize and a node restart as well as the happy path. For stateful or latency-sensitive services, confirm the application actually adapts to new CPU and memory limits. The beta removes some replacement churn, but it adds a lifecycle that controllers and runbooks must understand.