Revolutionizing Vertical Scaling: In-Place Pod Resize in Kubernetes 1.35

Kubernetes 1.35 brings a significant change to the way we handle vertical scaling, offering a game-changer for developers and DevOps teams worldwide, including those in North East India and the broader Indian context. This update enables the modification of running Pods' CPU and memory resources without recreating them, a feature that addresses a long-standing issue and simplifies day-to-day operations.

The Problem: Simple Changes That Cause Disruptions

In earlier versions of Kubernetes, a simple adjustment to the CPU or memory limit of a Pod would trigger a cascade of unwanted events, such as pod recreation, active connection termination, and loss of in-memory cache. This disruption could lead to service interruptions and additional maintenance efforts.

The Solution: In-Place Resource Update (GA)

With Kubernetes 1.35, in-place Pod resource updates are now generally available (GA). This means that CPU and memory can be modified in running Pods, and the node applies the new values without the automatic recreation cycle. Key features include hot CPU changes, configurable memory changes with or without container restart, and preservation of state, connections, and cache.

Observable Visibility

Kubernetes 1.35 introduces an important distinction in how resources are reported, providing visibility of the resize state via conditions. This allows you to know exactly what state the resize is in at any moment.

Configuration: resizePolicy

The resize behavior is configured per resource type using the resizePolicy in the container spec. This configuration allows for a more controlled and predictable resize process.

Relevance to North East India and India

The ability to scale vertically without causing disruptions is particularly valuable for organizations in North East India and India, where efficient resource utilization and minimizing downtime are crucial factors for success. This feature will enable teams to make necessary adjustments quickly, improving the overall performance and reliability of their applications.

The New Mental Model: Desired vs Actual vs Allocated

Kubernetes 1.35 introduces a new mental model for understanding resource allocation and utilization. This model includes the desired, actual, and allocated states, providing a clearer understanding of the current resource situation.

Limitations and Scheduler Protection

While the in-place resize feature is powerful, it does have clear limits. For example, it does not support changes to the QoS class, init containers, ephemeral containers, or Windows Pods. Additionally, some CPU/Memory managers may block changes during resize. Understanding these limitations is essential for a smooth implementation and operation.

Operational Impact

The most significant change is not technical; it's cultural. Kubernetes 1.35 encourages a shift in how teams approach resource management. Teams will be more likely to make CPU corrections without restart, allowing for faster iteration over resource configuration and a more responsive approach to throttling without the need for maintenance windows.

Command Summary

To execute a resize, you can use the kubectl command to patch the Pod and check the resize status, view current vs desired resources, and confirm no restart occurred.

Conclusion

Kubernetes 1.35 solves a problem that should never have existed: the need to restart a process just because a resource limit was adjusted. With in-place resize GA, CPU can be adjusted without any restart, and memory can be configured for container restart (not Pod). Full observability of resize state and protection against overcommit during pending changes make vertical scaling finally behave like an adjustment, not a deployment.