For years, the Kubernetes community has diligently worked to enhance the stability and predictability of performance within the API server. A significant portion of this effort has focused on optimizing list requests, which have historically been a primary contributor to high memory usage and substantial load on the etcd datastore. With each release, improvements have been made incrementally, and today marks a pivotal moment with a major piece of this ongoing challenge resolved.
The snapshottable API server cache feature has reached Beta status in Kubernetes v1.34, representing the culmination of a multi-release initiative designed to allow virtually all read requests to be served directly from the API server’s cache. This advancement significantly improves the efficiency and responsiveness of your kubernetes deployments.
Evolving the Cache for Enhanced Performance and Stability
The journey toward the current state involved several key enhancements across recent releases, laying the groundwork for today’s announcement. These changes collectively contribute to a more robust and performant kubernetes environment.
Consistent Reads From Cache (Beta in v1.31)
While the API server has long utilized caching mechanisms for performance gains, a critical milestone was ensuring consistent reads of the latest data from that cache. Introduced in v1.31, this enhancement enabled the watch cache to be used for strongly-consistent read requests for the first time. Consequently, filtered collections (such as “a list of pods bound to this node”) could now be safely served directly from the cache instead of etcd. This dramatically reduced the load on etcd for common workloads and improved overall system responsiveness within your kubernetes infrastructure.
Taming Large Responses with Streaming (Beta in v1.33)
Furthermore, another crucial improvement addressed the issue of memory spikes when transmitting large responses. The streaming encoder, introduced in v1.33, allowed the API server to transmit list items incrementally rather than buffering the entire multi-gigabyte response in memory. This made the memory cost of sending a response predictable and minimal, irrespective of its size. Notably, this feature significantly enhances scalability for kubernetes clusters handling large datasets.
Kubernetes 1.34: Snapshots Complete the Picture
The snapshottable API server cache addresses a remaining critical gap. This feature expands upon the watch cache’s capabilities, allowing it to generate efficient, point-in-time snapshots of its state. These snapshots are “lazy copies,” meaning they don’t duplicate objects but instead store pointers, making them incredibly memory-efficient.
When a list request for a historical resourceVersion arrives, the API server now efficiently locates the corresponding snapshot and serves the response directly from its memory. This crucial improvement allows paginated requests to be handled entirely from the cache, closing a major gap in performance optimization within your kubernetes setup.
A New Era of Predictable API Server Performance
With this final piece implemented, the synergy of these three features ushers in a new era of predictable API server performance.
- Data Retrieval From Cache: Consistent reads and snapshottable caches work synergistically to ensure that nearly all read requests—whether for the latest data or a historical snapshot—are served from the API server’s memory.
- Streamed Data Transmission: Streaming list responses guarantee minimal and constant memory footprint when sending this data to clients. As a result, resource utilization becomes more efficient throughout your kubernetes environment.
The resulting system exhibits remarkably predictable resource costs for read operations and improved resilience against spikes in request load. This translates into reduced memory pressure, lighter load on etcd, and a more stable, scalable, and reliable control plane for all kubernetes clusters.
Getting Started with the Snapshottable Cache
With its advancement to Beta status, the SnapshottableCache feature gate is enabled by default in Kubernetes v1.34. Consequently, you can immediately benefit from these performance and stability enhancements without requiring any specific configuration changes.
Acknowledgements
Special thanks are extended to those who designed, implemented, and reviewed these critical features:
- Ahmad Zolfaghari (@ah8ad3)
- Ben Luddy (@benluddy) – Red Hat
- Chen Chen (@z1cheng) – Microsoft
- Davanum Srinivas (@dims) – Nvidia
- David Eads (@deads2k) – Red Hat
- Han Kang (@logicalhan) – CoreWeave
- haosdent (@haosdent) – Shopee
- Joe Betz (@jpbetz) – Google
- Jordan Liggitt (@liggitt) – Google
- Łukasz Szaszkiewicz (@p0lyn0mial) – Red Hat
- Maciej Borsz (@mborsz) – Google
- Madhav Jivrajani (@MadhavJivrajani) – UIUC
- Marek Siarkowicz (@serathius) – Google
- NKeert (@NKeert)
- Tim Bannister (@lmktfy)
- Wei Fu (@fuweid) – Microsoft
- Wojtek Tyczyński (@wojtek-t) – Google
This milestone reflects the dedication of the community to building a more scalable and robust kubernetes platform.
Source: Read the original article here.
Discover more tech insights on ByteTrending.
Discover more from ByteTrending
Subscribe to get the latest posts sent to your email.
