Kubernetes Dropping Docker Runtime Support – What It Means for Enterprises

Dependency on containers

Containers are ruling the world of both open source and enterprise software, and the adoption rates are over 90% in the case of Docker and over 80% for Kubernetes.

Docker has become synonymous with containers and Kubernetes has become synonymous with a container orchestration engine.

It seemed to be inevitable that they both work together and are tightly bound together, forever.

Until the news broke out about the deprecation of Docker shim in Kubernetes 1.20.

Yes, it’s true, Kubernetes will deprecate the Docker runtime, starting from version 1.20.

Ian Coldwater, Kubernetes SIG Security, wrote on his twitter account: “Docker support is being deprecated in Kubernetes. You need to pay attention to this and plan for it. THIS WILL BREAK YOUR CLUSTERS.”

Let’s analyze what it means and what we are supposed to do about it.

What if not Kubernetes?

The question is not as absurd as it may sound. There are other alternatives for container orchestration, and despite Kubernetes winning the mindsets and market share, there are still other viable options.

→ Avenga about Kubernetes – how hot can it get?

So unless someone invested heavily in Kubernetes (like most of the enterprises have), it is possible to run Docker containers without Kubernetes. For instance, Docker’s own Docker Swarm, which is not expected to drop support for Docker, for quite obvious reasons. And let’s not forget Apache Mesos, which was the thing before the meteoric rise to popularity of Kubernetes.

But this kind of migration is not necessary, and I’m going to explain why.

What if not Docker?

“We encourage you to evaluate moving to a container runtime that is a full-fledged implementation of CRI (v1alpha1 or v1 compliant) as they become available.”

What?!

Yes, there are other container runtimes which implement the now famous Container Runtime Interface (CRI), which Docker does not.

So what’s going to happen to all the containers everybody created?  All these DOCKERFILE files that define how to build Docker containers as the primary deployment method?

Close to nothing is happening to them.  They will be executed by another container runtime and be compliant with CRI. Docker means that it is the file format of the containers (metadata, files inside the container, to lesser extent configuration) and that this is not going to be affected by this recent move from Kubernetes. The same applies for Docker container registries, such as Docker Hub; it won’t be deemed obsolete by this move.

Why is Kubernetes dropping support for the Docker engine?

There are two thoughts of reasoning.

One is technological.  The more components have to be maintained, the less secure the solution is because of the increased attack surface.

The other is related to maintenance. Kubernetes does not want to maintain a Docker shim anymore as they are not responsible for Docker development and codebase.

Another, and probably the most important, is that it’s a successful attempt to change the mindsets of DevOps and developers. Right now, container means Docker, but  this news from Kubernetes changed that. Many people are learning right this very minute that there are other container engines than Docker. It’s a part of competition. Docker wanted to win the war of container orchestrators with their Docker Swarm and failed. Now Kubernetes is making Docker even weaker in the perception of the tech community.

What to do?

Was Docker runtime a bad choice, always?

One of the answers to the news is that nobody should have ever used Docker runtime in the first place, because it was never compatible with the CRI API and it required a proxy (shim for API translation) to make it work with Kubernetes. For me, this kind of answer is unacceptable. There’s an assumption among the hard core Kubernetes fans that everybody follows the development of Kubernetes, and this move (depreciation of Docker runtime) was inevitable at some point in time. Maybe it was, but touching on such a delicate subject matter, which affects so many, deserves better answers.

Prepare for the inevitable

For the majority of DevOps specialists, there’s been a hidden assumption not to worry about this pair (Kubernetes-Docker) at all . . . so many things will change, but at least we can trust this as a foundation of modern cloud native computing.

Doing nothing is not something that will suddenly destroy your business applications once the depreciation happens. It won’t be switched off overnight. In the beginning, there will be just a warning message about the incoming drop of support. Things are about to change and by the end of 2021 is when things are expected to stop working.

The Kubernetes team advises to “make sure your worker nodes are using a supported container runtime”, which means testing containers on other than Docker engines.

Docker images are expected to run well in other engines. But as usual, if they were tested on local developer machines using Docker runtime, there’s a chance that they will fail or behave erratically with different runtime environments.

The risk is minimized by the fact that, the Docker engine uses containerd and runc engines internally, and what is being removed is a proxy layer between containerd and Kubernetes. 

One of the ideas here is to use different container runtimes (which will continue to be supported by Kubernetes, such as containerd and CRI-O) locally, starting with the developer’s workstations to avoid any surprises in the testing and production environment. For instance, MiniKube and other (relatively) lightweight Kubernetes environments for workstations are worth considering.

However there’s no denying that there’s additional risk introduced by this change.

But, it’s not the end of the Docker world.

You can still depend on Docker as a format for your containers; the same for DockerHub and other container repositories. Docker images are standard OCI (Open Container Initiative) images and they will continue to be supported and are a safe choice.

We may wonder at this time if the Kubernetes team will remove support for Docker containers, because that would be a huge disruption to the entire container based DevOps . . . to the entire modern IT! It’s highly unlikely that it will happen anytime soon.

Public cloud

Public clouds, hosted by Kubernetes environments, are expected to switch seamlessly and do not require any changes on the consumer side (Docker container developers). Of course, again, it means a slightly higher risk that something will break if it was tested on a Docker Engine.

→ Avenga insights Is the hybrid cloud here to stay forever?

Future of Kubernetes and Docker

Nothing stays the same in the world of technology. This thought is especially relevant to the newcomers in IT as it’s something they will observe over and over again. For the more experienced of us, it’s something that we are used to.

→ Explore Meeting the Future. Trends & Technology 2021.

The reaction of the IT world to the news of the Docker engine depreciation shows how much the modern software world depends on both technologies. The prevailing theme is downplaying the change by repeating ‘don’t panic’ in multiple versions. Something happened to the stable ‘relationship’ of Kubernetes and Docker and we are more anxious than before.

Fortunately, everything container related is based on Linux mechanisms (cgroups, etc.)  so as long as there’s support for it in the Linux kernels, runtimes and configurations, then containers as a mechanism are safe. And, it’s hard to imagine Linux being replaced by another OS over the next few years.

The particular implementation of container runtimes on Linux, such as Docker runtime, is not going away automatically, but it’s the Kubernetes that is the real thing for the cloud native deployments of your business applications, not Docker runtime. So we will adapt to these changes and there’s one year to make it happen.

The Avenga DevOps team is following the news closely and is applying the best practices for cloud native applications. We would be thrilled to help you with this inevitable transition, which few of us planned for. But remember, it’s 2020 so there’s no such thing as a ‘surprise’ anymore.