Resize Kubernetes Pods Without a Restart: 1.35 Is GA

You can now change the CPU and memory of a running Kubernetes pod without restarting it, and as of Kubernetes 1.35 the feature is GA and safe to use in production. In-place pod resize makes resource requests and limits mutable on a live pod through a new resize subresource. CPU changes never restart the container, and memory changes usually do not either. For the over-provisioned clusters we audit, turning this on is a clean 20-40% off the compute bill with zero downtime.

This closes a gap that made vertical scaling painful for a decade: until now, changing a pod’s CPU or memory meant deleting and recreating it, which is a non-starter for stateful workloads like databases, caches, and message brokers. In-place resize started as alpha in 1.27, went beta in 1.33, and shipped stable in Kubernetes 1.35 on December 17, 2025.

What is in-place pod resize in Kubernetes?

In-place pod resize is a Kubernetes feature that lets you patch the CPU and memory requests and limits of a container in a running pod, without recreating the pod. You call the pod’s resize subresource, the kubelet applies the new values to the running container, and the pod keeps its identity, IP, and storage.

The important behavior:

• CPU resize never restarts the container. It is applied by updating the cgroup limits live.
• Memory resize usually does not restart either. Whether it restarts depends on the container’s resizePolicy. With restartPolicy: NotRequired (the default for CPU and memory), the kubelet resizes in place.
• The pod object is patched, not replaced. No new pod, no rescheduling, no lost connections.

The canonical reference is the Kubernetes resize container resources docs.

How do you resize a running pod?

Use kubectl patch against the pod’s resize subresource with the new requests and limits. Here is the shape of it:

kubectl patch pod my-app --subresource resize --patch \
  '{"spec":{"containers":[{"name":"app","resources":{"requests":{"cpu":"1"},"limits":{"cpu":"2"}}}]}}'

The container’s CPU is updated live. You can watch the applied values under the pod status, and the kubelet reports the resize state so you can tell whether it is in progress, completed, or deferred because the node lacks capacity. No rollout, no new ReplicaSet revision, no dropped traffic.

What changed in the Kubernetes 1.35 GA release?

The big one: memory limit decreases are now allowed. In earlier versions you could raise a memory limit but not lower it in place. Kubernetes 1.35 lifted that restriction, so you can shrink an over-provisioned pod’s memory without a restart.

There is a safety caveat worth knowing: when you decrease a memory limit, the kubelet only applies the resize if current usage is already below the new limit, to avoid an immediate OOM-kill. That check is best-effort, not a guarantee, so decrease memory in sensible steps rather than one aggressive jump. If you have been fighting OOMKills, pair this with our guide on how to fix OOMKilled in Kubernetes.

How does in-place resize save money?

By letting you right-size continuously instead of over-provisioning “just in case.” Most teams pad requests heavily because getting them wrong used to mean a restart, so they round up and forget. In-place resize removes the penalty for being precise.

Where the savings come from:

• Shrink the padding. Drop requests to match real P95 usage and reclaim the difference. 20-40% is a common result on clusters that have never been tuned.
• Fix under-provisioning without downtime. Bump a throttled or near-OOM pod up before it fails, instead of after an incident.
• Right-size stateful workloads. Resize a Postgres, Redis, or Kafka pod that previously could not be touched without a maintenance window.

This is the natural complement to autoscaling. HPA adds pods, VPA sets the right per-pod resources, and in-place resize is what finally lets VPA apply its recommendations without disruptive restarts. For the fuller cost picture, see our FinOps for Kubernetes cost optimization playbook and the broader Kubernetes cost optimization guide.

In-place resize vs the Vertical Pod Autoscaler: how do they fit?

They are complementary, not competing. VPA decides what a pod’s resources should be; in-place resize is the mechanism that applies the change without recreating the pod. Before 1.35, VPA’s “Auto” mode had to evict and restart pods to apply recommendations, which is why many teams ran it in recommendation-only mode.

The 2026 pattern we recommend:

• VPA in recommend mode to learn the right numbers from real usage. Our Kubernetes VPA guide covers the setup.
• In-place resize to apply them without restarts, either manually for critical workloads or via VPA’s updater on newer versions.
• Keep HPA for horizontal scaling where load is spiky. If you are unsure which autoscaler does what, we broke it down in Cluster Autoscaler vs HPA vs VPA.

What are the limits and gotchas?

It is not magic, and a few constraints matter in production:

• You cannot resize below current usage safely. The kubelet guards memory decreases, but plan your steps.
• Node capacity still applies. A resize that does not fit on the current node is deferred, not force-fit. The pod stays at its old size until capacity frees up.
• Not every field is mutable in place. You are changing CPU and memory requests and limits, not the whole pod spec.
• QoS class can shift. Changing requests and limits can move a pod between Guaranteed, Burstable, and BestEffort, which affects eviction order.

You also want your whole fleet on a recent Kubernetes version to rely on this. If you are behind, plan the upgrade using our zero-downtime Kubernetes upgrade guide so you can adopt 1.35 features cluster-wide.

Should you use in-place resize in production?

Yes, now that it is GA in 1.35 it is production-ready, and it is one of the highest-leverage, lowest-risk cost wins available in Kubernetes today. Start with non-critical, over-provisioned workloads, measure the reclaimed capacity, then extend to stateful services once your team is comfortable with the resize workflow. Read the official Kubernetes 1.35 in-place pod resize GA announcement for the full feature detail.

---

Turn In-Place Resize Into a Real Cost Reduction

In-place pod resize removes the last excuse for over-provisioning, but the savings only show up if you actually measure usage, set the right numbers, and roll the change out safely across a live fleet. That is the work most teams never get to.

Our team provides hands-on Kubernetes cost optimization to help you:

• Find the padding with per-pod, per-namespace utilization audits instead of guesswork
• Right-size without downtime using in-place resize and VPA, including stateful databases and caches
• Keep it tuned with autoscaling and continuous recommendations so the savings do not creep back

We run this on production clusters regularly, and our broader Kubernetes consulting team can implement it end to end or upskill yours to own it.

Get a Kubernetes right-sizing audit from Tasrie IT Services →