In-Place Pod Resize Is GA: What It Actually Changes for Rightsizing

Kubernetes 1.35, released December 2025, graduated in-place pod resize to stable. You can now patch spec.containers[*].resources on a running pod through the resize subresource, and for CPU the container typically doesn’t restart at all. Memory increases usually apply live too; memory decreases can still trigger a restart depending on the container runtime, so it isn’t a total free pass — but it removes the single biggest reason rightsizing recommendations sat unapplied for months at a time.

The restart tax was the actual blocker

Every rightsizing tool before 1.35 had the same catch: change a pod’s requests, and the scheduler reschedules it. For a stateless web tier, that’s a non-event. For a stateful service, a long-running job, or anything with a slow warm-up cache, that’s a reason a recommendation sits in a backlog instead of getting applied — nobody wants to own an incident caused by a maintenance action that was supposed to save a few dollars a month.

That hesitation is visible in the numbers. Recent industry data puts average Kubernetes CPU utilization at just 8%, with CPU over-provisioning climbing from 40% to 69% year over year. Teams generally aren’t over-provisioning because they don’t know better. They’re over-provisioning because the fix used to cost more than the waste did.

What actually changes with GA

Time-of-day scaling becomes practical. Shrinking non-prod and batch workloads overnight and scaling them back up before the morning traffic curve no longer means scheduling a pod bounce around it.

Autoscalers can act on live data. Vertical Pod Autoscaler and cluster autoscalers can apply a new recommendation as soon as it’s calculated instead of waiting for a natural pod churn event — a deploy, a node drain, a crash — to have somewhere to land the change.

Rightsizing tools stop being advisory-only in practice. A recommendation you can apply with one click and no downtime gets applied. A recommendation that requires a maintenance window mostly doesn’t, no matter how good the underlying analysis is.

What it doesn’t fix

In-place resize solves the how. It does nothing about the what. You still need workload-level visibility into requests versus actual usage to know which pods are worth resizing in the first place — and for a lot of teams, that visibility gap, not the restart tax, is now the larger blocker.

Frequently asked questions

Does in-place resize work for every workload type? It applies to any pod using the resize subresource, but the practical safety varies — stateless workloads with no local state are the least risky to resize live; anything with in-memory caches or long-lived connections benefits from testing the behavior before relying on it broadly.

Do CPU and memory resize behave the same way? No. CPU resource changes generally apply without a restart. Memory decreases are more likely to require one, since the container runtime has to actually free the memory rather than just adjust a cgroup limit upward.

Does this replace the need for a Vertical Pod Autoscaler? No — VPA still decides what to change; in-place resize changes how cheaply that decision can be applied. The two are complementary, and VPA implementations are actively adding support for the resize subresource rather than being made obsolete by it.

Is this available on managed Kubernetes (EKS, AKS, GKE), or only self-managed clusters? It’s a core Kubernetes API feature tied to cluster version, not a vendor add-on — availability depends on which control-plane version your managed cluster is running, so check your provider’s supported version list rather than assuming it’s universal yet.

Rightsizing only pays off if you know which workloads are actually over-provisioned — see requests versus real usage across your fleet, namespace by namespace, without standing up a separate monitoring stack first.