Kubernetes v1.33: In-Place Pod Resize Hits Beta

Kubernetes v1.33 just made vertical scaling way less painful.

The in-place Pod resize feature-first introduced as alpha back in v1.27-has graduated to Beta and is now enabled by default. This is a big deal if you've ever had to restart a Pod just to give it more memory or CPU.

What changed?

Traditionally, resizing a container's resources meant killing the Pod and starting fresh. For stateless stuff, fine. For databases, long-running batch jobs, or anything that hates interruptions? Painful.

Now you can change CPU and memory requests and limits on a running Pod. Most of the time, no restart required.

How it works:

You update the Pod spec's spec.containers[*].resources field (which is now mutable for CPU and memory). The actual resources currently running show up in status.containerStatuses[*].resources. Trigger the resize via the new resize subresource:

kubectl edit pod <pod-name> --subresource resize

Requires kubectl v1.32+, but worth it.

Why this matters:

Less disruption for stateful applications. Better resource utilization-scale down over-provisioned Pods without losing state. Faster response to transient load spikes. Java apps that need extra CPU at startup? Spin up with higher resources, then resize down once steady-state kicks in.

What's new since alpha:

The team reworked the whole allocation management system with the Kubelet. Better checkpointing. Faster resize detection. Sidecar containers now supported. A bunch of edge-case bugs squashed. The CRI integration got an overhaul too.

What's next:

Production hardening. Relaxing current limitations (like allowing memory limit decreases). VerticalPodAutoscaler integration is already in progress-VPA will get a new InPlaceOrRecreate update mode to try non-disruptive resizes first.