Kubernetes 1.35 In-Place Pod Resize: The Complete Guide to Resizing Without Restarts

For years, the biggest complaint about Kubernetes resource management was simple: you can't change CPU or memory on a running pod without restarting it.

Want to give a pod more memory because it's approaching its limit? Restart. Want to reduce CPU on an over-provisioned workload? Restart. Running a JVM that took 2 minutes to warm up? Too bad — restart.

That era is officially over. In-Place Pod Resize graduated to GA in Kubernetes 1.35, and it changes how we think about resource management in Kubernetes.

What Is In-Place Pod Resize?

In-Place Pod Resize allows you to modify a pod's CPU and memory resource requests and limits while the pod is running — no restart required.

Before this feature, the only way to change resources was:

1. Update the Deployment spec
2. Kubernetes kills the old pod
3. Kubernetes creates a new pod with new resources
4. Application restarts from scratch

Now, you can patch a running pod's resources, and the Linux kernel adjusts the cgroup limits on the fly. The container keeps running without interruption.

How It Works Under the Hood

When you resize a pod:

1. You patch the pod's spec.containers[*].resources field
2. The kubelet receives the update
3. Kubelet updates the container's cgroup limits in the Linux kernel
4. The container process doesn't even know it happened

For CPU, this is seamless — the cgroup CPU quota changes immediately.

For memory, it's slightly more nuanced:

• Increasing memory: Always succeeds if the node has capacity
• Decreasing memory: Only succeeds if the container is using less than the new limit

Trying It Out

Prerequisites

• Kubernetes 1.35+ (feature gate InPlacePodVerticalScaling is enabled by default)
• Container runtime: containerd 1.7+ or CRI-O 1.28+

Step 1 — Create a Pod with Resize Policy

apiVersion: v1
kind: Pod
metadata:
  name: resize-demo
spec:
  containers:
  - name: app
    image: nginx:1.27
    resources:
      requests:
        cpu: 100m
        memory: 128Mi
      limits:
        cpu: 200m
        memory: 256Mi
    resizePolicy:
    - resourceName: cpu
      restartPolicy: NotRequired
    - resourceName: memory
      restartPolicy: NotRequired

The resizePolicy field tells Kubernetes whether a restart is needed for each resource type. NotRequired means in-place resize — RestartContainer means the container restarts on change.

Step 2 — Resize the Pod

Increase CPU and memory without restarting:

kubectl patch pod resize-demo --subresource resize --patch '{
  "spec": {
    "containers": [{
      "name": "app",
      "resources": {
        "requests": {"cpu": "200m", "memory": "256Mi"},
        "limits": {"cpu": "400m", "memory": "512Mi"}
      }
    }]
  }
}'

Step 3 — Check the Resize Status

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

Possible values:

• Proposed — resize requested, not yet applied
• InProgress — kubelet is applying changes
• Deferred — insufficient resources on node, will retry
• Infeasible — resize cannot be fulfilled (e.g., exceeds node capacity)
• Empty — resize completed successfully

Verify the actual resources:

kubectl get pod resize-demo -o jsonpath='{.status.containerStatuses[0].resources}'

Using In-Place Resize with Deployments

In-Place Pod Resize works at the pod level. When you update a Deployment's resource spec, Kubernetes still does a rolling update (creating new pods). To resize without rolling updates, patch pods directly.

However, you can combine it with VPA (Vertical Pod Autoscaler) for automatic in-place resizing.

VPA with In-Place Resize Mode

VPA now supports a new update mode: InPlaceOrRecreate. This tells VPA to try in-place resize first, and only restart the pod if in-place isn't possible.

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: my-app-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  updatePolicy:
    updateMode: "InPlaceOrRecreate"
  resourcePolicy:
    containerPolicies:
    - containerName: app
      minAllowed:
        cpu: 50m
        memory: 64Mi
      maxAllowed:
        cpu: 2000m
        memory: 4Gi

With this configuration:

1. VPA monitors your workload's actual resource usage
2. When it recommends a change, it patches the pod's resources in-place
3. If in-place resize fails (e.g., Infeasible), it falls back to evicting and recreating the pod
4. No more surprise restarts for resource adjustments

Install VPA with in-place support:

git clone https://github.com/kubernetes/autoscaler.git
cd autoscaler/vertical-pod-autoscaler
./hack/vpa-up.sh

Real-World Use Cases

Java/JVM Applications

JVM apps take minutes to warm up. Before in-place resize, scaling resources meant cold starts. Now:

# App is hitting memory limits, increase without restart
kubectl patch pod java-app-abc123 --subresource resize --patch '{
  "spec": {
    "containers": [{
      "name": "java-app",
      "resources": {
        "requests": {"memory": "2Gi"},
        "limits": {"memory": "4Gi"}
      }
    }]
  }
}'

The JVM keeps running with its warm caches, compiled code, and established connections.

Batch Processing Jobs

Jobs that need different resources at different stages:

# Data loading phase - need more memory
kubectl patch pod batch-job-xyz --subresource resize --patch '{
  "spec": {"containers": [{"name": "worker", "resources": {"limits": {"memory": "8Gi"}}}]}
}'
 
# Processing phase - need more CPU
kubectl patch pod batch-job-xyz --subresource resize --patch '{
  "spec": {"containers": [{"name": "worker", "resources": {"limits": {"cpu": "4"}}}]}
}'

Traffic Spike Handling

Scale pod resources during known peak periods:

# Before Black Friday sale
for pod in $(kubectl get pods -l app=web -o name); do
  kubectl patch $pod --subresource resize --patch '{
    "spec": {"containers": [{"name": "web", "resources": {"limits": {"cpu": "2", "memory": "2Gi"}}}]}
  }'
done
 
# After peak
for pod in $(kubectl get pods -l app=web -o name); do
  kubectl patch $pod --subresource resize --patch '{
    "spec": {"containers": [{"name": "web", "resources": {"limits": {"cpu": "500m", "memory": "512Mi"}}}]}
  }'
done

Limitations to Know

1. Node capacity — you can't resize beyond what the node can offer. If the node is at capacity, the resize is Deferred or Infeasible.

2. Memory decrease — reducing memory limits only works if current usage is below the new limit. Otherwise, you risk OOMKill.

3. Init containers — resize doesn't apply to init containers (they've already run).

4. Resource quotas — resizes must stay within namespace ResourceQuota limits.

5. Pod overhead — resize doesn't change pod overhead (used by sandbox containers in kata/gVisor).

Monitoring Resizes

Track resize events with Prometheus:

# Count of resize operations
kube_pod_container_status_last_resize_status
 
# Pods with pending resizes
kube_pod_container_resource_resize_status{status="Deferred"}

Or simply watch for resize events:

kubectl get events --field-selector reason=Resized -w

Quick Reference

Wrapping Up

In-Place Pod Resize is one of the most impactful Kubernetes features in years. No more restarting pods just to change resource allocations. No more cold starts for JVM apps. No more VPA-induced evictions.

Combined with VPA's new InPlaceOrRecreate mode, you get truly seamless vertical autoscaling — the cluster adjusts resources on the fly based on actual workload needs.

If you're on Kubernetes 1.35+, start using it today. Your Java developers will thank you.

Want to master Kubernetes resource management, autoscaling, and production-grade cluster operations with hands-on labs? The KodeKloud Kubernetes course covers VPA, HPA, resource quotas, and real-world scaling strategies. Need a cluster to try in-place resize? DigitalOcean Kubernetes runs the latest Kubernetes versions with one-click upgrades.