In-place pod resizing allows you to change the CPU and memory resources for containers within a running pod without application disruption. The standard methods for changing pod CPU and memory resources cause the pod to be re-created, potentially causing disruption. In-place pod resizing allows you to scale pod resources up or down without suffering the downtime or state loss associated with a pod restart.
When using in-place pod resizing to change CPU or memory resources, you can control whether a pod is restarted by configuring a resize policy in the pod specification. The following example resize policy requires a pod restart upon changing the memory resources, but prevents a restart for CPU resource changes.
Example resource policy
apiVersion: v1
kind: Pod
metadata:
name: resize-demo
spec:
securityContext:
runAsNonRoot: true
seccompProfile:
type: RuntimeDefault
containers:
- name: pause
# ...
resizePolicy: (1)
- resourceName: cpu
restartPolicy: NotRequired
- resourceName: memory
restartPolicy: RestartContainer
1 |
Specifies a resize policy. |
|
Memory limits cannot be decreased unless the resize policy for memory is RestartContainer .
|
You cannot add or modify a resize policy to an existing pod, but you can add or edit the policy in the pod’s owner object, such as a deployment, if the pod has an owner object.
Using in-place pod resizing requires that you use the --subresource resize
flag when editing a pod in the OpenShift CLI (oc
), as shown in the following examples:
Example commands
$ oc edit pod <pod_name> --subresource resize
$ apply -f <file_name>.yaml --subresource resize
$ patch pod <pod_name> --subresource resize --patch \
'{"spec":{"containers":[{"name":"pause", "resources":{"requests":{"cpu":"800m"}, "limits":{"cpu":"800m"}}}]}}'
Because you need to use the --subresource resize
flag with a resize policy, you cannot edit the pod resources in the OKD web console.
If the resize policy is NotRequired
and you change the request or limits, the pod is not restarted.
Example output
NAME READY STATUS RESTARTS AGE
resize-pod 1/1 Running 0 5s
If the resize policy is RestartContainer
and you change the request or limits, the pod is restarted.
Example output
NAME READY STATUS RESTARTS AGE
resize-pod 1/1 Running 1 (5s ago) 5s
After making the resource changes, the pod status conditions indicate the state of a resize request by using the following messages:
-
PodResizeInProgress
: The kubelet is able to allocate the requested resources and the change is being applied.
-
PodResizePending
: The kubelet cannot immediately make the change for one of the following reasons:
-
Infeasible
: The requested resize cannot be executed on the current node. For example, requesting more resources than the node has available would result in an Infeasible
condition.
-
Deferred
: The requested resize is currently not possible, but might become possible at a later time. For example, if another pod is removed from the node, the requested resources might become available. The kubelet retries the resize when conditions on the node change.
-
Error
: The kubelet is experiencing an error during the resource allocation and reports the reason for the error in the message field.
Example status for an infeasible change
apiVersion: v1
kind: Pod
metadata:
name: resize-demo
# ...
status:
conditions:
- lastProbeTime: "2025-09-03T15:00:50Z"
lastTransitionTime: "2025-09-03T15:00:50Z"
message: 'Node didn''t have enough capacity: cpu, requested: 1000000, capacity:
3500'
reason: Infeasible
status: "True"
type: PodResizePending
Note the following limitations:
-
In-place pod resizing is not supported for non-restartable init containers and ephemeral containers.
-
In-place pod resizing is not allowed if the changes violate other pod mutability constraints, such as the pod QoS class.
-
Pods managed by a static cpuManagerPolicy
or memoryManagerPolicy
parameter cannot be resized with in-place pod resizing.
-
Pods utilizing swap memory must use the RestartContainer
policy for memory requests with in-place pod resizing.