Self-hosted, Scale, and Federation with Kubernetes v1.4 and Beyond
summary
etcd v3 replaces v2 to handle gigabytes of state and scale clusters to 3k–5k nodes (testing at 5k+), cuts resident memory (≈0.8GB for 512MB of keys) and flattens latency spikes; an etcd operator runs etcd on Kubernetes for automated backups and recovery. self-hosted clusters use Bootkube to run API server, controller-manager and scheduler as pods. Federation deploys replica sets, services, ingress, DNS across multiple clusters with a global load balancer (demo: nginx across four regions).
AI-written summary · about
chapters (16)
- 0:00Introduction
- 0:32About CoreOS
- 1:13Kubernetes CD
- 3:19CD Demo
- 7:36Latency performance
- 9:42Memory consumption
- 10:52Summary
- 11:45NetCD Operator
- 14:32Selfhosted Kubernetes
- 17:05Selfhosted Kubernetes goals
- 17:47Selfhosted Kubernetes demo
- 19:55Boot Queue
- 21:37Federation
- 25:54Replica Sets
- 35:18Shared Vision
- 36:04Goals
related talks
15mKubernetes and etcd Features That Unlocked 15k Node Clusters
31mDemystifying Kubernetes Failure Scenarios Caused by etcd
30mScaling Kubernetes to Thousands of Nodes Across Multiple Clusters, Calmly
36mManaging und Running Multiple Kubernetes Clusters
34mScaling Cloud Development Environments on K8s: Enterprise-Scale Adoption Lessons
26mDon't Let Your Kubernetes Cluster Go Wild: Ensuring Etcd Reliability
36mKubernetes with a single master
34mSelf-Hosted Kubernetes: How and Why [I]