With the latest and final updates of this year, Kubernetes announced deprecating Dockershim, the container runtime interface (CRI) shim for Docker. It means that the version v1.20 of Kubernetes will get a deprecation warning for Docker. But there is nothing to worry or panic about, says the open-source container orchestration tool in its official release. As the announcement has created a massive confusion in the developer community, in this article, we will break down this announcement by Kubernetes. 

Is Kubernetes Parting Ways With Docker?

Kubernetes has come up with many interesting announcements in its newer release. It brought about 42 enhancements, out of which 15 are moving to beta, and 16 are entering alpha. One of the major announcements of the new update is the deprecation of Docker, which is essentially a set of platform-as-a-service that are used to make containers easy to use. This open-source platform has millions of containerised applications. The Kubernetes server runs within a Docker container on the local system. With the Kubernetes support enabled, one can deploy workloads, in parallel, on Kubernetes. 

The recent announcement stated that Kubernetes would be deprecating the use of the open-source Docker container runtime and instead will use runtimes that use the Container Runtime Interface (CRI). It further stated that the Docker-produced images would continue to work in the cluster with all CRI compliant runtimes but will not support the container runtime. However, “it is not as dramatic as it sounds,” read the statement. 

It further stated that it does not mean the death of Docker as a development tool. As a matter of fact, Docker can still be used to build containers and images, which can still run in the Kubernetes cluster. They will continue to work as they always have, and end-users of Kubernetes will likely not notice the change. 

However, the Docker runtime support may be removed in the future release, mostly in late 2021, in its 1.22 release. Following which, the user will need to switch to other compliant container runtimes such as containerd or CRI-O. This also needs to be ensured by managed Kubernetes services such as EKS or AKS before the Docker support is finally removed in the future version. 

What Is The Confusion?

Addressing the confusion, Kubernetes stated that inside the Kubernetes cluster, a thing called a container runtime, which is responsible for pulling and running container images. While Docker is a popular choice for that runtime, there can be other alternatives such as CRI-O and containerd. 

While Docker has many UX enhancements that make it really easy for humans to interact with, those UX enhancements are not necessarily required for Kubernetes. To support this human-friendly abstraction layer, Kubernetes cluster has to use another tool called Dockershim, which is an additional thing for Kubernetes to maintain. So, Kubernetes is removing Dockershim from Kubelet, which, as a result, removes the support for Docker as a container runtime. 

Wrapping Up

Clearing the confusion, Kubernetes stated that the Docker installation that is being used in the development is unrelated to the Docker runtime inside the Kubernetes cluster. While it may sound confusing, the bottom line is that Docker is still as useful as before. This is because the images produced by Docker isn’t really a Docker-specific image, instead is an OCI (Open Container Initiative) image and can be assessed regardless of the tool used to build it. While it may cause initial hiccups, things will get easier as time goes, believes Kubernetes. “…it isn’t catastrophic, and generally, it’s a good thing.”