How In‑Place Pod Resizing Evolves in Kubernetes v1.33: From Alpha to Beta

What Is In‑Place Pod Resizing?

Traditionally, changing CPU or memory allocations for a container required restarting the Pod, which can be disruptive for stateful services, long‑running batch jobs, or any workload sensitive to restarts. In‑place pod resizing lets you modify a running Pod’s CPU and memory requests and limits, usually without restarting the container.

Core Concepts

The spec.containers[*].resources field in the Pod spec now represents the desired resources and is mutable for CPU and memory.

The status.containerStatuses[*].resources field reflects the actual resources currently configured on the running container.

You trigger a resize by updating the desired resources via the new resize subresource of the Pod.

Why In‑Place Pod Resizing Matters

Reduced disruption: Stateful applications, long‑running batch jobs, and sensitive workloads can adjust resources without the downtime or state loss associated with Pod restarts.

Improved resource utilization: Over‑provisioned Pods can be downsized without interruption, freeing cluster capacity, while heavily loaded Pods can be up‑scaled on‑the‑fly.

Faster scaling: Instant resource spikes—such as higher CPU demand during Java application startup—can be met by initially allocating more CPU and then reducing it later without a restart.

Changes from Alpha to Beta

Since the Alpha release in v1.27, extensive work has refined the feature. Key user‑visible changes include:

Resize subresource: Modifying Pod resources now requires using the resize subresource (e.g., kubectl patch pod <name> --subresource resize ... ). This is supported starting with kubectl v1.32.

Resize status via Pod conditions: The old status.resize field is deprecated. Two new conditions report resize progress: PodResizePending – kubelet cannot approve the resize immediately (reasons such as Deferred or Infeasible ). PodResizeInProgress – the resize has been accepted and is being applied; errors are reported in the condition’s message.

Sidecar support: Sidecar containers can now be resized in‑place.

Stability and Reliability Enhancements

Redesigned allocated‑resource management in kubelet for greater consistency and robustness, eliminating many errors.

Improved checkpoint and state‑tracking logic using new checkpoint files ( allocated_pods_state , actuated_pods_state ) to reliably preserve resize state across kubelet restarts and handle edge cases where runtime‑reported resources differ from requests.

Faster resize detection via enhancements to the Pod Lifecycle Event Generator (PLEG), allowing kubelet to react more quickly.

Enhanced CRI integration with a new UpdatePodSandboxResources call, better informing runtimes and plugins (e.g., NRI) of Pod‑level resource changes.

Numerous bug fixes covering systemd CGroup driver issues, containers without resource limits, CPU minimum‑share calculations, restart back‑off, error propagation, and test stability, among others.

Future Outlook for In‑Place Pod Resizing

Continued focus on stability and productization to ensure the feature is robust enough for production use.

Addressing current limitations, such as enabling reductions of memory limits.

Integration with Vertical Pod Autoscaler (VPA): a new InPlaceOrRecreate update mode will let VPA first attempt a non‑disruptive in‑place resize and fall back to Pod recreation when necessary, allowing users to benefit from VPA recommendations while minimizing disruption.