Extending the Kubernetes Cluster API

One major downside for developers is that Kubernetes has no native functionality to manage its nodes or other clusters. As a consequence, operations must get involved every time a new cluster or worker node is needed. Of course, several ways exist to create a cluster and also to create a new worker node. But all of them require a specific domain knowledge.

Cluster API

The Cluster API is a new working group under the umbrella of the sig-cluster-lifecycle. The objective of the group is to design an API which enables you to create clusters and machines via a simple, declarative API. The working group is in the very early stages of defining all API types. But an example for GCP already exists.

The whole Cluster API currently consists of four components: one API server and three controllers.

API server

The Cluster API in its current state brings an extension-API server which is responsible for CRUD operations on the API resources.

Controllers

Currently there are three controllers planned:

• MachineController

• MachineSet

• MachineDeployment

The MachineController is meant to be provider specific as each provider has its own way of managing machines. MachineSet and MachineDeployment on the other hand will be generic controllers which simply generate Machine or, respectively, MachineSet resources. This means that this approach is very similar to a Deployment which manages ReplicaSets and a ReplicaSet manages Pods.

But, of course, a provider could also implement a MachineSet and MachineDeployment controller, which could make sense, looking at AutoScaling groups on AWS or NodePools on GKE.

API types

The Cluster API introduces four new types:

Cluster

The cluster represents a Kubernetes cluster with configuration of the entire control plane except for node specifics.

Machine

A machine represents an instance at a provider, which can be any kind of server, like an AWS EC2 instance, a PXE booted bare-metal server or a Raspberry PI.

MachineSet –  You see where this is going 😉

A MachineSet is similar to a ReplicaSet: a definition for a set of same machines. The MachineSet controller will create machines based on the defined replicas and the machine template.

A MachineDeployment is similar to a Deployment: a definition for a well managed set of machines. The MachineDeployment controller though, will not directly manage machines but MachineSets. For each change on a MachineDeployment, the controller will create and scale up a new MachineSet to replace the old one.

MachineDeployment

ProviderConfig

Each machine and cluster type has a field called providerConfig within its spec. The field providerConfig is loosely defined. It allows arbitrary data to be stored in it. It allows provider-specific configuration for each API implementation.

Outlook

Possible ways to utilize this new API would be:

• Autoscaling

• Integration with the Cluster Registry API

  • Automatically add a new cluster to a registry, support tooling that works across multiple clusters using a registry, delete a cluster from a registry

• Streamlining Kubernetes installers by implementing the Cluster API

• Declarative Kubernetes upgrades for the control plane and kubelets

• Maintaining consistency of control plane and machine configuration across different clusters / clouds

• Cloud adoption / lift and shift / liberation

Henrik’s colleague Guus van Weelden will be speaking on “Let’s Play with Lego and Kubernetes” and his colleague Matthias Loibl will be speaking on “Declarative Multi-Cluster Monitoring with Prometheus” at KubeCon + CloudNativeCon EU, May 2-4, 2018 in Copenhagen, Denmark.