Kubernetes v1.36: In-Place Vertical Scaling for Pod-Level Resources Graduates to Beta

Summary

Kubernetes v1.36 introduces the graduation of In-Place Pod-Level Resources Vertical Scaling to Beta. This feature allows developers to modify the aggregate resource budget (.spec.resources) of a running Pod, enabling dynamic resource adjustments without necessarily requiring container restarts.

Key Points

• Feature Status: In-Place Pod-Level Resources Vertical Scaling has graduated to Beta in Kubernetes v1.36.
• Default Configuration: The feature is enabled by default via the InPlacePodLevelResourcesVerticalScaling feature gate.
• Required Infrastructure: Implementation requires Linux-based nodes, cgroup v2, and a Container Runtime Interface (CRI) that supports the UpdateContainerResources call (e.g., containerd v2.0+ or CRI-O).
• Required Feature Gates: Operation requires PodLevelResources, InPlacePodVerticalScaling, InPlacePodLevelResourcesVerticalScaling, and NodeDeclaredFeatures to be enabled.
• Resize Mechanism: Updates are applied using the resize subresource via a patch operation on the Pod specification.
• Disruption Control: The resizePolicy defined at the container level determines if an update is non-disruptive (Not/Required) or requires a container restart (RestartContainer).

Technical Details

The feature allows for the management of a shared resource pool for Pods, which is particularly effective for Pods with sidecars where individual container limits are not explicitly defined. When a resize operation is initiated, the Kubelet evaluates the resizePolicy of each container to determine the update method. If set to NotRequired, the Kubelet attempts to dynamically update cgroup limits via the CRI. If set to RestartContainer, the Kubelet restarts the container to apply the new boundaries.

The Kubelet enforces a specific sequence of operations to maintain node stability and prevent resource overshoot. During a resource increase, the Pod-level cgroup is expanded first to create sufficient headroom before the individual container cgroups are enlarged. Conversely, during a resource decrease, the container cgroups are throttled before the aggregate Pod-level cgroup is shrunken.

To ensure feasibility, the Kubelet performs a check against the Node's allocatable capacity. If the new aggregate request cannot be accommodated due to node overcommitment, the PodResizePending condition will report a Deferred or Infeasible status. Developers can monitor the lifecycle of a resize through Pod Conditions: PodResizePending indicates the specification has been updated but not yet admitted by the Node, while PodResizeInProgress indicates the Node has admitted the change (reflected in status.allocatedResources) but the cgroup updates are still being applied (reflected in status.resources).

Impact / Why It Matters

This feature simplifies the management of complex Pods by allowing the adjustment of aggregate resource boundaries on-the-fly, reducing the need for manual per-container recalculations. It also provides the necessary infrastructure for future automated scaling via Vertical Pod Autoscaler (VPA) integration.