Resize Kubernetes Pods Without Restart (2026 Guide)

You can change a running pod's CPU and memory in place by patching its resize subresource — kubectl patch pod <name> --subresource resize. CPU applies with no restart by default; memory restarts the container only if you set resizePolicy: RestartContainer. The pod is never recreated.

TL;DR

In-place pod resize lets you raise or lower a container's CPU and memory requests and limits on a running pod without recreating it.¹ It reached stable (GA) in Kubernetes v1.35² (released December 2025³) and is on by default through the InPlacePodVerticalScaling feature gate; the current release as of writing is v1.36 "Haru"⁴. You trigger a resize through the pod's resize subresource with kubectl patch ... --subresource resize (the --subresource flag needs kubectl v1.32+).⁵ CPU resizes apply transparently; memory resizes update the cgroup in place unless you opt into a container restart via resizePolicy. The QoS class never changes, and a handful of pods (Windows, static-policy, non-restartable init containers) can't be resized at all.² This guide is verified against the official Kubernetes v1.35/v1.36 documentation as of 16 June 2026.

What you'll learn

• What in-place pod resize is and which Kubernetes version made it GA
• How to resize a pod's CPU without restarting it, step by step with kubectl
• How to resize memory, and why it can still restart the container
• What the resizePolicy field does (NotRequired vs RestartContainer)
• Whether a resize changes the pod's QoS class
• How to read resize status with the PodResizePending and PodResizeInProgress conditions
• The limitations that make some pods un-resizable
• How autoscalers (HPA, VPA) relate to in-place resize
• How resizing differs from editing a Deployment

What is in-place pod resize in Kubernetes?

In-place pod resize is the ability to change the CPU and memory requests and limits of a container in a running pod without deleting and recreating that pod.¹ Historically spec.containers[*].resources was immutable: any change forced the workload controller to roll out replacement pods. The feature makes those fields mutable for CPU and memory, with the kubelet applying the change to the live container.²

The desired values live in spec.containers[*].resources as before; the actual values currently applied to the container are reported separately in status.containerStatuses[*].resources, so you can tell whether a requested resize has taken effect yet.²

Which Kubernetes version made in-place pod resize GA?

In-place pod resize graduated to stable (GA) in Kubernetes v1.35.² It first appeared as alpha in v1.27 (May 2023)⁶, moved to beta and on-by-default in v1.33 (May 2025)⁷, and reached GA in v1.35, which shipped on 17 December 2025.³ The controlling feature gate is InPlacePodVerticalScaling. The current Kubernetes release at the time of writing is v1.36 "Haru" (22 April 2026).⁴

Note one easy point of confusion: container-level resize (this guide) is GA in v1.35, while pod-level resource resize — changing the aggregate spec.resources for the whole pod — is a separate, newer feature that is beta in v1.36.⁸

How do I resize a pod's CPU without restarting it?

Use kubectl patch against the pod's resize subresource. CPU defaults to in-place application, so no restart happens.² First create a small pod:

# resize-demo.yaml
apiVersion: v1
kind: Pod
metadata:
  name: resize-demo
spec:
  containers:
    - name: app
      image: nginx:1.30
      resizePolicy:
        - resourceName: cpu
          restartPolicy: NotRequired
        - resourceName: memory
          restartPolicy: NotRequired
      resources:
        requests:
          cpu: "250m"
          memory: "256Mi"
        limits:
          cpu: "500m"
          memory: "512Mi"

kubectl apply -f resize-demo.yaml

Now bump the CPU on the running pod through the resize subresource:

kubectl patch pod resize-demo --subresource resize --patch \
  '{"spec":{"containers":[{"name":"app","resources":{"requests":{"cpu":"800m"},"limits":{"cpu":"800m"}}}]}}'

Confirm the container was not restarted and the new CPU is live:

# restartCount stays the same
kubectl get pod resize-demo -o jsonpath='{.status.containerStatuses[0].restartCount}{"\n"}'

# actual applied resources, as opposed to the desired spec
kubectl get pod resize-demo \
  -o jsonpath='{.status.containerStatuses[0].resources}{"\n"}'

The --subresource resize flag requires a kubectl client of v1.32 or newer; pair it with a v1.35+ cluster for the GA behavior.⁵

How do I resize pod memory, and why might it still restart?

Resizing memory works the same way — patch the resize subresource — but whether the container restarts depends on its resizePolicy for memory.² With the default NotRequired, the kubelet just updates the memory cgroup in place. With RestartContainer, the kubelet restarts that container (the pod is not recreated) so the process re-reads its memory settings:

