The deprecation of Docker on Kubernetes

Shocking news

This week, the official Kubernetes blog created a post informing all users that from version 1.20 onward, Kubernetes will deprecate the usage of Docker as a container runtime, removing it entirely on version 1.23. As you probably guess, this caused some level of confusion in a lot of people: "What will happen now?", "Should I migrate do swarm?", "What about my images?", "Is docker dead/dying?", "Why the hell are they doing this?".

While this sounds like terrible news for both Docker and Kubernetes users, this isn't that big of a deal, and I will explain to you why.

The deprecation does make sense

The important thing to understand is what exactly is being deprecated. According to the official blog post, the thing being deprecated is "[the usage of] Docker as an underlying runtime". But what does this means? To make sense of this, we need to clear some definitions first.

When we talk about Kubernetes, we're talking about a layer of abstraction that helps us manage our clusters and automate the deployments and scaling of our applications, and more. To do so, Kubernetes needs to talk to a container runtime. This runtime is the piece of the puzzle responsible to download the requested images and create, run, or destroy containers on the host machine.

Likewise, when we say Docker, we're referencing not a single thing, but a whole stack, that contains, among other things its own container runtime. And this specific piece of software (the container runtime) is precisely what is being deprecated on the newer versions of Kubernetes.

To be more precise, the Kubernetes team is dropping the support for the dockershim, to avoid being tightly coupled with the Docker runtime. Despite Kubernetes having a proper interface to talk to the different container runtimes - the CRI - the Docker container runtime does not follow this interface (Docker was created before that) and as such, you need a little... ahem... "hack" of sorts to glue both things together. This "little hack" is called dockershim.

This deprecation is happening now because according to the proposal for the deprecation the shim itself is part of the main kubelet core. For those who don't know, kubelet is the agent that runs on every node of the cluster and is responsible to use the container runtime to turn our pod specifications into reality. To cut it short, this means that a piece of provider-specific (in the case, Docker) logic is implemented on the kubelet itself. This is far from ideal because it both increases the complexity and coupling to a specific provider. Docker shouldn't be treated as a "special" case; it should be treated like any other runtime that implements the CRI.

The impact on users

We've talked a lot about container runtimes, but how does it affect my existing docker images? Well, the good news is that nothing changes in this regard. Yes, you read right: despite deprecating the docker runtime, your docker images will continue to work as you expect them to.

Why? The reason is that docker images are fully compatible with the image specification of the Open Container Initiative, so nothing will change in this case. There is no need to freak out or to "abandon" Docker images because they're already following the standard for years. It is even possible that you might already be using a different engine and won't be affected at all by these changes. For example, I'm running a local development cluster with KiND for several months (expect a tutorial about it soon) and the change in runtime is completely transparent (kiND uses containerd, and not docker, as a runtime).

The people that (might) be impacted are the kubernetes administrators, that need to ensure that the clusters must change to a different runtime before version 1.23 drops out (expected to be released at the end of 2021). If you're using Docker as a runtime, it is best to go to the official Kubernetes documentation and read about container runtimes, to start planning (and playing around) with different runtimes. This shouldn't be a painful transition, and you have a lot of time to plan and test for it.

In summary

This news looks earth-shattering at first glance, but in reality, chances are you might not be directly impacted by the change at all. In summary:

1. Are you a developer, that uses or creates docker images to deploy your applications everywhere? If so, nothing changes, carry on with your existing tools and workflow.
2. Do you use a cloud-managed Kubernetes service, like Amazon EKS or Google's GKE? Check with your provider what are their plans and what you should do to migrate your nodes.
3. Do you manage your own cluster? Check on the documentation what is the runtime you're currently using and how to configure it.

Again, there is no need to panic, and even the people that will be directly affected by this decision - the kubernetes administrators - have enough time to adapt to these changes, considering the actual drop of dockershim will happen only near the end of 2021. As long as you have a migration plan, your applications should be safe.