Madhav Jivrajani and Marek Siarkowicz discuss the performance challenges of the Kubernetes API server and how to avoid common scalability pitfalls.
Don't miss out! Join us at our next Flagship Conference: KubeCon + CloudNativeCon events in Hong Kong, China (June 10-11); Tokyo, Japan (June 16-17); Hyderabad, India (August 6-7); Atlanta, US (November 10-13). Connect with our current graduated, incubating, and sandbox projects as the community gathers to further the education and advancement of cloud native computing. Learn more at kubecon.io
Defusing the Kubernetes API Performance Minefield - Madhav Jivrajani, UIUC & Marek Siarkowicz, Google
Kubernetes enables a wide landscape of CNCF projects and organisations to build upon its foundation and extend its functionality through custom controllers. But anyone who has deployed an operator at scale, quickly discovers that the Kubernetes API is a performance minefield. Forget to set resourceVersion when listing pods? Your control plane explodes! This talk delves into recent enhancements in Kubernetes designed to defuse this performance minefield. We'll explore the improved storage layer that allows caching more types of requests, effectively halving request latency and reducing the load on etcd. Don't let your cluster fall victim to faulty controllers – join us to learn how these changes mitigate risks, boost performance, and contribute to a more stable and reliable Kubernetes experience. We'll explore how the storage layer improves API responsiveness and predictability, and you'll understand the impact of these changes on scalability, reliability, and overall user experience.
Why it's here
1 person recommends this
What people say. Recommended by a Kubernetes scalability contributor to explain the real engineering work behind API server and etcd performance.
S
u/Serathiusin r/kubernetes • Recommends
On “Why etcd breaks at scale in Kubernetes”
As a person that works on Kubernetes scalability, API server caching layer and etcd (with my work being cited in the article), I can only say that this article totally misses the point and brings more disinformation about scalability than information.
It's the k3s/kine marketing trying to sell you their solution.
The recent jumps in scalability of K8s offerings is the result of years of work put into fixing inefficiencies and bottlenecks in the control plane.
At GKE we tested run 30k node clusters on old v3.4 etcd release on old n2 machine generation. It worked.
Want to know more, watch my talk link to this video
