Resize CPU and Memory Resources assigned to Pods [page]deterministic

This page explains how to change the CPU and memory resources set at the Pod level without recreating the Pod.

The In-place Pod Resize feature allows modifying resource allocations for a running Pod, avoiding application disruption. The process for resizing individual container resources is covered in [Resize CPU and Memory Resources assigned to Containers](/docs/tasks/configure-pod-container/resize-container-resources).

This page highlights In-place Pod-level resources resize. Pod-level resources are defined in `spec.resources` and they act as the upper bound on the aggregate resources consumed by all containers in the Pod. The In-place Pod-level resources resize feature lets you change these aggregate CPU and memory allocations for a running Pod directly.

##

The following [feature gates](/docs/reference/command-line-tools-reference/feature-gates/) must be enabled for your control plane and for all nodes in your cluster:

* [`InPlacePodLevelResourcesVerticalScaling`](/docs/reference/command-line-tools-reference/feature-gates/#InPlacePodLevelResourcesVerticalScaling) * [`PodLevelResources`](/docs/reference/command-line-tools-reference/feature-gates/#PodLevelResources) * [`InPlacePodVerticalScaling`](/docs/reference/command-line-tools-reference/feature-gates/#InPlacePodVerticalScaling) * [`NodeDeclaredFeatures`](/docs/reference/command-line-tools-reference/feature-gates/#NodeDeclaredFeatures)

The kubectl client version must be at least v1.32 to use the `--subresource=resize` flag.

## Pod Resize Status and Retry Logic

The mechanism the `kubelet` uses to track and retry resource changes is shared between container-level and Pod-level resize requests.

The statuses, reasons, and retry priorities are identical to those defined for container resize:

* Status Conditions: The `kubelet` uses PodResizePending (with reasons like Infeasible or Deferred) and PodResizeInProgress to communicate the state of the request.

* Retry Priority: Deferred resizes are retried based on PriorityClass, then QoS class (Guaranteed over Burstable), and finally by the duration they have been deferred.

* Tracking: You can use the `observedGeneration` fields to track which Pod specification (metadata.generation) corresponds to the status of the latest processed resize request.

For a full description of these conditions and retry logic, please refer to the [Pod resize status](/docs/tasks/configure-pod-container/resize-container-resources/#pod-resize-status) section in the container resize documentation.

## Container Resize Policy and Pod-Level Resize

Pod-level resource resize does not support or require its own restart policy.

* No Pod-Level Policy: Changes to the Pod's aggregate resources (spec.resources) are always applied in-place without triggering a restart. This is because Pod-level resources act as an overall constraint on the Pod's cgroup and do not directly manage the application runtime within containers.

* [Container Policy](/docs/tasks/configure-pod-container/resize-container-resources/#container-resize-policies) Still Governs: The resizePolicy must still be configured at the container level (spec.containers[*].resizePolicy). This policy governs whether an individual container is restarted when its resource requests or limits change, regardless of whether that change was initiated by a direct container-level resize or by an update to the overall Pod-level resource envelope.

## Limitations

For Kubernetes , resizing Pod-level resources in-place is subject to all the limitations described for container-level resource resize, which you can find here: [Resize CPU and Memory Resources assigned to Containers: Limitations](/docs/tasks/configure-pod-container/resize-container-resources/#limitations).

Additionally, the following constraint is specific to Pod-level resource resize: * Container Requests Validation: A resize is only permitted if the resulting Pod-level resource requests (spec.resources.requests) are greater than or eq …(trimmed)