kubectl patch pod resize-demo --subresource resize --patch \
  '{"spec":{"containers":[{"name":"app","resources":{"requests":{"memory":"512Mi"},"limits":{"memory":"1Gi"}}}]}}'

The common gotcha: many runtimes size their heap once at startup. A JVM launched with a fixed -Xmx, for example, will not use additional memory just because the cgroup limit grew — it needs a restart to pick up the new ceiling. For those workloads, set restartPolicy: RestartContainer on the memory resource so the resize actually takes effect.⁹ Memory limit decreases — once blocked — became allowed during the beta period (in v1.34): the kubelet makes a best-effort attempt to avoid OOM-kills, and if the container is already using more than the proposed limit the resize stays in progress rather than applying.²¹⁰

What is the resizePolicy field (NotRequired vs RestartContainer)?

resizePolicy is a per-resource list on a container that tells the kubelet how to apply a resize.² Each entry pairs a resourceName (cpu or memory) with a restartPolicy:

If you omit resizePolicy, it defaults to NotRequired for both CPU and memory.² Because that default silently grows memory without restarting the process, be explicit about memory policy when your app needs a restart to use it.

Does resizing a pod change its QoS class?

No. A pod's Quality of Service class — Guaranteed, Burstable, or BestEffort — is fixed when the pod is created and a resize cannot change it.² Your new values must still satisfy the original class: a Guaranteed pod must keep requests equal to limits for both CPU and memory after the resize, or the request is rejected.¹¹ This is why you sometimes need to patch both requests and limits together, as in the CPU example above.

How do I check the status of a resize?

Watch two pod conditions and the actual applied resources.² A resize that can't be completed immediately surfaces as PodResizePending, with a reason:

• Infeasible — the request can never be satisfied on this node (for example it exceeds node capacity, or the pod uses a static resource-manager policy).²
• Deferred — the resize is feasible in principle but can't be done right now (the node lacks free room), so the kubelet re-evaluates it later, prioritizing by PriorityClass, QoS class, and how long the resize has waited.²

While the kubelet is applying an accepted resize, the pod shows PodResizeInProgress.² Inspect everything with:

kubectl describe pod resize-demo        # shows conditions and events
kubectl get pod resize-demo \
  -o jsonpath='{.status.containerStatuses[0].resources}{"\n"}'   # actual values

Compare status.containerStatuses[*].resources (actual) against spec.containers[*].resources (desired) to confirm the change landed.²

What are the limitations of in-place pod resize?

The feature is deliberately scoped. As of v1.35/v1.36 you cannot:²

• Resize anything other than CPU and memory in place.
• Change the pod's QoS class.
• Resize non-restartable init containers or ephemeral containers (restartable sidecar containers can be resized).
• Resize pods pinned by the static CPU manager or static Memory manager policies — those resizes are marked Infeasible.
• Use it on Windows pods, which are not supported.

A resize that exceeds the node's allocatable capacity also stays pending as Infeasible until you free space or the request is reduced.²

Can I autoscale with in-place resize (HPA or VPA)?

The Horizontal Pod Autoscaler is unrelated: it scales the number of replicas, not the resources of a single pod, and does not use in-place resize.² Vertical autoscaling is where in-place resize fits. The Vertical Pod Autoscaler can apply recommendations through an InPlaceOrRecreate mode that resizes in place when possible and falls back to evict-and-recreate otherwise — but that mode is alpha (behind a VPA feature gate, off by default) as of 2026, so treat it as experimental rather than production-ready.¹²

How is resizing different from editing a Deployment?

Editing the resources in a Deployment (or any pod template) changes the template, which triggers a rolling replacement: Kubernetes spins up new pods with the new resources and tears down the old ones. The resize subresource instead patches the already-running pod, with no new pod and — for CPU, or memory under NotRequired — no restart at all.² For day-2 right-sizing of long-running or stateful workloads, that difference is the whole point. If you do want a controlled rollout instead, see our guide on zero-downtime deployments in Kubernetes.

Bottom line

In-place pod resize turns CPU and memory into something you can tune on a live pod instead of a reason to roll the whole workload. Start with resizePolicy set explicitly per resource, drive changes through the resize subresource, and watch status.containerStatuses[*].resources plus the PodResize* conditions to confirm they land. It pairs naturally with native sidecar containers for resource-tuning helper containers, and with the Gateway API migration guide as part of a broader modern-Kubernetes toolkit. For autoscaling, keep an eye on the VPA's in-place mode, but don't rely on it in production until it leaves alpha.