This release marks a major step: more than 6 years after its initial conception, the In-Place Pod Resize feature (also known as In-Place Pod Vertical Scaling), first introduced as alpha in Kubernetes v1.27, and graduated to beta in Kubernetes v1.33, is now stable (GA) in Kubernetes 1.35!
This graduation is a major milestone for improving resource efficiency and flexibility for workloads running on Kubernetes.
In the past, the CPU and memory resources allocated to a container in a Pod were immutable. This meant changing them required deleting and recreating the entire Pod. For stateful services, batch jobs, or latency-sensitive workloads, this was an incredibly disruptive operation.
In-Place Pod Resize makes CPU and memory requests and limits mutable, allowing you to adjust these resources within a running Pod, often without requiring a container restart.
Key Concept:
spec.containers[*].resources field now represents the desired
resources. For CPU and memory, these fields are now mutable.status.containerStatuses[*].resources field reflects the resources currently
configured for a running container.requests
and limits in the Pod's specification by utilizing the new resize subresource.Detailed usage instructions and examples are provided in the official documentation: Resize CPU and Memory Resources assigned to Containers.
In-place Pod Resize is a foundational building block that unlocks seamless, vertical autoscaling and improvements to workload efficiency.
InPlaceOrRecreate update mode, which leverages this
feature, has graduated to beta. This allows resources to be adjusted automatically and seamlessly based on
usage with minimal disruption.Here are a few examples of some use cases:
Since the initial beta in v1.33, development effort has primarily been around stabilizing the feature and improving its usability based on community feedback. Here are the primary changes for the stable release:
The graduation of In-Place Pod Resize to stable opens the door for powerful integrations across the Kubernetes ecosystem. There are several areas for futher improvement that are currently planned.
There are planned integrations with several autoscalers and other projects to improve workload efficiency at a larger scale. Some projects under discussion:
InPlaceOrRecreate has recently graduated to beta, with the eventual goal being to graduate
the feature to stable. Support for InPlace mode is still being worked on; see this pull request.If you have a project that could benefit from integration with in-place pod resize, please reach out using the channels listed in the feedback section!
Today, In-Place Pod Resize is prohibited when used in combination with: swap, the static CPU Manager, and the static Memory Manager. Additionally, resources other than CPU and memory are still immutable. Expanding the set of supported features and resources is under consideration as more feedback about community needs comes in.
There are also plans to support workload preemption; if there is not enough room on the node for the resize of a high priority pod, the goal is to enable policies to automatically evict a lower-priority pod or upsize the node.
Resolve kubelet-scheduler race conditions There are known race conditions between the kubelet and scheduler with regards to in-place pod resize. Work is underway to resolve these issues over the next few releases. See the issue for more details.
Safer memory limit decrease The Kubelet's best-effort check for OOM-kill prevention can be made even safer by moving the memory usage check into the container runtime itself. See the issue for more details.
Looking to further build on this foundational feature, please share your feedback on how to improve and extend this feature. You can share your feedback through GitHub issues, mailing lists, or Slack channels related to the Kubernetes #sig-node and #sig-autoscaling communities.
Thank you to everyone who contributed to making this long-awaited feature a reality!