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

Source: Kubernetes Blog

Following the graduation of Pod-Level Resources to Beta in v1.34 and the General Availability (GA) of In‑Place Pod Vertical Scaling in v1.35, the Kubernetes community is thrilled to announce that In‑Place Pod‑Level Resources Vertical Scaling has graduated to Beta in v1.36!

This feature is now enabled by default via the InPlacePodLevelResourcesVerticalScaling feature gate. It allows users to update the aggregate Pod resource budget (.spec.resources) for a running Pod, often without requiring a container restart.

Why Pod‑level in‑place resize?

The Pod‑level resource model simplifies management for complex Pods (such as those with sidecars) by allowing containers to share a collective pool of resources. In v1.36 you can now adjust this aggregate boundary on‑the‑fly.

This is particularly useful for Pods where containers do not have individual limits defined. Those containers automatically scale their effective boundaries to fit the newly resized Pod‑level dimensions, letting you expand the shared pool during peak demand without manual per‑container recalculations.

Resource inheritance and the resizePolicy

When a Pod‑level resize is initiated, the Kubelet treats the change as a resize event for every container that inherits its limits from the Pod‑level budget. To determine whether a restart is required, the Kubelet consults the resizePolicy defined within individual containers:

• Non‑disruptive Updates: If a container’s restartPolicy is set to NotRequired, the Kubelet attempts to update the cgroup limits dynamically via the Container Runtime Interface (CRI).
• Disruptive Updates: If set to RestartContainer, the container will be restarted to apply the new aggregate boundary safely.

Note: Currently, resizePolicy is not supported at the Pod level. The Kubelet always defers to individual container settings to decide if an update can be applied in‑place or requires a restart.

In this scenario, a Pod is defined with a 2 CPU pod‑level limit. Because the individual containers do not have their own limits defined, they share this total pool.

1. Initial Pod specification

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. The resize operation

To double the CPU capacity to 4 CPUs, apply a patch using the resize subresource:

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

Node‑Level reality: feasibility and safety

Applying a resize patch is only the first step. The Kubelet performs several checks and follows a specific sequence to ensure node stability.

1. The feasibility check

Before admitting a resize, the Kubelet verifies if the new aggregate request fits within the Node’s allocatable capacity. If the Node is overcommitted, the resize is not ignored; instead, the PodResizePending condition will reflect a Deferred or Infeasible status, providing immediate feedback on why the “envelope” hasn’t grown.

2. Update sequencing

To prevent resource “overshoot,” the Kubelet coordinates the cgroup updates in a specific order:

• When Increasing: The Pod‑level cgroup is expanded first, creating the “room” before the individual container cgroups are enlarged.
• When Decreasing: The container cgroups are throttled first, and only then is the aggregate Pod‑level cgroup shrunken.

Observability: tracking resize status

With the move to Beta, Kubernetes uses Pod Conditions to track the lifecycle of a resize:

• PodResizePending – The spec is updated, but the Node hasn’t admitted the change (e.g., due to capacity).
• PodResizeInProgress – The Node has admitted the resize (status.allocatedResources) but the changes aren’t yet fully applied to the cgroups (status.resources).

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

Constraints and requirements

• cgroup v2 only – Required for accurate aggregate enforcement.
• CRI support – Requires a container runtime that implements the UpdateContainerResources CRI call (e.g., containerd v2.0+ or CRI‑O).
• Feature gates – PodLevelResources, InPlacePodVerticalScaling, InPlacePodLevelResourcesVerticalScaling, and NodeDeclaredFeatures must be enabled.
• Linux only – Currently exclusive to Linux‑based nodes.

What’s next?

As we move toward General Availability (GA), the community is focusing on Vertical Pod Autoscaler (VPA) integration, enabling VPA to issue Pod‑level resource recommendations and trigger in‑place actuation automatically.

Getting started and providing feedback

We encourage you to test this feature and provide feedback via the standard Kubernetes communication channels:

• Slack: #sig-node
• Mailing list
• Open community issues/PRs