kubernetesautoscalingPractitioner

Mastering In-Place Resizing of Kubernetes Container Resources

5 min read Kubernetes DocsApr 27, 2026Reviewed for accuracy

Practitioner — Hands-on experience recommended

In Kubernetes, the ability to resize CPU and memory resources assigned to containers is crucial for maintaining application performance and resource efficiency. As workloads fluctuate, you need a mechanism to adapt resource allocations dynamically without incurring downtime. This feature allows you to adjust the desired resources for a running container, ensuring that your applications can scale effectively in response to real-time demands.

To resize resources, you modify the desired requests and limits in the Pod's specification. You can do this using commands like kubectl patch, kubectl apply, or kubectl edit, specifically targeting the Pod's resize subresource. When the desired resources differ from the allocated resources, the Kubelet will initiate a resize operation. Be mindful that the resizePolicy parameter controls whether a container should restart during resizing. Setting it to NotRequired allows for in-place resizing without a restart, which is often desirable for maintaining availability.

In production, you must consider several factors. Ensure your Kubernetes cluster is version 1.33 or later, and that your kubectl client is at least version 1.32 to utilize the --subresource=resize flag. Watch out for scenarios where memory limits are decreased while usage exceeds the requested limit; in such cases, the resize will be skipped, leaving the status in an "In Progress" state. Additionally, Windows pods do not support in-place resizing, and pods managed by static CPU or Memory manager policies cannot be resized in this manner.

Key takeaways

→Request a resize by updating the desired resources in the Pod's spec.
→Use `kubectl patch` with the `--subresource=resize` flag for in-place resizing.
→Set `resizePolicy` to `NotRequired` to avoid container restarts during resizing.
→Monitor memory usage before decreasing limits to prevent skipped resizes.
→Ensure your cluster and `kubectl` versions meet the minimum requirements for resizing.

Why it matters

In production, efficient resource management directly impacts application performance and cost. Resizing resources dynamically helps avoid over-provisioning and under-provisioning, ensuring optimal resource utilization.

Code examples

YAML

1apiVersion:v1
2kind:Pod
3metadata:
4  name: resize-demo
5  namespace: qos-example
6spec:
7  containers:
8  - name: pause
9    image: registry.k8s.io/pause:3.8
10    resizePolicy:
11    - resourceName: cpu
12      restartPolicy: NotRequired
13    # Default, but explicit here
14    - resourceName: memory
15      restartPolicy: RestartContainer
16    resources:
17      limits:
18        memory: "200Mi"
19        cpu: "700m"
20      requests:
21        memory: "200Mi"
22        cpu: "700m"

shell

kubectl create -f pod-resize.yaml -n qos-example

shell

# Wait a moment for the pod to be running
kubectl get pod resize-demo --output=yaml -n qos-example

When NOT to use this

Windows pods do not support in-place resize. Pods managed by static CPU or Memory manager policies cannot be resized in-place. The official docs don't call out specific anti-patterns here. Use your judgment based on your scale and requirements.

Want the complete reference?

Read official docs

Test what you just learned

Quiz questions written from this article

Take the quiz →

Better StackSponsor

Unified observability — logs, uptime monitoring, and on-call in one place. Used by 50,000+ engineering teams to ship faster and sleep better.

Try Better Stack free →

Mastering In-Place Resizing of Kubernetes Container Resources

Key takeaways

Why it matters

Code examples

When NOT to use this

More on this topic

Unlocking Efficiency: Amazon EKS Auto Mode Meets Istio Ambient Mesh

Scaling StarRocks on EKS: Harnessing KEDA and Karpenter for OLAP Efficiency

Scaling StarRocks on EKS: Harnessing KEDA and Karpenter for OLAP Power