Scale Kubernetes to Manage 60K Nodes Through Architectural Extension
summary
A Kubernetes fork called Octos extends the control plane and proves a split architecture can manage 60,000 nodes by separating customer workload into tenant + resource partitions with independent API servers and etcd. Changes include a unified runtime to treat VMs like pods, CRI extensions, and a watch/bookmark optimization that cuts API-server CPU for event processing ~70%. Benchmarks use modified cluster-loader and show comparable pod startup latency at much higher QPS, demonstrating it works.
AI-written summary · about
chapters (17)
- 0:00Intro
- 0:48Outlines
- 1:29WHO ARE WE AND WHAT IS ARKTOS PROJECT
- 4:21WHY CENTAURUS AND ARKTOS
- 8:26ARKTOS INTRODUCTION
- 9:20ARKTOS SCALE-OUT ARCHITETCURE
- 11:48ARKTOS MULTI-TENANCY DESIGN
- 14:16ARKTOS UNIFIED RUNTIME INFRASTRUCTURE
- 17:07Arktos Scale-Out Architecture
- 20:55Arktos Optimization
- 21:38Performance Test Results & Analysis
- 26:04Performance Test Tool
- 28:23Critical Changes for Performance Improvement
- 34:20Events Watch Optimization
- 43:23Final Performance Data
- 44:16Arktos Cluster TP1 Master Resource Utilization
- 44:48Arktos Cluster RP1 Master Resource Utilization
related talks
34mPanel: Improving and Managing Kubernetes at Scale
34mEmbracing Upstream Kubernetes in Web Scale Organization
42m2000 Nodes and Beyond: How We Scaled Kubernetes to 60,000-Container Clusters
30mScaling Kubernetes to Thousands of Nodes Across Multiple Clusters, Calmly
37mKubernetesception: How to run a 1000 control planes
32mScaling Kubernetes Application to 1M Users
37mOne Cluster to Rule Them All - Multi-Tenancy for 1k Users
03mFrom 5 to 1,300+ Clusters: Declarative Scaling for Private Kubernetes