Kubernetes 1.35: In-Place Pod Resize Graduates to Stable

Source: Kubernetes Blog

Release Announcement

This release marks a major step: more than six 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 v1.35!

This graduation is a significant milestone for improving resource efficiency and flexibility for workloads running on Kubernetes.

In‑Place Pod Resize

Historically, the CPU and memory resources defined for a container in a Pod were immutable.
Changing them required deleting and recreating the entire Pod—a disruptive operation for:

• Stateful services
• Batch jobs
• Latency‑sensitive workloads

In‑Place Pod Resize makes CPU and memory requests and limits mutable, allowing you to adjust these resources while the Pod is running, often without restarting the container.

Key Concepts

How to Perform an In‑Place Resize

1. Edit the Pod spec (or use kubectl patch/kubectl apply) to modify the resources section under spec.containers.

   spec:
     containers:
     - name: my-app
       resources:
         requests:
           cpu: "500m"
           memory: "256Mi"
         limits:
           cpu: "1"
           memory: "512Mi"

2. Submit the resize request using the resize subresource:

   kubectl replace --subresource=resize -f pod-resize.yaml

3. Verify the change:

   kubectl get pod -o jsonpath='{.status.containerStatuses[*].resources}'

Benefits

• Zero‑downtime updates for resource‑intensive workloads.
• Faster iteration on performance tuning.
• Reduced operational overhead—no need to delete/recreate Pods for simple scaling.

In‑Place Pod Resize is now a standard feature in recent Kubernetes releases, enabling more flexible and responsive resource management for production workloads.

How can I start using in‑place Pod Resize?

Detailed usage instructions and examples are provided in the official documentation:

Resize CPU and Memory Resources assigned to Containers

How does this help me?

In‑place Pod Resize is a foundational building block that unlocks seamless vertical autoscaling and improves workload efficiency.

Benefits

• Resources adjusted without disruption
  Workloads that are sensitive to latency or restarts can have their resources modified in‑place, avoiding downtime or loss of state.

• More powerful autoscaling
  Autoscalers can now adjust resources with less impact. For example, the Vertical Pod Autoscaler (VPA) InPlaceOrRecreate update mode—now graduated to beta—leverages this feature to automatically and seamlessly resize pods based on usage.

  See the AEP‑4016 enhancement for details.

• Address transient resource needs
  Workloads that temporarily need more resources can be adjusted quickly. This enables features like the CPU Startup Boost (AEP‑7862), where applications request extra CPU during startup and then automatically scale back down.

Example Use Cases

• A game server that scales its size with a shifting player count.
• A pre‑warmed worker that shrinks while idle and inflates on the first request.
• Dynamic scaling for efficient bin‑packing of workloads.
• Increased resources for just‑in‑time (JIT) compilation during startup.

Changes Between Beta (1.33) and Stable (1.35)

Since the initial beta in v1.33, development has focused on stabilizing the feature and improving its usability based on community feedback. Below are the primary changes introduced in the stable release v1.35.

1. Memory‑limit Decrease

• Previously, decreasing memory limits was prohibited.
• This restriction has been lifted; memory‑limit decreases are now permitted.
• The Kubelet will try to prevent OOM‑kills by allowing the resize only if the current memory usage is below the new desired limit.
• Note: This check is best‑effort and not guaranteed.

2. Prioritized Resizes

When a node lacks sufficient room to satisfy all resize requests, Deferred resizes are re‑attempted based on the following priority order:

1. PriorityClass
2. QoS class
3. Duration of the Deferred state – older requests are prioritized first.

3. Pod‑Level Resources (Alpha)

• In‑place Pod Resize now supports Pod Level Resources.
• This capability is gated behind a feature flag and is alpha in v1.35.

4. Increased Observability

• New Kubelet metrics and Pod events have been added specifically for In‑Place Pod Resize.
• These enhancements help users track and debug resource changes more effectively.

What’s Next?

The graduation of In‑Place Pod Resize to stable opens the door for powerful integrations across the Kubernetes ecosystem. Several areas for further improvement are currently planned.

Integration with Autoscalers and Other Projects

Planned integrations with autoscalers and related projects aim to improve workload efficiency at larger scale. Projects under discussion include:

• VPA CPU startup boost – AEP‑7862
  Allows applications to request more CPU at startup and scale back down after a specific period.

• VPA support for in‑place updates – AEP‑4016
  InPlaceOrRecreate support has graduated to beta; the goal is to graduate the feature to stable. Support for pure InPlace mode is still in progress (see PR #8818).

• Ray autoscaler – Plans to leverage In‑Place Pod Resize to improve workload efficiency. See the Google Cloud blog post for details.

• Agent‑sandbox “Soft‑Pause” – Investigating the use of In‑Place Pod Resize for lower latency. See the GitHub issue.

• Runtime support – Java and Python runtimes currently cannot resize memory without a restart. An open conversation with Java developers is ongoing (see the JDK bug).

If your project could benefit from integration with In‑Place Pod Resize, please reach out via the channels listed in the Feedback section.

Feature Expansion

Today, In‑Place Pod Resize is prohibited when used with:

• Swap
• The static CPU Manager
• The static Memory Manager

Resources other than CPU and memory remain immutable. Expanding the set of supported features and resources is under consideration as community feedback is gathered.

Future plans also include workload preemption: when a high‑priority pod cannot be resized due to insufficient node capacity, policies could automatically evict a lower‑priority pod or upscale the node.

Improved Stability

• Resolve kubelet‑scheduler race conditions
  Known race conditions between the kubelet and scheduler affect In‑Place Pod Resize. Work is underway to address these issues in upcoming releases. See the issue #126891.

• Safer memory‑limit decrease
  The kubelet’s best‑effort OOM‑kill prevention can be made safer by moving the memory‑usage check into the container runtime itself. See the issue #135670.

Providing Feedback

If you’d like to help improve and extend this feature, we welcome your input!

• GitHub: Open an issue in the relevant repository.

• Mailing Lists: Share your thoughts on the appropriate Kubernetes mailing list.

• Slack: Join the conversations in the Kubernetes communities:

  • #sig-node
  • #sig-autoscaling

Thank you to everyone who contributed to making this long‑awaited feature a reality!