Recently, Kubernetes announced it will deprecate Docker as the container runtime in the forthcoming releases after Kubernetes 1.20. As per the official documentation it is currently planned for the 1.22 release in late 2021. This news caused a big noise in the cloud-native field and added a lot of confusion on why Kubernetes deprecated docker and what next? In this article, we will learn the reason for it.

Official Announcement


The below is the official confirmation from the Kubernetes changelog on why did Kubernetes choose to abandon Docker? We will see that in detail in the below information chain.

Docker support in the kubelet is now deprecated and will be removed in a future release. The kubelet uses a module called “dockershim” which implements CRI support for Docker and it has seen maintenance issues in the Kubernetes community. We encourage you to evaluate moving to a container runtime that is a full-fledged implementation of CRI (v1alpha1 or v1 compliant) as they become available.

Reference: https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#deprecation

Why Kubernetes deprecated docker?


We need to understand Dockershim briefly first. Inside the Kubernetes cluster, the container runtime job is doing the job of pulling and running your container images. Since Docker is the popular choice for that runtime and Dockershim is a bridging service (extracts only run time) that helps Kubernetes communicate with docker. Because Docker itself has not yet implemented CRI. But to this day, maintaining Dockershim has become a heavy burden for operations and opens a bigger attack surface and requires maintenance. In short, Docker was not designed to be integrated inside Kubernetes.  As a result, Kubernetes choose to remove Docker in the upcoming release.

Refer: Kubernetes Architecture

Alternatives of Dockershim: What Next?


Kubernetes community recommends considering using an available container runtime (containerd and CRI-O)  that includes a complete implementation of CRI  (Container Runtime Interface)

Can we use existing Docker image?


We can still use the image generated by Docker because it is not actually a Docker-specific image, but an OCI (Open Container Initiative) image. No matter what tool you use to build the image, any image that meets the OCI standard looks the same in Kubernetes. Both containerd and CRI-O can extract these images and run them. So we can still use Docker to build container images, and we can continue to use them on containerd and CRI-O.

Can we use Docker in Kubernetes 1.20?


Yes, if you use Docker as the runtime in Kubernetes 1.20, it will only print a warning log when Kubelet starts. Kubernetes will remove dockershim as early as the 1.23 version released in late 2021.

Which CRI implementation should I use?


This is a more complicated issue, and it depends on many factors. If you have used Docker before, then migration to containerd should be a relatively easy choice, and as per the official documentation in Kubernetes, containerd has better performance and lower cost. Of course, you can also explore other projects in the CNCF landscape to choose a more appropriate environment.

Reference


1. https://kubernetes.io/blog/2020/12/02/dockershim-faq/#which-cri-implementation-should-i-use

2. https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/

3. https://kubernetes.io/blog/2020/12/02/dockershim-faq/