Part 2: How to migrate to containerd and CRI-O after Dockershim Deprecation in Kubernetes 1.24

In the last part of our series, we talked about what are CRI and OCI, differences between Docker, containerd, CRI-O and their architecture, etc. Recently, we’ve got to know that Docker is going to be deprecated from kubernetes! (check out this article officially from kubernetes) So let’s talk more in depth about why is it happening so?

Why is dokershim deprecated from K8s 1.24?

In version 1.24, Kubernetes will no longer support Docker as a container runtime. Docker is being phased out in favor of runtimes that use the Container Runtime Interface (CRI), which was built for Kubernetes. If you're a Kubernetes end-user, you won't notice much of a difference. This does not imply that Docker is dead, nor does it imply that you can't or shouldn't use it as a development tool. Docker is still a helpful tool for creating containers, and the images generated by the docker build may be used in your Kubernetes cluster. If you wish to create your cluster, you'll have to make certain adjustments to avoid cluster failure. As Docker will be deprecated from K8s 1.24, you'll have to transition to one of the other compatible container runtimes, such as containerd or CRI-O. Simply ensure that the runtime you select supports the current settings of the Docker daemon (such as logging).

Why are people freaking out when they hear this news?

There are two environments being considered, which is causing some confusion. There's a component within a Kubernetes cluster called a container runtime that's in charge of fetching and running container images. Although Docker is a popular choice for that runtime, it was not meant to be integrated into Kubernetes, which poses issues.

Will Dockerfiles be used in the future?

This modification is intended for developers that engage with Docker in a different environment. The Docker runtime inside the Kubernetes cluster is independent of the development Docker installation. Docker is still valuable to developers in all of the ways it was before the modification. Docker generates an OCI (Open Container Initiative) image, which isn't truly a Docker-specific image. Kubernetes will treat any OCI-compliant image in the same way, regardless of the tool used to create it. containerd and CRI-O are both capable of pulling and running such images.

How to switch from Docker to containerd & CRI-O?

Step 1: Cordon & Drain node

$ kubectl cordon <Node name>
$ kubectl drain <Node Name> --ignore-daemonsets

Step 2: Stop Services

$ systemctl stop kubelet
$ systemctl stop docker

Step 3: Remove Docker (optional):

apt purge docker-ce docker-ce-cli

OR

yum remove docker-ce docker-ce-cli

Migrating from Docker to containerd

Step 4: Configure containerd

Disable the disabled_plugins line in /etc/containerd/config.toml to enable the CRI interface.

#disabled_plugins = ["cri"]

Note: You can create a new default containerd config file if there isn't one already:

containerd config default > /etc/containerd/config.toml

And then restart containerd:

systemctl restart containerd

Step 5: Change the runtime Add these 2 containerd runtime flags in /var/lib/kubelet/kubeadm-flags.env :

--container-runtime=remote 
--container-runtimeendpoint=unix:///run/containerd/containerd.sock"

Step 6: Now you can start kubelet

systemctl start kubelet

Step 7: Test your containerd runtime

kubectl get nodes -o wide

Now you can uncordon your node:

kubectl uncordon <Node>

And you are done!

Migrating from Docker to CRI-O

Step 4: CRI-O repository & installation

$ add-apt-repository ppa:projectatomic/ppa
$ apt update
$ apt install -y cri-o-1.15

Step 5: Configure CRI-O & Kernel Create file 99-kubernetes-crio.conf

vi /etc/sysctl.d/99-kubernetes-crio.conf

And add the following lines:

net.bridge.bridge-nf-call-iptables  = 1
net.ipv4.ip_forward                 = 1
net.bridge.bridge-nf-call-ip6tables = 1

Apply changes to kernel:

sysctl -a

Verify crio.conf and edit cri-o to use Docker registry

Open file crio.conf:

vim /etc/crio/crio.conf

Check that the path to conmon is accurate in the configuration; if it isn't, run the command:

which conmon

Add the output to the crio.conf file

# Path to the conmon binary, used for monitoring the OCI runtime.
conmon = "/usr/bin/conmon"

Also make sure “registries” option is commented out

registries = [
        "quay.io",
        "docker.io",
]

Step 6: Now you can start CRI-O

$ systemctl enable crio
$ systemctl start crio

Step 7: Configure and start kubelet Edit vi /etc/default/kubelet and it should look something like this:

KUBELET_EXTRA_ARGS=--feature-gates="AllAlpha=false" --container-runtime=remote --cgroup-driver=systemd --container-runtime-endpoint='unix:///var/run/crio/crio.sock' --runtime-request-timeout=5m

And then start kubelet:

systemctl start kubelet

Step 8: Now you can uncordon your node:

kubectl uncordon <Node>

And you are done!

Summary

While concluding, I would like to include that, Docker getting deprecated from Kubernetes doesn’t mean that you can’t use Docker. It just means that Docker won’t be used as the default engine in Kubernetes and it’s all depending on your demands when choosing a specific container runtime as each of them has their own benefits.

Make sure to check out the official article from Kubernetes to know more (check it out here!). Stay tuned for more such contents!