Mastering In-Place Resizing of Kubernetes Container Resources
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
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"kubectl create -f pod-resize.yaml -n qos-example# Wait a moment for the pod to be running
kubectl get pod resize-demo --output=yaml -n qos-exampleWhen 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 docsIndustry-standard certifications built by the people behind Linux and Kubernetes. Earn the CKA — the gold standard Kubernetes administrator cert. OpsCanary readers get 30% off year-round with code OPSCANARY3.
Get CKA certified →Kubernetes v1.37: Mastering the New Features for Resilience and Efficiency
Kubernetes v1.37 introduces critical features that enhance resilience and efficiency in your clusters. Notably, the HorizontalPodAutoscaler can now scale down to zero Pods when idle, optimizing resource usage. Dive in to understand how these updates can transform your production environment.
Mastering Advanced Kubernetes Control Plane Config in Amazon EKS
Unlock the full potential of your Kubernetes control plane with advanced configuration options in Amazon EKS. Learn how to optimize pod scheduling with scoring strategies like MostAllocated and LeastAllocated, and fine-tune your Horizontal Pod Autoscaler for rapid scaling.
Mastering EKS Auto Mode: Automated Node Failure Management
Node failures can cripple your Kubernetes clusters, but Amazon EKS Auto Mode offers a robust solution. It automatically detects, drains, and replaces failing nodes, leveraging the Node Monitoring Agent and Karpenter for seamless operation.
Get the daily digest
One email. 5 articles. Every morning.
No spam. Unsubscribe anytime.