From Frankenstein to Kamaji: Lessons in Building a Single CAPI Cluster Across Multiple Providers
summary
Giant Swarm prototypes a hybrid Cluster API cluster with the control plane on vSphere and workers on Proxmox, which initially requires a Frankenstein cluster hack: patching the vSphere CCM to ignore non-vSphere provider IDs so Proxmox nodes stop getting deleted. That fork works but is brittle and unmaintainable, so they replace VM control planes with Kamaji hosted control planes, running three control plane pods and a 3-node etcd StatefulSet in the management cluster, yielding faster bootstraps, better resource use, and upstream support at the cost of management-cluster blast radius and networking tweaks.
AI-written summary · about
chapters (8)
- 0:00Introduction to talk
- 1:07Cluster API overview
- 9:19Hybrid cluster challenges
- 11:28Frankenstein cluster demo
- 15:41Fixing the Frankenstein cluster
- 22:45Hosted control planes with Kamaji
- 26:40Kamaji cluster demo
- 31:20Q&A session
related talks
30mFrom Frankenstein To Kamaji: Lessons in Building a Single CAPI Cluster Across Multiple Providers
35mKubernetes-in-Kubernetes with Kamaji, KubeVirt, and the Cluster API
40mMay the Control Plane be with you: Kamaji and the rise of Kubernetes at scale
35mSimplified Experience Of Building Cluster API Provider In Multitenant Cloud
37mKubeInception: running up to a thousand clusters in the real Cloud-Native way
26mRunning Kubernetes Clusters the Kubernetes-Native Way
40mDeep Dive: Kubernetes (VMware) SIG
29mTowards Sustainable Multi-Cluster Management in Real-World Academic Infrastructure