#kcdchennai #kubernetes #docker #devops

Author: Jothimani Radhakrishnan (Lifion by ADP). A Software Product Engineer, Cloud enthusiast | Blogger | DevOps | SRE | Python Developer. I usually automate my day-to-day stuff and Blog my experience on challenging items.

Intro

Hey Docker lovers <3, this is not going to be a happy story for you guys. Yes, for me as well. Like everyone, I loved using Docker very much. When I get to know about this project (Dockershim), it was a heartbreaking moment for me.

Before knowing about Dockershim let us discuss the following.

Kubelet takes care of managing worker nodes in relation to the master node. It ensures that the specified containers for the pod are up and running.

To know more about kubelet: https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/

Container runtime:

Container runtime is a software that is responsible for running containers. To create a pod, kubelet needs a container runtime environment. For a long time, Kubernetes used Docker as its default container runtime.

This creates a problem/dependency that whenever docker release updates/upgrades it breaks the Kubernetes.

There are also several container runtime tools.

• containerd
• CRI-O
• Docker
• Rocket
• LXD
• OpenVZ
• Windows Server Containers

Okay! Coming back to the context of this blog. Docker is going to be deprecated from Kubernetes as default and containerd is going to replace the place.

What is Dockershim?

Docker existed as a default engine in k8s, after introducing additional CRI access (Container runtime interface) in k8s, Kubernetes created an adaptor component called dockershim.

The dockershim adapter allows the kubelet to interact with Docker as if Docker were a CRI compatible runtime.

Img src: Kubernetes documentation

Switching to Containerd as a container runtime eliminates the middleman

Points to Check to make sure your environment is not affected by this change. You can continue to use Docker to build images, using Docker is not considered a dependency.

All these below pointers should be considered and updated as per your native CRI.

Make sure to update your docker commands operations that are running inside the pod. For example, listing running containers in the worker node using docker ps which might not work after the deprecation.

Check for any private registries or image mirror settings in the Docker configuration file (like /etc/docker/daemon.json)

1. Any scripts that ssh in worker nodes and does any docker CRUD operations.
2. Any third-party tools using docker needs to be updated. Migrating Telemetry
3. Any alerts that are configured based on Docker specific errors should be updated.
4. Any automation or bootstrap scripts based on Docker commands should be updated.
5. The list is not limited as mentioned above and might vary based on your adoption of usage.

To know more about the deprecation FAQ: kubernetes.io/blog/2020/12/02/dockershim-faq

Thank you,

Happy containerd! :p

Reference: developer.ibm.com/blogs/kube-cri-overview kubernetes.io/docs/tasks/administer-cluster.. kubernetes.io/blog/2022/01/07/kubernetes-is..