Kubernetes Can Now Resize Your Pods Without Restarting Them

Kubernetes 1.35 shipped in December 2025 with something the community has been asking for since the early days — the ability to change the CPU and memory of a running pod without killing and restarting it. It's called In-Place Pod Resize and it just hit stable (GA).

Before this, if you wanted to give a pod more resources, you had to edit the deployment and wait for a rolling restart. For stateless services that's fine. For anything stateful — databases, long-running jobs, ML training runs — a restart mid-operation is painful. This feature changes that.

1. What It Actually Does

When you update the resource requests or limits on a container spec, the kubelet now adjusts the underlying cgroup settings for that running container directly. No pod replacement. No scheduler dance. The container keeps running, and its resource allocation changes underneath it.

There's a new field in the container spec called resizePolicy that controls exactly what happens when each resource type changes:

containers:
- name: app
  resources:
    requests:
      cpu: "500m"
      memory: "512Mi"
    limits:
      cpu: "1"
      memory: "1Gi"
  resizePolicy:
  - resourceName: cpu
    restartPolicy: NotRequired
  - resourceName: memory
    restartPolicy: RestartContainer

With NotRequired, CPU changes apply instantly with no disruption. With RestartContainer, the container restarts in place — the pod stays, but the container inside gets a fresh start with the new memory limit.

2. How to Resize a Running Pod

Once your cluster is on 1.35, you can patch a pod's resources directly using kubectl. No need to touch the deployment — though in practice you'd also update the deployment spec to keep things consistent:

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

You can also watch the resize status live:

kubectl get pod my-app-pod -o jsonpath='{.status.resize}'

3. Tracking the Resize State

The pod status now includes a new resize field that shows what's happening in real time:

• InProgress — the kubelet is currently applying the change

• Deferred — the node doesn't have enough resources right now, but might later

• Infeasible — the request can't be satisfied on this node at all

If you see Deferred, the pod stays running at its old resource level while Kubernetes waits for capacity to free up. If you see Infeasible, you'll need to either scale down another workload or move the pod to a different node.

4. The Part People Miss

Memory resize is trickier than CPU resize. The Linux kernel doesn't let you just shrink a process's memory the same way you can throttle CPU. So if you try to reduce memory below what the container is actively using, the kubelet will make a best-effort attempt to avoid an OOM kill — but it doesn't guarantee it.

In practice: increasing memory is always safe. Decreasing memory should be done carefully, and only when you're confident the container isn't near its current limit.

5. Who Should Care About This

The teams who benefit most are the ones running workloads that can't afford a restart:

• Database pods that take minutes to warm up

• Long-running batch jobs or ML training

• Apps that need to scale up CPU for a short burst without disrupting live traffic

For typical stateless deployments, you probably won't use this much — rolling restarts are fine. But for the cases where restarts are expensive, in-place resize is a real quality-of-life improvement.

This feature was in alpha since Kubernetes 1.27, spent time in beta in 1.33, and is now stable in 1.35. It went through a lot of iteration, which shows — the implementation is solid and the edge cases are well-documented. If you run stateful workloads on Kubernetes, it's worth testing in your next cluster upgrade.