Your submission was sent successfully! Close

Thank you for signing up for our newsletter!
In these regular emails you will find the latest updates from Canonical and upcoming events where you can meet our team.Close

Thank you for contacting our team. We will be in touch shortly.Close

  1. Blog
  2. Article

Stephan Fabel
on 15 November 2018


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.



    

Related posts


Marcin "Perk" Stożek
14 March 2024

How should a great K8s distro feel? Try the new Canonical Kubernetes, now in beta

Kubernetes Article

Try the new Canonical Kubernetes beta, our new distribution that combines ZeroOps for small clusters and intelligent automation for larger production environments that also want to benefit from the latest community innovations ...


Karen Horovitz
18 March 2024

Canonical accelerates AI Application Development with NVIDIA AI Enterprise

Kubernetes Article

Charmed Kubernetes support comes to NVIDIA AI Enterprise Canonical’s Charmed Kubernetes is now supported on NVIDIA AI Enterprise 5.0. Organisations using Kubernetes deployments on Ubuntu can look forward to a seamless licensing migration to the latest release of the NVIDIA AI Enterprise software platform providing developers the latest AI ...


Marcin "Perk" Stożek
14 December 2023

Canonical Kubernetes 1.29 is now generally available

Kubernetes Article

A new upstream Kubernetes release, 1.29, is generally available, with significant new features and bugfixes. Canonical closely follows upstream development, harmonising our releases to deliver timely and up-to-date enhancements backed by our commitment to security and support – which means that MicroK8s 1.29 is now generally available as ...