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

Why It Matters

Live vertical scaling reduces downtime and operational overhead for complex, sidecar‑rich workloads, improving cluster efficiency and cost management. It paves the way for tighter integration with the Vertical Pod Autoscaler, automating resource right‑sizing.

Key Takeaways

• Beta in‑place pod‑level vertical scaling enabled by default in v1.36
• ResizePolicy controls whether containers restart or update cgroup limits
• Kubelet validates node capacity before applying a resize patch
• cgroup v2 and CRI runtimes like containerd v2+ are required
• PodResizePending and PodResizeInProgress conditions expose resize status

Pulse Analysis

Kubernetes continues to evolve its resource management capabilities, and the v1.36 beta for In‑Place Pod‑Level Resources Vertical Scaling marks a pivotal step. By allowing administrators to adjust a pod’s collective CPU and memory limits on the fly, the platform reduces the need for disruptive container restarts. This is especially valuable for multi‑container pods that share a common resource pool, such as sidecar‑heavy microservices, where per‑container limits are often omitted. The feature builds on the pod‑level resource model introduced in v1.34 and leverages the existing In‑Place Pod Vertical Scaling introduced in v1.35, delivering a more seamless scaling experience.

Technical adoption hinges on a few prerequisites. The node must run Linux with cgroup v2, and the container runtime must support the UpdateContainerResources CRI call—containerd v2.0+ or CRI‑O are typical choices. When a resize request is issued via the resize subresource, the Kubelet first checks node allocatable capacity, then orchestrates cgroup adjustments in a safe order: expanding the pod‑level cgroup before container cgroups when scaling up, and throttling containers before shrinking the pod cgroup when scaling down. Each container’s resizePolicy—NotRequired for live updates or RestartContainer for a restart—guides the Kubelet’s decision, and the new PodConditions (PodResizePending, PodResizeInProgress) give operators clear visibility into the operation’s state.

Looking ahead, the community is targeting General Availability and tighter integration with the Vertical Pod Autoscaler (VPA). Once VPA can emit pod‑level recommendations, it will be able to trigger these in‑place adjustments automatically, closing the loop on dynamic workload scaling. Early adopters are encouraged to test the beta, provide feedback through SIG‑Node Slack or the mailing list, and monitor the evolving feature gates. As the ecosystem matures, in‑place vertical scaling promises to simplify capacity planning, lower latency during peak loads, and reduce the operational cost of running large, heterogeneous workloads on Kubernetes.