Kubernetes v1.36 Enhances Pod Resource Management with Default Vertical Scaling

Apr 30, 2026 672 views

Kubernetes has reached a significant milestone with the release of version 1.36, where the In-Place Vertical Scaling for Pod-Level Resources has officially graduated to Beta status. This enhancement builds on the previous iterations of the feature, first introduced in version 1.34 and subsequently reaching General Availability in version 1.35.

With this new phase, In-Place Vertical Scaling activates by default through the InPlacePodLevelResourcesVerticalScaling feature gate. It empowers users to modify the combined resource budget (.spec.resources) of an active Pod, often eliminating the need to restart containers.

Advantages of In-Place Resizing

The Pod-level resource model simplifies the complexity of Pods that include additional containers, known as sidecars, by allowing them to draw from a single resource pool. Version 1.36 enhances this capability further, permitting live adjustments to the resource limits. This is especially beneficial for Pods without individual resource limits, enabling the effective scaling of shared resources during peak workloads without manual recalibrations for each container.

Understanding Resize Policies

When a Pod's resources are altered, the Kubelet interprets this as a resize event for all containers that are linked to the Pod-level resource budget. Whether a container needs to restart during this adjustment depends on the specified resizePolicy:

Non-disruptive Updates: Containers marked with restartPolicy set to NotRequired enable dynamic limit adjustments via the Container Runtime Interface (CRI) without restarts.
Disruptive Updates: Those adopting RestartContainer will necessitate a restart to properly apply the new resource settings.

Important: The current implementation does not support resizePolicy configurations at the Pod level; individual container settings govern the operational decisions.

Demonstrating Resource Scaling

Consider a scenario where a Pod is initially set with a total CPU limit of 2. Given that there are no distinct limits for each container, all containers will share this limit:

1. Initial Pod Setup

apiVersion: v1
kind: Pod
metadata:
 name: shared-pool-app
spec:
 resources: # Pod-level limits
 limits:
 cpu: "2"
 memory: "4Gi"
 containers:
 - name: main-app
 image: my-app:v1
 resizePolicy: [{resourceName: "cpu", restartPolicy: "NotRequired"}]
 - name: sidecar
 image: logger:v1
 resizePolicy: [{resourceName: "cpu", restartPolicy: "NotRequired"}]

2. Executing the Resize

To increase the CPU capacity to 4, apply the following patch using the resize subresource:

kubectl patch pod shared-pool-app --subresource resize --patch \
 '{"spec":{"resources":{"limits":{"cpu":"4"}}}}'

Ensuring Node Safety

Executing a resize patch is just the beginning. The Kubelet must perform rigorous checks to guarantee node stability:

1. Assessment of Feasibility

Before a resize is approved, the Kubelet ensures that the new aggregate request adheres to the Node's allocatable limits. If the Node is overcommitted, it doesn’t simply reject the request; instead, it reflects a PodResizePending status alongside a Deferred or Infeasible message, offering clarity on the inability to fulfill the request.

2. Sequencing Updates

The Kubelet manages resource updates methodically to prevent issues:

Increasing Resources: The Pod-level cgroup is expanded first, allowing additional capacity before adjusting individual container cgroups.
Decreasing Resources: Container cgroups are throttled prior to reducing the overall Pod-level allocation.

Observing the Resize Process

This Beta update introduces Pod Conditions to monitor resize activities:

PodResizePending: Indicates that the state has been updated, yet the Node hasn’t accepted the changes.
PodResizeInProgress: Denotes that while the Node has accepted the resize, the alterations have not fully been implemented in the cgroups.

status:
 allocatedResources:
 cpu: "4"
 resources:
 limits:
 cpu: "4"
 conditions:
 - type: PodResizeInProgress
 status: "True"

Requirements and Limitations

cgroup v2 Required: Necessary for accurate management of resource limits.
CRI Compatibility Required: A container runtime must support UpdateContainerResources (e.g., containerd v2.0+ or CRI-O).
Feature Gates: Needs activation of PodLevelResources, InPlacePodVerticalScaling, InPlacePodLevelResourcesVerticalScaling, and NodeDeclaredFeatures.
Linux Environment Only: Currently applicable exclusively to Linux nodes.

Looking Ahead

As the community gears up for General Availability (GA), a key focus will be on integrating the Vertical Pod Autoscaler (VPA) to automatically generate resource recommendations and trigger in-place adjustments.

Community Engagement

Users are encouraged to test the new feature and share their feedback through various Kubernetes communication channels:

Source: David Miller · kubernetes.io

Comments

No comments yet. Be the first to comment.