Starting with Kubernetes 1.20, released on December 8th, developers have received a warning that Kubernetes is deprecating Docker. This means that Kubernetes officially ceases to support the Docker tech stack, as you can already see in the release notes on GitHub.

The news wasn’t a big surprise. The Kubernetes development team had been planning and preparing this step for three years, so it was only a matter of time. Since Kubernetes was originally developed to orchestrate Docker containers, many Kubernetes users probably didn’t like this.

But, don’t panic! Let’s see what this really means.

To make things clear

Let’s clear it up from the beginning. Kubernetes will continue to run Docker images. Docker images are fully compatible with the OCI (Open Container Initiative), regardless of where you host them. Kubernetes might continue to run container clusters in other ways, but Docker images will be able to run on Kubernetes clusters just like they did by now.

There are two different environments here, and that’s what causes the main uncertainty. The container runtime within the Kubernetes cluster takes care of pulling and running the container files. Docker is one of the options for a container runtime.

However, Docker wasn’t meant to be embedded within Kubernetes, which is causing an issue. Kubernetes is a container orchestrator that strives to work beyond Docker with the larger container community. In reality, Kubernetes only uses a limited portion of the tech stack of Docker.

What Kubernetes actually wants to achieve is to remove the need to install Docker and recommend more lightweight alternatives. As Docker includes various tools and APIs to allow you to run containers.

With this change, you’ll be able to install something that doesn’t take up so much space. Containerd and CRI-O are container runtimes that support the standard interface.

The background

The background is apparently the division of the Docker ecosystem into numerous sub-projects with small components that are undergoing a differentiated development. The Kubernetes community finds the Docker daemon to be increasingly bloated. Kat Cosgrove, Principal Cloud Engineer of JFrog, put things into perspective on Twitter:

Cosgrove highlights the difference between the Docker runtime and Docker as a complete package. The most important thing for Kubernetes is the container runtime, and Docker is incompatible with the Container Runtime Interface (CRI). This is why it always needed the dockershim layer.

According to the statement, the main reason why Kubernetes is deprecating Docker is to actually drop the support for dokershim. The dockershim was basically the bridge between the Docker API and the Kubernetes CRI. Now that the dockershim support is no longer here, Containerd has come up as a technically better solution.

CRI-O and Containerd as alternatives

Docker is not dead with the new development, it just no longer works as a runtime environment in Kubernetes. Developers will have to switch to Containerd with the next version.

For example, Red Hat has been functioning without Docker for a while, relying on CRI-O and Podman. For Kubernetes users, the innovation should make work easier, since in the future, the standardized CRI interface will simply be used for communication with the container runtime. Alternatives like CRI-O and Containerd support this interface.

The final conclusion

There are many other lightweight tools that you can use to build or run container images.

However, Docker is basically what everyone thinks of when they hear the word “containers”. Docker is responsible for the rise of containers and we have to acknowledge that. Docker made containers transparent, representing them as the main concept in cloud-native DevOps.

Long story short, no reason to worry here. Kubernetes will continue running with the current Docker containers, and there are still some months for Kubernetes administrators to roll out the required improvements. Dockershim is retiring, but Docker is not dead at all.

So, what we think is that Docker isn’t going anywhere soon. Developers will probably find it hard to switch immediately. However, this leaves a lot of space for many other vendors to shine.

The deprecation note is documented on GitHub in the release notes. More information on the runtime environments for containers can be found in the Kubernetes documentation To avoid confusion, Kubernetes also clears things up in this blog post.