No, Docker isn’t Dead
By: Yitaek Hwang
Tags: Coding, Kubernetes, Docker, Programming

This tweet drowned out other coverage on the v1.20 release detailing nice improvements such as graceful shutdown of nodes and efficient reboot. Massive confusion ensued until two new blog posts came out to clarify the deprecation notice:

In short, support for dockershim, the bridge between the Docker API and the Kubernetes Container Runtime Interface (CRI), is being dropped, in favor of other CRIs such as containerd and CRI-O. This means that existing Docker images built via docker build will continue to work (as well as other build options like img, buildah, or kaniko), but the Docker runtime (component that pulls and runs your images) will be removed in v1.22 release in late 2021.

Wait, What?

If you are still confused, it is likely because Docker has become synonymous to containers over time, even though it actually refers to an entire tech stack. Docker was introduced before Kubernetes to popularize the Linux container pattern. This meant that Docker was not originally designed with Kubernetes in mind, leaving some parts incompatible and others redundant.

Kubernetes, on the other hand, is a container orchestrator that aims to work with the broader container ecosystem beyond Docker. When looking at the Docker architecture, Kubernetes actually only uses a small part of Docker’s tech stack:

Image Credit: Kohei Ota

The critical thing here is containerd, a container runtime element Docker uses to pull and run images. Unfortunately, Docker currently does not support Kubernetes’s CRI standard so Kubernetes maintainers wrote a layer to support this (dockershim). However, dockershim was a temporary solution and long-term maintenance became an issue as it became incompatible with newer features (e.g. cgroups v2, user namespaces). This is why Kubernetes maintainers are deprecating support for dockershim (and hence Docker) and encouraging migration to CRI-compliant runtimes.

So what does this mean for you?

For Developers

Good news, nothing should change. Most likely, your interaction with Docker is local development and building a Docker image. The image built by Docker is Open Container Initiative (OCI) compliant image that other runtimes that Kubernetes support knows how to pull and run.

The edge case may be if you are using the Docker socket ( /var/run/docker.sock ). in Docker in Docker scenario (perhaps with Gitlab runners to run integration tests on a dev cluster). In this case, look for alternative container solutions such as img, buildah, or kaniko.

For Kubernetes Admins

If you are administrating a Kubernetes cluster, you will need to replace Docker with a CRI-compliant runtime such as containerd or CRI-O (or other CNCF alternatives) by v1.22 release in late 2021 (v1.20 will only display a warning). The good news is that managed Kubernetes providers like GKE and AKS already support containerd, and EKS will likely follow since Fargate already supports containerd. Sufficient testing is in order, but migration to containerd should be relatively painless since Docker also uses containerd underneath the hood.

TL;DR

Long story short, there’s no need to panic. Kubernetes will continue to work with your existing Docker containers, and Kubernetes admins still have several months to roll out the necessary changes. Dockershim is going away, but Docker is not dead.