Red Hat OpenShift, the most popular container orchestration platform, has always provided flexibility, scalability, and resilience. As workloads evolve, so do the requirements for resources such as CPU and memory. Traditionally, adjusting these resources for a running pod meant recreating the pod. However, with the concept of in-place resource resizing, this is changing. Let's dive into what in-place resource resizing is and why it's a game-changer for OpenShift users.
This feature was alpha in Kubernetes 1.27 and behind a feature gate in OpenShift versions through 4.19, but has graduated to beta in Kubernetes 1.33 and is on by default in OpenShift 4.20.
What is in-place resource resize?
In-place resource resize refers to the ability to adjust the CPU and memory requests and limits of a running Pod without the need to recreate it. This feature allows for more dynamic resource management, ensuring that applications can be allocated more or fewer resources based on their current needs without causing disruptions.
Why is it important?
Recreating a Pod to adjust its resources can lead to downtime, especially if the pod is part of a StatefulSet or if it's handling critical tasks. In-place resizing reduces this downtime, ensuring smoother operations.
Over-provisioning resources can lead to wastage, while under-provisioning can cause performance issues. Dynamic resizing ensures that resources are used efficiently, based on real-time needs.
Efficient resource utilization can lead to cost savings, especially in cloud environments where you pay for the resources you use.
There is no need to manually intervene and recreate pods or adjust deployment configurations. This simplifies the operational overhead.
How does it work?
For our purposes, you need to create a pod whose container limits and resources differ so it isn't assigned the “Guaranteed” QoS class. Resize is not allowed if it would violate other pod mutability constraints, and the pod’s QoS class is still immutable.
apiVersion: v1
kind: Pod
metadata:
name: resizeme
spec:
containers:
- name: resizeme
image: ubi9/ubi
command: ["tail", "-f", "/dev/null"]
resources:
requests:
cpu: 1
memory: "512Mi"
limits:
cpu: 2
memory: "1Gi"Observe the allocatedResources fields in the containerStatuses:
$ oc get pod resizeme -o yaml
...
containerStatuses:
- allocatedResources:
cpu: "1"
memory: 512MiTheir presence indicates the availability of in-place resize.
Note: In Alpha, ResizePolicy fields were additionally always populated by default, but this is no longer the case. The fields are still available but implicit defaults are assumed.
Resize The Container’s Resources: Change the pod’s CPU request from 1 to 2. You can also use oc edit to make a change, but be mindful that you include the --subresource=resize argument.
$ oc patch pod resizeme -p '{"spec": {"containers": [{"name": "resizeme", "resources": { "requests" :{ "cpu" : 2, "memory": "512Mi"}, "limits" :{ "cpu" : 2, "memory" : "1Gi" } } }] }}' --subresource=resizeNote: Previous iterations of this feature allowed you to edit the pod spec without having to specify the resize subresource, but the behavior has changed and you now have to specify the subresource. Additionally, the resize subresource is only available in kubectl version 1.33 / oc version 4.20 or greater, so make sure you are using a new enough client. If your client is too old, or you fail to specify the resize subresource, you will receive the following:
The Pod "resizeme" is invalid: spec: Forbidden: pod updates may not change fields other than `spec.containers[*].image`,`spec.initContainers[*].image`,`spec.activeDeadlineSeconds`,`spec.tolerations` (only additions to existing tolerations),`spec.terminationGracePeriodSeconds` (allow it to be set to 1 if it was previously negative)Watch the pod react. The resize happens quickly in most cases if it’s feasible, but you might be able to catch it by looking at the pod conditions.
$ oc get pod resizeme -o json | jq '.status.conditions[] | select(.type | test("PodResizePending|PodResizeInProgress|PodResizeInfeasible|PodResizeDeferred|Resizing"))
{
"lastProbeTime": "2025-09-20T01:01:18Z",
"lastTransitionTime": "2025-09-20T01:01:18Z",
"status": "True",
"type": "PodResizeInProgress"
}Observe the successful resize. Eventually, once the resize is complete, your resource changes will be reflected in container status:
$ oc get pods resizeme -o yaml
...
containerStatuses:
- allocatedResources:
cpu: "2"
memory: 512Mi
containerID: cri-o://5076fa4d8cddea4d2d219b51f6ce31b510c59b1abbe300e7e6ce69ca70848f69
image: registry.access.redhat.com/ubi9/ubi:latest
imageID: registry.access.redhat.com/ubi9/ubi@sha256:03215fe3630a1b49a00e1b1918d063fe82b7197d342b5c253fe2255fc8027ea3
lastState: {}
name: resizeme
ready: true
resources:
limits:
cpu: "2"
memory: 1Gi
requests:
cpu: "2"
memory: 512Mi
restartCount: 0You can find more details on configuration options and constraints upstream.
Limitations and considerations
While in-place resource resizing offers numerous benefits, there are some considerations. Not all resources can be adjusted. While CPU and memory can be adjusted, other resources like storage are not currently supported for in-place resizing.
There is potential for resource contention. If resources are reduced too aggressively, it might lead to resource contention among pods.
As far as compatibility with container runtimes, ensure that your container runtime supports dynamic resource adjustments.
Summary
In-place resource resizing for OpenShift pods spec is a step towards more dynamic and efficient resource management. As OpenShift continues to evolve, features like this highlight its adaptability and responsiveness to the needs of modern applications and infrastructures. As always, while leveraging such features, it's essential to monitor and manage resources wisely to ensure optimal performance and cost-efficiency.
