Cluster API to the Rescue: An Easier Way to Manage Your Kubernetes Clusters

In less than a generation, we’ve gone from bare-metal servers to virtualization to containers. It’s a story of expanded possibilities aided by stakeholder communities coming together to solve problems. Over time, processes have become easier and more efficient for end users. We’ve learned to orchestrate containers with Kubernetes, and now we can manage Kubernetes clusters and their associated infrastructure needs across multiple cloud providers (and hopefully on-premises) with Cluster API.

Looking back to how we got here, the path is entirely logical: physical servers were once underutilized. They frequently ran only one application per physical server, leaving a vast majority of their computing power just sitting idle.

Virtual machines came about to let you convert your underutilized physical servers into appropriately sized virtual servers. They reduced waste and made things easier: You were able to pack multiple virtual machines into a single physical server. With virtual machines, you could increase density and reduce cost.

Now, we can increase that density even further by shipping an entire application in a single container image. Container images can run almost everywhere—on physical servers or virtual machines, or even both at once. They also are typically significantly smaller than full operating system images, containing the application and any supporting files it needs.

Orchestrating Your Containers

When you have a single server, you can likely get by with managing your containers by hand. But when you’re trying to coordinate the placement and execution of containers for a department or an entire company full of dozens—or hundreds—of business units, you’ll quickly become overwhelmed if you’re still trying to do this all by hand. Instead, you need a way to orchestrate your containers.

Kubernetes isn’t the only container orchestrator out there, but it’s certainly the dominant one. As a Cloud Native Computing Foundation (CNCF) graduated project, Kubernetes lets you take a fleet of servers (physical or virtual) and combine their computing power into clusters. When you ask Kubernetes to run a pod (composed of one or more containers), Kubernetes selects a server with available capacity and then schedules the pod to run on that server.

Kubernetes has a reputation for being difficult, however. It’s just too hard, people say. Hard to install. Hard to use. Hard for everyone, no matter if you’re a developer or an IT administrator. Fortunately, the open source community has been chipping away at some of the complexities.

In the past, bootstrapping a Kubernetes cluster was exceedingly difficult. Kubernetes comprises several components, each with its own complex set of command line flags or configuration options. Trying to determine the correct values for each of these things wasn’t an easy task.

To help with this, the open source community in the Kubernetes Special Interest Group (SIG) Cluster Lifecycle came together and wrote kubeadm, which provides an easy—and, more importantly—consistent way to bootstrap a Kubernetes cluster. It follows the Unix philosophy: Focus on a single task and do that one task very well.

Kubeadm requires all the prerequisite infrastructure and software exist before you can use it. You must therefore pre-create all your servers, install software, set up networking and firewall rules and so on before you bootstrap a cluster. Prior to kubeadm, the only way to install Kubernetes was to either use an installer or piece together the components and command-line arguments yourself (possibly with help from Kelsey Hightower’s “Kubernetes the Hard Way“). Kubeadm is certainly not the only tool you can use to bootstrap a cluster, but it is the one that is supported by SIG Cluster Lifecycle, and it is the bootstrapper we recommend.

But kubeadm is only part of the journey, not a destination. If you were an IT operator looking to manage Kubernetes clusters in a multi-cloud setup—anything from Amazon, Google, Microsoft and others—you likely relied on multiple tools to cover all the different cloud providers. Each tool functioned slightly differently from the others. There was no guarantee your clusters were all bootstrapped the same way because some tools might use kubeadm, while others may not have.

The Coming of Cluster API

The SIG Cluster Lifecycle community noticed this fragmentation and began work on an effort to provide a unified platform to manage Kubernetes clusters and their associated infrastructure needs, across multiple cloud providers and (hopefully) on-premises.

Called the Cluster API project, the goal is to use the same kinds of APIs that users are familiar with in Kubernetes. Cluster API declaratively manages the life cycle of clusters (create, scale, upgrade and delete). By making use of the structured nature of Kubernetes APIs, it becomes possible to build higher-level cloud-agnostic tools that allow for greater ease of use and more sophisticated automation.

The intention is for Cluster API users to have a unified platform that manages Kubernetes clusters and their associated infrastructure needs across multiple cloud providers and hopefully on-premises, too. Cluster API adoption should provide portability across different infrastructures (with some configuration details specific to each cloud provider). For users, this means a relatively consistent and reliable user experience, regardless of the cloud provider or on-premises environment. In other words, it’s a batteries-included-but-swappable model.

Cluster API is letting us expand possibilities even further: enterprises will find it easier to adopt Kubernetes by standardizing and automating the full lifecycle management of Kubernetes clusters and their underlying infrastructure.

This is still a young project, though, and there is still much work to do. The community is looking for a large variety of contributions. To get involved in helping to improve Cluster API, try the Kubernetes Community Forum or Slack Channels, such as #cluster-api, #cluster-api-azure, #cluster-api-openstack, #cluster-api-aws, #cluster-api-baremetal. I’m looking forward to seeing what we can build together!

Andy Goldstein

Andy Goldstein is a staff engineer at VMware (via Heptio) where he works on tooling to make operating Kubernetes clusters easier. In his past lives, Andy worked on Velero (a disaster recovery tool for Kubernetes) and OpenShift. He lives in Rockville, MD, with his wife, two children, and two noisy cats.

Andy Goldstein has 1 posts and counting. See all posts by Andy Goldstein