The Myth of the Monocluster
Talkat KubeCon + CloudNativeCon North America 2019 · on Wednesday, 2019-11-20· at 17:20· Ballroom Sec 20CD - San Diego Convention Center, Upper Level·
summary
Argues a single monolithic Kubernetes cluster increases blast radius and operational friction, citing control-plane and DNS bottlenecks (about 30 public failures with 17 featuring DNS), API-server scaling limits, noisy-neighbor I/O issues, and version drift. Recommends multiple, throwaway clusters managed by a dedicated platform team, use Cluster API and Gatekeeper for reproducible baseline clusters and policy enforcement, pick a few clusters for multi-cluster ingress for critical services, and aim to recreate a cluster from scratch within an operational target (for example, one hour).
AI-written summary · about
chapters (10)
- 0:00Start
- 0:22this talk?
- 0:55the myths
- 1:50the problem
- 3:32challenges
- 4:35fail
- 18:00hard things
- 20:22no pets allowed
- 23:21criteria
- 28:16takeaways
related talks
35mKubernetes, Lessons Learnt
20mYou can't have a cluster*!$& without a cluster!
41mKubernetes the Very Hard Way
27mRunning Kubernetes in Production A Million Ways to Crash Your Cluster
49mCluster Wrangling: How to make Kubernetes clusters secure and usable
34mA Huge Cluster or Multi-Clusters? Identifying the Bottleneck
32mLaying the Foundation: Real World Kubernetes Deployment Patterns
36mKubernetes, Decisions