Containerd brings more container runtime options for Kubernetes. You're living dangerously if you're not moving to one of the recommended CRI runtimes these days! Let's parse mechanics (see the headline)!
Dockershim, which is built into Kubernetes’ kubelet code base, had always been viewed as a temporary solution, and maintaining it has been cited as a burden. A kubelet, which is an agent that runs on each node in a cluster, ensures that containers are running in a pod. The CRI standard allows container runtimes to be decoupled from the kubelet code base for simplified maintenance.
What is all the fuss about?
The removal of dockershim requires developers and cluster administrators to go through an "inconvenient, but necessary" migration as described by Víctor Jiménez Cerrada, a content manager engineer at container security software vendor Sysdig.
As dockershim is deprecated from K8s v1.24, you'll have to transition to one of the other compatible container runtimes. Simply ensure that the runtime you select supports the current settings of the Docker daemon such as logging.
0. The walkthrough
Well, let's look at the current situation? Take a look at how everything works now.
⏩ Kubelet calls the Container Runtime Interface plugin, via the CRI runtime service #API, to create a pod
⏩ CRI uses #containerd internal to create and start a special pause container and puts that container inside the pod’s cgroups and namespace
⏩ CRI configures the pod’s network namespace using CNI while Kubelet subsequently calls the CRI plugin, via the CRI image service API, to pull the application container image
⏩ Kubelet then calls CRI, via the CRI runtime service API, to create and start the application container inside the pod using the pulled container image
⏩ CRI finally uses containerd internal to create the application container, put it inside the pod’s cgroups and namespace, then to start the pod’s new application container.
How to switch from Docker to containerd?
1. Check what CRI is running
First we should check what container runtime is currently running. We do this with
$ kubectl get nodes -o wide
See the CONTAINER-RUNTIME column of the output.
2. Cordon and Drain node
After cordoning a node, new Pods cannot be scheduled to it. If you want to schedule a Pod to the node, you need to uncordon the node manually. If a node has been bound as backend target node, it will be removed from the target node list after it is condoned.
$ kubectl cordon <Node name>
$ kubectl drain <Node Name> --ignore-daemonsets
3. Stop services
$ systemctl stop kubelet
$ systemctl stop docker
4. Configure containerd
Disable the disabled_plugins line in /etc/containerd/config.toml to enable the CRI interface.
#disabled_plugins = ["cri"]
You can create a new default containerd config file if there isn't one already:
$ containerd config default > /etc/containerd/config.toml
Then, restart containerd:
$ systemctl restart containerd
5. Change the runtime
Add these two containerd runtime flags in /var/lib/kubelet/kubeadm-flags.env:
--container-runtime=remote
--container-runtimeendpoint=unix:///run/containerd/containerd.sock
6: Now you can start kubelet and test your new runtime
$ systemctl start kubelet
$ kubectl get nodes -o wide
7. Ok, uncordon your node:
$ kubectl uncordon <Node>
And you are done.
To summarize
A frog 🐸 in a well knows nothing of the sea.
This Japanese saying means someone sees the world through their limited perspective. They’re quick to judge and think very big of themselves. It’s used to remind someone that there are things bigger than them in the world.
🇯🇵 Oh, and if you're afraid of non-docker CLI, there is another gem from Japan which may help you, nerdctl tool which keeps legacy in order.
Do not be afraid of changes in the usual way of things! Many are for the better. Be the happy Podfather!
⚠️ The author recommeds you to read this article written by Rakesh Jain.
Top comments (0)