Upgrading Charmed Kubernetes

This article describes the advantages users of Charmed Kubernetes enjoy through the high degree of automation charms offer the operator. One of the hardest problems of infrastructure-as-a-service operations is upgrading. Charms make it an easy 4 step process that is highly repeatable and predictable in its outcome.

Kubernetes on Ubuntu is a solid choice for many developers, operators and cloud platforms. Ubuntu powers most public Container-as-a-Service offerings today, and gives some of the best performance characteristics across all virtual substrates and bare metal due to its up-to-date kernel, built-in multi-cloud optimisations, and availability of the latest version of K8s within days of the upstream release.

Operators have many choices when deciding which orchestration framework to apply when installing K8s at scale, or when managing many clusters. Some are considering to build a “Kubernetes-as-a-Service” offering on-premise, as a local alternative to the various offerings in the public cloud.

Canonical offers support for kubeadm, a popular tool for many Kubernetes administrators to get started. However, Charms pose an attractive alternative to provide a highly automated way to deploy and operate K8s using model-driven architecture. Charms contain operations code which has been made transferable, and can be considered “object-oriented operations”. Rather than rewriting the same procedure to fit new circumstances, Charms allow the operator to instantiate classes of components on a model, and describe the properties of their interfaces. Operators can then relate the objects to each other, without having to procedurally describe this relation every time. For example, an object of etcd will understand methods to create a cluster of etcd out of a stand-alone installation, its interaction with a certificate authority to create a TLS certificate for encryption, and so on.

Using Charms to deploy and operate Kubernetes leads to highly automated, repeatable, and version controlled clusters, which expose the identical operational paradigms independent of the substrate they run on. For example, deploying Charmed Kubernetes on top of AWS feels identical to deploying it on VMware or bare-metal.

One of the most common “Day 2” operations is the upgrade of an existing K8s cluster. Again, Charms provide the necessary operational intelligence encoded in the “methods” belonging to each of the “objects” on the model describing the cluster. This leads to a tangible difference for the operator.

Upgrading a charmed Kubernetes cluster

Using Charms, upgrading is essentially a 4-step process. As an example, I deployed the Charmed Kubernetes (CDK) version 1.11 on AWS. Here is a (cropped) screenshot of how that looks like:

$ juju status

The current version installed for the kubernetes-master and kubernetes-worker application is 1.11.4. However, version 1.12 is actually available, so we’re going to upgrade.

1.) Upgrade Kubernetes charms:

$ juju upgrade-charm kubernetes-master

$ juju upgrade-charm kubernetes-worker

This will pull the latest stable Kubernetes charms from the Charm Store to facilitate the upgrade of Kubernetes itself. Run the “juju status” command again and wait until all units are back in the “active” state.

2.) Set the target version by configuring the channel for the charms:

$ juju config kubernetes-master channel=1.12/stable
$ juju config kubernetes-worker channel=1.12/stable

Juju will set the model parameters accordingly and it will reflect in the status of the CDK cluster. Please note that “blocked” only refers to changes to the running model – the Kubernetes cluster is still fully functional!

3.) Upgrade all the Kubernetes Master nodes:

$ juju run-action kubernetes-master/0 upgrade
$ juju run-action kubernetes-master/1 upgrade

The kubernetes-master unit will show various status messages as it goes through the upgrade process. While this is happening, the workload is marked as in “maintenance” mode.

4.) Upgrade all the Kubernetes Worker nodes:

$ juju run-action kubernetes-worker/0 upgrade
$ juju run-action kubernetes-worker/1 upgrade
$ juju run-action kubernetes-worker/2 upgrade

The Charms, containing all the operational logic behind upgrading a K8s cluster (and I encourage you to check out the steps for upgrading Kubernetes to appreciate the amount of automation), will manage and coordinate everything necessary to get from 1.11 to 1.12. This is will not interrupt the data plane access to the workloads while the upgrade is being performed, however access to the control plane, i.e. interacting with the K8s cluster in an administrative manner, is obviously not guaranteed – you are upgrading the cluster, after all.

Once the upgrade has been completed, your picture changes to this. Note the new version of Kubernetes Master and Worker nodes (1.12.2):

Upgrading minor and major versions require operator interaction as shown above. However, it should be noted that maintenance releases are tracked automatically. This allows deployments of Charmed Kubernetes to remain up-to-date with regards to security and maintenance patches, further reducing the burden of operating many Kubernetes clusters across many different virtual and physical substrates.

Upgrading K8s comes with many gotchas and requires a specialised skill set to perform well. Using charms, this process becomes much easier and predictable by reducing the complexity to a simple to follow, 4-step process, which remains identical across all substrates supported by Charms, whether on-premise or on the public cloud.