Kubernetes v1.24 and later releases ship with out Dockershim after its deprecation in December 2020’s v1.20 launch. Dockershim’s not accessible as a built-in container runtime. You might want to use a unique supported runtime as an alternative, akin to containerd, CRI-O, or Docker Engine with the cri-dockerd adapter.
On this article, we’ll present how you can test whether or not you’re affected, then clarify how one can migrate to a unique runtime. It is best to take these steps earlier than you improve to Kubernetes v1.24 or a later model so your cluster’s workloads aren’t impacted.
What Was Dockershim?
Dockershim was developed as a essential element so Kubernetes might assist extra container runtimes. At first of the challenge, Kubernetes solely labored with Docker Engine. This restriction was eliminated by the introduction of the CRI customary. Any CRI-compatible runtime might now be used with Kubernetes, together with containerd and CRI-O, an OCI implementation of the usual.
Whereas CRI introduced new flexibility to Kubernetes, it introduced a difficulty for current clusters. Docker lacked assist for the CRI customary so Dockershim was constructed to let the Kubernetes staff layer compatibility on high. Dockershim was a direct integration with Docker Engine that was all the time supposed to be a short lived measure.
The container motion is now rather more than Docker, as the unique Kubernetes push to CRI demonstrates. Docker itself has cut up into particular person parts with its runtime extracted as containerd, a graduate of the Cloud Native Computing Basis (CNCF).
containerd is absolutely supported by Kubernetes and extra suited to standalone use in cloud environments. Kubernetes doesn’t require the Docker CLI and its bevy of options to run your Pods; all it wants is the power to start out and run containers at a comparatively low stage. Dockershim has been eliminated as a result of it was troublesome to take care of. Its use created fragile code that was tightly coupled to Docker Engine’s implementation.
Checking Whether or not You’re Utilizing Dockershim
Lately created clusters on fashionable platforms are extremely unlikely to be utilizing Dockershim. This contains clusters managed by common cloud suppliers akin to Amazon EKS, Azure AKS, Google GKE, and DigitalOcean DOKS.
You’re most definitely to want to take motion for those who preserve your personal cluster and first set it up a number of years in the past. You’ll be able to test whether or not you’re utilizing Dockershim because the runtime for any of your Nodes by operating this Kubectl command:
$ kubectl get nodes -o huge NAME STATUS VERSION CONTAINER-RUNTIME node-1 Prepared v1.22.8 docker://19.3.1 node-2 Prepared v1.22.8 containerd://1.4.13
On this instance, one of many nodes is utilizing containerd and will be left as-is. The opposite node is configured utilizing Docker and may very well be affected by the Dockershim removing. You’ll be able to test by operating this command on the Node:
$ tr ' ' < /proc/"$(pgrep kubelet)"/cmdline | grep "--container-runtime"
Your Node is utilizing Dockershim to run containers if no output’s displayed. Should you do get some output, examine the displayed --container-runtime-endpoint flag worth to find out if Dockershim is energetic. A runtime endpoint of unix:///run/containerd/containerd.sock alerts containerd is used, so no migration is critical.
Altering A Node’s Runtime
Nodes which can be utilizing Dockershim should be up to date to use a unique runtime. First drain the Node’s workloads utilizing Kubectl, so your Pods are rescheduled to different Nodes in your cluster. It is best to cordon the Node too to cease any new Pods being scheduled.
$ kubectl cordon node-1 $ kubectl drain node-1 --ignore-daemonsets
Subsequent run the next instructions on the Node itself. Start by stopping the Docker daemon and the Node’s Kubelet employee course of:
$ systemctl cease kubelet $ systemctl disable docker.service --now
Now you possibly can set up your new runtime.
Utilizing containerd
containerd is mostly the popular resolution for present clusters. It is best to be capable to migrate to containerd for those who’re not counting on particular options of Docker Engine. If you’re, head to the next part and set up cri-dockerd as an alternative.
Add Docker’s repository to your system in case your package deal lists don’t already embrace it. containerd is distributed in Docker’s repository.
$ sudo apt-get replace $ sudo apt-get set up ca-certificates curl gnupg lsb-release $ curl -fsSL https://obtain.docker.com/linux/debian/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg $ echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://obtain.docker.com/linux/debian $(lsb_release -cs) secure" | sudo tee /and so on/apt/sources.listing.d/docker.listing > /dev/null
Set up containerd:
$ sudo apt replace $ sudo apt set up containerd
Now replace the Node’s Kubelet configuration file to make use of the brand new runtime. Open /var/lib/kubelet/kubeadm-flags.env. Search for or add the --container-runtime and --container-runtime-endpoint flags with the next values:
--container-runtime=distant--container-runtime-endpoint=unix:///run/containerd/containerd.sock
Subsequent change the socket annotation saved towards the Node object within the Kubernetes management aircraft:
$ kubectl edit node node-1
Within the file that opens, discover the kubeadm.alpha.kubernetes.io/cri-socket annotation and alter it to unix:///run/containerd/containerd.sock. Save and shut the file to replace the Node’s object.
Now restart Kubelet:
$ systemctl begin kubelet
Enable the Node a number of moments to start out and connect with the Kubernetes management aircraft. It is best to be capable to repeat the get nodes command and see that containerd is now getting used.
$ kubectl get nodes -o huge NAME STATUS VERSION CONTAINER-RUNTIME node-1 Prepared v1.22.8 containerd://1.4.13 node-2 Prepared v1.22.8 containerd://1.4.13
Lastly take away the cordon you positioned across the Node so it could possibly start to obtain Pods:
$ kubectl uncordon node-1
Utilizing cri-dockerd
cri-dockerd is a runtime collectively developed by Docker and Mirantis. It’s successfully a standalone model of Dockershim that’s independently maintained. It permits you to maintain utilizing acquainted performance with out encumbering the Kubernetes challenge with Dockershim’s upkeep necessities.
Ensure you’ve already obtained Docker Engine put in. Then set up cri-dockerd by downloading the most recent binary from GitHub releases:
$ wget https://github.com/Mirantis/cri-dockerd/releases/obtain/v0.2.0/cri-dockerd-v0.2.0-linux-amd64.tar.gz $ tar xvf cri-dockerd-v0.2.0-linux-amd64.tar.gz $ mv cri-dockerd /usr/native/bin/
Subsequent obtain, set up, and allow cri-dockerd’s systemd service configurations:
wget https://uncooked.githubusercontent.com/Mirantis/cri-dockerd/grasp/packaging/systemd/cri-docker.service wget https://uncooked.githubusercontent.com/Mirantis/cri-dockerd/grasp/packaging/systemd/cri-docker.socket sudo mv cri-docker.socket cri-docker.service /and so on/systemd/system/ sudo sed -i -e 's,/usr/bin/cri-dockerd,/usr/native/bin/cri-dockerd,' /and so on/systemd/system/cri-docker.service sudo systemctl daemon-reload sudo systemctl allow cri-docker.service sudo systemctl allow --now cri-docker.socket
Now you possibly can modify your Node’s Kubelet configuration to make use of cri-dockerd. That is much like configuring a Node to make use of containerd.
Open /var/lib/kubelet/kubeadm-flags.env. Search for or add the --container-runtime and --container-runtime-endpoint flags with the next values:
--container-runtime=distant--container-runtime-endpoint=unix:///var/run/cri-dockerd.sock
Subsequent change the Node object’s socket annotation:
$ kubectl edit node node-1
Within the file that opens, discover the kubeadm.alpha.kubernetes.io/cri-socket annotation and alter it to unix:///var/run/cri-dockerd.sock. Save and shut the file to replace the Node’s object.
Now restart Kubelet:
$ systemctl begin kubelet
Wait a number of moments after which use Kubectl to test the Node is up. It should nonetheless present the Docker runtime nevertheless it’s now primarily based on the standalone cri-dockerd, as an alternative of the Dockershim that’s built-in with Kubernetes.
$ kubectl get nodes -o huge NAME STATUS VERSION CONTAINER-RUNTIME node-1 Prepared v1.22.8 docker://19.3.1 node-2 Prepared v1.22.8 containerd://1.4.13
Now you can take away the cordon you positioned across the Node. It should begin to settle for Pod scheduling requests once more.
$ kubectl uncordon node-1
Conclusion
Kubernetes v1.24 eliminated the Dockershim element that beforehand built-in CRI compatibility for Docker Engine. Whereas most up-to-date clusters will likely be unaffected, you need to test whether or not you’re utilizing Dockershim earlier than upgrading to the brand new launch.
The runtime to modify to depends upon the way you presently use your cluster. containerd is normally a sensible choice for those who’re not utilizing Docker options. You should use cri-dockerd to convey again Dockershim-like integration if it is advisable preserve compatibility with current tooling that’s reliant on Docker Engine. This additionally helps for those who’re mounting the Docker daemon socket (/var/run/docker.sock) into your containers to energy Docker-in-Docker workflows.
Dockershim’s removing doesn’t influence the way you construct and use container photos. Kubernetes can nonetheless run photos created with docker construct they usually’re appropriate with all supported runtimes. CRI runtimes work with any OCI-format picture, as output by Docker and different picture builders.
