How to switch the Docker container runtime to containerd with Charmed Kubernetes
Canonical
on 7 December 2020
Tags: Charmed Kubernetes , Charms , containerd , containers , docker , k8s , kubernetes
This article describes how easy it is for users of Charmed Kubernetes to switch from the Docker container runtime to containerd. You may have heard that Kubernetes is deprecating Docker as a container runtime after v1.20. Docker as an underlying runtime is being deprecated in favor of runtimes that use the Container Runtime Interface(CRI) created for Kubernetes, such as containerd.
One of the hardest problems of infrastructure-as-a-service operations is replacing the component of an already deployed solution to another. Charms make this an easy 3-step process that is highly repeatable and predictable in its outcome.
Ubuntu is the reference platform for Kubernetes on all major public clouds, including official support in Google’s GKE, Microsoft’s AKS and Amazon’s EKS CAAS offerings. Canonical delivers pure upstream Kubernetes tested across the widest range of clouds — from public clouds to private data centres, from bare metal to virtualised infrastructure.
What is a charm?
A charm is a software package that bundles an operator together with metadata that supports the integration of many operators in a coherent aggregated system.
An operator packaged as a charm means that it is configured, operated and integrated in a standard way regardless of the vendor or the application. Charms enable multi-vendor operator collections with standardised behaviours, reducing the learning curve associated with each operator and creating richer application ecosystems.
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.
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.
Switching the Docker runtime to containerd in a charmed Kubernetes cluster
Using Charms, changing the Docker runtime to containerd is essentially a 3-step process. As an example, I deployed Charmed Kubernetes on AWS and changed the containerd runtime in the YAML bundle to Docker since it already comes with containerd by default. Here is a (cropped) screenshot of how that looks like:
$ juju status
The current container runtime installed is Docker. However, the Docker runtime is being deprecated, so we’re going to change it to containerd.
1.) Remove the Docker runtime:
$ juju remove-application docker
This will remove the Docker runtime from the Kubernetes cluster. Run the “juju status” command again and wait until all units are back in the “active” state.
2.) Deploy the containerd runtime:
$ juju deploy cs:~containers/containerd
Juju will deploy the new containerd runtime. This will reflect in the status of the Charmed Kubernetes cluster.
3.) Add the relation to the Kubernetes masters and workers:
$ juju add-relation containerd kubernetes-master:container-runtime
$ juju add-relation containerd kubernetes-worker:container-runtime
The kubernetes-master unit will show various status messages as it goes through the switch process. While this is happening, the workload is marked as in “maintenance” mode.
The Charms, containing all the operational logic behind configuring and operating a K8s cluster, will manage and coordinate everything necessary to install and configure the new containerd runtime into the existing cluster.
Once the switch has been completed, your picture changes to this. Note the containerd runtime instead of Docker:
Replacing the container runtime in 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, 3-step process, which remains identical across all substrates supported by Charms, whether on-premise or on the public cloud.
Install Kubernetes on Ubuntu
Kubernetes on Ubuntu is free to use and always current – you get the latest innovations from the Kubernetes community within a week of upstream release. It works on any cloud (public, private, and bare-metal). Kubernetes on Ubuntu is the productive, open source way to manage containers and microservices, automating the time-consuming tasks of installing, patching, upgrading, and carrying out cluster health checks. Try Kubernetes on Ubuntu today!
What’s the risk of unsolved vulnerabilities in Docker images?
Recent surveys found that many popular containers had known vulnerabilities. Container images provenance is critical for a secure software supply chain in production. Benefit from Canonical’s security expertise with the LTS Docker images portfolio, a curated set of application images, free of vulnerabilities, with a 24/7 commitment.
Newsletter signup
Related posts
How should a great K8s distro feel? Try the new Canonical Kubernetes, now in beta
Try the new Canonical Kubernetes beta, our new distribution that combines ZeroOps for small clusters and intelligent automation for larger production...
Kubernetes backups just got easier with the CloudCasa charm from Catalogic
For a native integration for Canonical’s Kubernetes platform, Juju was the perfect fit, and the charm makes consuming CloudCasa seamless for users.
Canonical accelerates AI Application Development with NVIDIA AI Enterprise
Charmed Kubernetes support comes to NVIDIA AI Enterprise Canonical’s Charmed Kubernetes is now supported on NVIDIA AI Enterprise 5.0. Organisations using...