“We want to take the same technology that's being used for workloads running on top of Kubernetes and apply that to Kubernetes itself”
Cluster API is a big deal. In fact, Kubernetes creators Joe Beda and Craig McLuckie hope it will soon manage the majority of all Kubernetes clusters. So what is Cluster API, and why do Joe and Craig think it’s “generationally more advanced” than what anyone—cloud provider or otherwise—is doing right now? I interviewed them to learn more.
A good starting point is defining what Kubernetes actually is. Although it’s easy to think of Kubernetes as a container orchestrator it’s fundamentally about declaring a desired state and continuous reconciliation to that state. Cluster API brings that same approach to the Kubernetes clusters themselves. The Cluster API is an open-source, cross-vendor effort to simplify cluster lifecycle management. It’s a member of a set of tools—including kubeadm and emerging projects to help create/curate/update base virtual machine images—tackling this problem in a Kubernetes-native way.
But let’s step back a moment and consider whether cluster lifecycle management is an actual problem that needs this type of attention. In the marketplace of ideas, multi-cluster has won. Rather than creating one giant Kubernetes cluster for everyone to share, users have expressed a need to have many small clusters. It makes sense from a security perspective, and can improve resilience and stability, as well.
However, where new problems emerge, Joe says, is that the current generation of lifecycle tooling is “not set up for turnkey management at scale.” It’s easy to get a Kubernetes cluster up and running through existing DevOps tooling, Joe explained, but “keeping it up, and doing the day-to-day stuff and upgrading that stuff, is where it really starts to get more difficult and we start seeing a lot more bespoke solutions.”
In addition, while the public clouds offer managed services for Kubernetes, they typically have a closed control plane. To Craig, that’s not ideal:
"Systems are being built deeply intertwined into Kubernetes, and it's very hard to bring that into an enterprise context if you don't have access to the control plane. You can't add admission controllers, API server flags, can't intercept critical log events. Kubernetes consumers don’t like that.”
To Joe and Craig, Cluster API presents a path forward. It offers an open mechanism to create continuously reconciled systems and uses primitives that can work across clouds or on-premises, on virtualized or bare metal infrastructure. Its base definitions of concepts like cluster, machine, and node are platform-agnostic. There aren’t provider-specific dependencies in the core code base, but extensibility is important and a diverse provider universe already exists. You’ll find provider implementations for a host of clouds, including AWS, Microsoft Azure, Baidu Cloud, Digital Ocean, Google Cloud Platform, IBM Cloud, vSphere, Packet, and more. For Joe, Cluster API is a continuation of some of the best ideas proven out in BOSH—the release and lifecycle management tool used by Cloud Foundry—applied to a much wider domain.
If you want to get your hands dirty with Cluster API, there’s nothing holding you back. According to Craig, it’s a modular system that focuses on doing one thing well, so it’s approachable for Kubernetes pros to check out. However, it’s also actively evolving—the next release is coming in March—and has an “inception challenge” of requiring an initial management cluster to start managing the created clusters.
To be sure, VMware is investing heavily in the open source Cluster API work. For starters, it’s solving that inception challenge by baking the supervisor cluster into vSphere directly via Project Pacific, and by offering multi-cloud provisioning through Tanzu Mission Control. However, both Joe and Craig anticipate other vendors will follow suit by insulating customers from the changing API surface and the need to instantiate the bootstrapping cluster.
Many (most?) of those who implement it may compete with VMware, but Joe thinks that’s fine, because it’s an important enabling capability for the entire Kubernetes ecosystem. He believes our industry must move past the point where vendor business models depend on software being complicated to install and use. We need to keep investing upstream to ensure everyone gets these foundational benefits.
And then VMware continues innovating in areas that complement Kubernetes, including cross-region management, advanced security and policy control, and so much more.
Come visit us at KubeCon Europe to talk more about Cluster API and all things Kubernetes!
Join the Community!
- Cluster API community forum
- sig-cluster-lifecycle Google Group to gain access to documents and calendars
- The Cluster API Book
About the Author
Follow on Twitter More Content by Richard Seroter
