Resize CPU and Memory Resources assigned to Containers [page]deterministic
This page explains how to change the CPU and memory resource requests and limits assigned to a container *without recreating the Pod*.
Traditionally, changing a Pod's resource requirements necessitated deleting the existing Pod and creating a replacement, often managed by a [workload controller](/docs/concepts/workloads/controllers/). In-place Pod Resize allows changing the CPU/memory allocation of container(s) within a running Pod while potentially avoiding application disruption. The process for resizing Pod resources is covered in [Resize CPU and Memory Resources assigned to Pods](/docs/tasks/configure-pod-container/resize-pod-resources).
Key Concepts:
* Desired Resources: A container's `spec.containers[*].resources` represent the *desired* resources for the container, and are mutable for CPU and memory. * Actual Resources: The `status.containerStatuses[*].resources` field reflects the resources *currently configured* for a running container. For containers that haven't started or were restarted, it reflects the resources allocated upon their next start. * Triggering a Resize: You can request a resize by updating the desired `requests` and `limits` in the Pod's specification. This is typically done using `kubectl patch`, `kubectl apply`, or `kubectl edit` targeting the Pod's `resize` subresource. When the desired resources don't match the allocated resources, the Kubelet will attempt to resize the container. * Allocated Resources (Advanced): The `status.containerStatuses[*].allocatedResources` field tracks resource values confirmed by the Kubelet, primarily used for internal scheduling logic. For most monitoring and validation purposes, focus on `status.containerStatuses[*].resources`.
If a node has pods with a pending or incomplete resize (see [Pod Resize Status](#pod-resize-status) below), the [scheduler](#gloss:kube-scheduler) uses the *maximum* of a container's desired requests, allocated requests, and actual requests from the status when making scheduling decisions.
##
The `InPlacePodVerticalScaling` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) must be enabled for your control plane and for all nodes in your cluster.
The `kubectl` client version must be at least v1.32 to use the `--subresource=resize` flag.
## Pod resize status
The Kubelet updates the Pod's status conditions to indicate the state of a resize request:
* `type: PodResizePending`: The Kubelet cannot immediately grant the request. The `message` field provides an explanation of why. * `reason: Infeasible`: The requested resize is impossible on the current node (for example, requesting more resources than the node has). * `reason: Deferred`: The requested resize is currently not possible, but might become feasible later (for example if another pod is removed). The Kubelet will retry the resize. * `type: PodResizeInProgress`: The Kubelet has accepted the resize and allocated resources, but the changes are still being applied. This is usually brief but might take longer depending on the resource type and runtime behavior. Any errors during actuation are reported in the `message` field (along with `reason: Error`).
### How kubelet retries Deferred resizes
If the requested resize is _Deferred_, the kubelet will periodically re-attempt the resize, for example when another pod is removed or scaled down. If there are multiple deferred resizes, they are retried according to the following priority:
* Pods with a higher Priority (based on PriorityClass) will have their resize request retried first. * If two pods have the same Priority, resize of guaranteed pods will be retried before the resize of burstable pods. * If all else is the same, pods that have been in the Deferred state longer will be prioritized.
A higher priority resize being marked as pending will not block the remaining pending resizes from being attempted; all remaining pe …(trimmed)