#machinedeployment

I’ve been minimally exposed to “Managed Kubernetes” but recent projects has forced me into get a better understanding what it can do. If you’ve ever deployed a cluster on Amazon EKS, Google GKE or Azure AKS you’ll soon notice that you have no masters in your cluster(!). That’s right, that means someone else is managing that piece of the puzzle for you (and charge you) and everything just works. Also convenient with this concept is that the tools provided by these services allow you to just add more compute nodes dynamically without any effort what so ever.

The trick is brilliant and simple. There IS a dedicated master for your cluster – but it’s managed by an uber Kubernetes cluster – that uber cluster also have access to your IaaS to fling compute nodes left, right and center at your command.

Let’s break this down in a pretty diagram.

A new cuddle command is of course needed for all this to tie together: clusterctl. Clustercuddle allows an admin to create and delete clusters on an IaaS provider. A list of supported, or in development, IaaS providers are available in the Kubernetes SIG Cluster API GitHub repo but all your usual suspects are there amongst the public cloud providers as well as vSphere and OpenStack (unsure if this is in any way related to OpenStack Magnum). The listed project for “Bare Metal” is an OpenStack Ironic fork to allow bare metal provisioning with clusterctl. There was some hay on El Reg about Red Hat joining the fray just the other day, so I'm sure this will all come together for the Red Hat OpenShift customers who opt-out from running Red Hat OpenStack Platfrom (OSP) as the IaaS but clearly want the benefit of running bare metal compute nodes.

Clustercuddle also funnels out all the appropriate kubeconfigs that users need to communicate with their API server running on the uber cluster. The cluster-admin of a slave cluster has a machinedeployment API object where they can manipulate properties for new compute nodes that gets added to the cluster. Behold, simply flicking .spec.replicas will automatically conform the cluster by either provision or decommission nodes.

A sample machinedeployment API object is available in the Cluster API GitHub repo but shown here for completeness:

--- apiVersion: "cluster.k8s.io/v1alpha1" kind: MachineDeployment metadata: name: sample-machinedeployment spec: replicas: 3 selector: matchLabels: foo: bar template: metadata: labels: foo: bar spec: providerSpec: value: apiVersion: "gceproviderconfig/v1alpha1" kind: "GCEProviderConfig" roles: - Node project: "${GCLOUD_PROJECT}" zone: "us-central1-c" machineType: "n1-standard-2" os: "ubuntu-1604-lts" versions: kubelet: 1.9.4