In-place Pod resize on Kubernetes: field notes for right-sizing without restarts

What changed

In-place Pod resize arrived as alpha in Kubernetes 1.27, reached beta in 1.33 and graduated to stable in 1.35¹³. It makes CPU and memory requests and limits mutable on a running Pod. You send the change to the Pod's resize subresource, for example with kubectl patch --subresource resize, which needs kubectl 1.32 or later².

Each container declares a resizePolicy per resource. NotRequired asks for the change to be applied without a restart; RestartContainer restarts that container to apply it. A common pattern in the documentation is CPU set to NotRequired and memory set to RestartContainer².

The stable release added two things operators will notice. Memory limits can now be decreased, with the kubelet only allowing it when current usage is below the new limit, a best-effort check rather than a guarantee. And when a node can't fit every pending resize, retries are ordered by PriorityClass, then QoS class, then how long the request has waited¹.

Watch the conditions, not just the spec

A resize is a request, not a guarantee. The kubelet reports progress through Pod conditions²:

The practical rule: alert on long-lived PodResizePending. A spec that says 4 CPUs while the container still runs on 2 is a quiet source of confusion in incidents and cost reports alike.

Where the VPA fits

The Vertical Pod Autoscaler recommends requests from observed usage and applies them. Its InPlaceOrRecreate update mode tries an in-place resize first and falls back to recreating the Pod when that isn't possible; the 1.35 release blog described that mode as graduating to beta¹⁵.

This is the combination that changes cost economics. Recommendations used to sit in a report because applying them was disruptive. With in-place updates they can be applied continuously, within limits you set.

Pod-level resources are next

Kubernetes 1.36 promoted in-place resize of Pod-level resources to beta, meaning a shared budget for all containers in a Pod can also change without recreating it⁴. That is useful for Pods with sidecars, where per-container numbers are hard to tune separately. I would treat it as beta: pilot it, but don't build a platform default on it yet.

Where it bites

• Applications that size themselves at start-up. A runtime that reads its memory limit once, such as a JVM heap or a worker pool sized to CPU count, won't notice a change. For those, a restart policy on memory is the honest choice.
• Memory decreases. The usage check is best-effort, so shrinking memory on a busy Pod still carries OOM risk¹. Shrink gradually and watch.
• Node fragmentation. Growing in place only works if the node has room. Busy nodes produce Deferred resizes; plan headroom or accept fallback to recreation.
• Quotas and policy. Resizes still count against namespace quotas, and teams will need guardrails on how far they can go, enforced with admission policies in multi-tenant clusters.

How I'd roll it out

1. Measure first. Compare requests with real usage by namespace and team, using the allocation approach in FOCUS-based cost allocation.
2. Start with CPU on stateless services, using NotRequired, where the risk is lowest and the savings show quickly.
3. Run the VPA in recommendation mode for a few weeks, then enable InPlaceOrRecreate on workloads that tolerate the fallback.
4. Use it for warm-up spikes. Services that need extra CPU at start-up, including model servers like those in vLLM serving, can start large and shrink once warm.
5. Alert on pending resizes and report status, not spec, in cost dashboards.
6. Combine with scale-to-zero from Kubernetes FinOps: horizontal scaling for traffic shape, vertical for per-Pod fit.

How I can help

I run Kubernetes cost and platform reviews that turn right-sizing from a one-off report into a continuous, safe process. As a fractional CTO I can own that roadmap. Or analyse your challenge and bring the result to a call.