Kubernetes (Sorta) Drops Docker Support: It’s Not as Bad It Sounds

In December 2020, news that Kubernetes was dropping "Docker support" caused a bit of panic. Fortunately, it wasn't Docker containers that were being deprecated, those will still work fine. Instead, Kubernetes is deprecating Dockershim.

First and foremost, it's not as bad as it sounded. Most end-users and developers probably won't notice much change, but it's still a big deal for some Kubernetes admins.

To get to help you get to the bottom of things, here we'll take a deeper dive into what Kubernetes is (and is not) depreciating, why they're doing it, when it'll happen, the surrounding confusion, and how it might impact you.

What Exactly is Kubernetes Doing?

As of version 1.20, Kubernetes is deprecating the use of Docker as a container runtime. Specifically, they're deprecating the use of Dockershim which is a sort of middleware that allows for the use of the Docker container runtime.

Here's the full rundown from CBT Nuggets trainer Ben Finkel:

What Caused All the Concern?

One of the reasons Kubernetes deprecation of Docker grabbed so much attention is people assumed the impact could be widespread. After all, Docker images and Kubernetes are some of the most popular tools of the trade in the DevOps world.

However, what got lost in the headlines was: This change isn't about Docker containers and images, it's about CRI, container runtimes, and Dockershim (more on all that below).

CRI and Dockershim: Why Kubernetes is Making the Change

Understanding why Kubernetes is dropping Dockershim support starts with understanding Dockershim. To understand Dockershim, it helps to understand Kubernetes container runtimes and the CRI (Container Runtime Interface).

• Container runtimes. Low-level software that enables Kubernetes to do things such as stop or start containers. Examples of container runtimes include Docker, containerd, and CRI-O.

• CRI (Container Runtime Interface). An API (application programming interface) that provides a standard way for Kubernetes kubelets to use different container runtimes.

Some container runtimes, like containerd, have supported CRI natively for some time. Docker does NOT support CRI. To enable Docker to work with CRI, the Kubernetes team made Dockershim as an intermediary that handles the CRI translation for environments with Docker container runtimes.

For a visual example of how Docker and Dockershim work compared to a CRI runtime (like containerd), check out the image below.

Image source: Kubernetes (Creative Commons BY 4.0)

As you can see, Dockershim is just an intermediate translation layer. For container runtime functionality, all Kubernetes needed from Docker was containerd. By getting rid of the extra layer, the Kubernetes project becomes easier for its developers to maintain.

OCI and Why Docker Containers Will Still Work Fine

The announcement of Kubernetes deprecating "Docker" caused such uproar because people initially assumed it meant Docker containers wouldn't work anymore. A big reason for that confusion was: Docker is often used imply containers, but Docker is also a platform and an organization. In this case, "Docker" simply meant one specific part of the tech stack (the container runtime) that makes up the larger Docker platform.

Images built using docker build or pulled from Docker Hub will still run in Kubernetes clusters. That means most end users will be largely – or even completely – unaffected.

Like many things in tech that "just work" together, the reason for this is standardization. In this case, the OCI (Open Container Initiative) – of which Docker was a founding member — is what provides the standards that allow Docker images and other container runtimes to work together. OCI provides a runtime specification (runtime-spec) and an image specification (image-spec). Any OCI runtime can run any OCI image. Because Docker container images meet the OCI standards, they will continue to work fine in Kubernetes clusters regardless of the underlying OCI container runtime.

Most People Will Only Notice a Warning Message

As of version 1.20, the only difference you'll notice if you’re using Docker as a container runtime is a warning message. As we can see in the GitHub pull request, this warning message will be displayed to users of the Docker Container Runtime: "Using dockershim is deprecated, please consider using a full-fledged CRI implementation”

For now, that's all that has changed. Of course, that means Kubernetes admins need to start planning for what's to come.

The Kubernetes FAQ on Dockershim provides some insight on when we can expect to see support dropped. Currently, the earliest possible timeline for dropping Dockershim is Kubernetes version 1.23 in late 2021.

Docker Alternatives for Container Runtimes

If you need a replacement container runtime, there are several viable options. Two of the most popular choices are:

containerd: A Docker Spinoff

Initially, containerd (yes, it is all lowercase!) started out as part of Docker. Today, after becoming a CNCF (Cloud Native Computing Foundation) graduated project in 2019, it is still part of Docker but also stands on its own as a CRI-compliant container runtime that can be used independent of Docker. At a high-level containerd runs containers, pushes and pulls images to/from a registry, and manages images. For an example of what that means in practice, check out the image of containerd's architecture in context below:

Source: https://containerd.io/ License: CC-BY-4.0

CRI-O: A Lightweight Alternative to Docker

Kubernetes projects including Minikube and openSUSE's Kubic use CRI-O (yes, all caps for this one!) as their container runtime. CRI-O considers themselves a lightweight alternative to Docker, rkt, and other container runtimes for Kubernetes. Currently, CRI-O is a CNCF incubating project.

Of course, those aren't your only two options. In theory, any CRI-compliant runtime could work. However, you'll want to make sure it supports all the specific features and use cases you need to support such as these examples from the Kubernetes Dockershim FAQ:

• Logging

• Kubectl plugins that need Docker CLI (Command Line Interface) or control socket (e.g. Docker in Docker)

• Scripts that directly call Docker or call Docker using its control socket

• Tools like kube-imagepuller that need direct Docker access

Mirantis and Docker Will Keep Dockershim Alive

While there are alternatives to using Dockershim, there is also some demand to keep it around. Fortunately, in early December 2020, Mirantis announced that they – along with Docker – will continue to maintain Dockershim.

After Kubernetes drops support, the Mirantis/Docker maintained version Dockershim will be available as a standalone component. Some configuration changes will be required to integrate the standalone component, but you'll be able to keep using Docker as your Kubernetes container runtime.

Conclusion

To recap what happened with Kubernetes and Dockershim over the last few months:

• As of version 1.20, Kubernetes has deprecated the use of Dockershim which effectively deprecated Docker as a Kubernetes container runtime.

• Dockershim support won't be dropped until after Kubernetes 1.22, so late 2021 at the earliest

• Headlines and Tweets in early December got people thinking this meant Docker containers won't work in Kubernetes in the future. However, that's not the case. Docker images and Docker containers will continue to work just fine in Kubernetes clusters

• For the most part, this change will only impact Kubernetes admins, not developers building Docker images for use in Kubernetes clusters.

• Mirantis and Docker will pick up support for Dockershim so admins can keep using it after Kubernetes drops it.

What that means for you depends on how you use Docker and Kubernetes together. It could mean anything from "nothing will change" to "you need to find a new container runtime".

Unless you're a Kubernetes admin or using workflows that involve Docker in Docker and Kubernetes, you probably don't need to worry much. If you are one of the few affected by the change, you'll need to decide what to do with your Kubernetes container runtime. You could switch to something like containerd or decide to continue to use Dockershim as supported by Mirantis and Docker. Whatever the case, make sure to have your plans in order before Kubernetes 1.23 is released.