Kubernetes Is Deprecating Docker Support — What Does This Mean?

Starting with Kubernetes 1.20, released a while ago, 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. 

Will Kubernetes Still Run Docker Images?

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. 

It’s important to separate Docker images from the Docker runtime. Kubernetes can still run Docker images because they comply with the Open Container Initiative (OCI) format. However, Kubernetes no longer relies on the Docker runtime (the background engine that runs the containers), opting instead for runtimes like Containerd or CRI-O.

Kubernetes only uses the Docker runtime component to run containers, but not Docker’s full feature set like its CLI, image builder, or daemon APIs.

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. 

Understanding the Split Between Docker and Kubernetes

The shift began as the Docker ecosystem split into smaller sub-projects, each evolving at its own pace. Over time, the Docker daemon became increasingly complex, bundling in features that Kubernetes didn’t use. This added overhead led the Kubernetes community to explore more lightweight runtimes better suited to its needs.

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 PR 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.

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. 

For all Microtica users, Microtica’s pipelines won’t be affected by this change. Microtica uses Docker as a runtime for the pipeline steps. Building Docker images using Microtica pipelines will not affect the deployments on Kubernetes since images are fully compatible with the OCI.