In one of the most momentous changes to hit the container ecosystem in years, Kubernetes announced in December 2020 that it will be killing support for dockershim. The Kubernetes camp is very eager to assure everyone that this is not a big deal: All that deprecating Docker basically means, they say, is that some folks will have to switch their Kubernetes clusters to use a new runtime. Otherwise, developers can continue to use Docker’s tooling just as they always have.
That’s more or less true, and it may indeed be the case that the dockershim deprecation won’t affect too many developers. But what about the Kubernetes and Docker ecosystems more broadly? Here’s what the change is likely to mean for the world of containers as a whole.
What is Dockershim and Why is Kubernetes Killing It?
Put simply, dockershim is a tool that translates commands from Docker Engine (which is Docker’s set of tools for building and managing containers) into a format that Kubernetes can understand. This is important because Kubernetes itself is not directly compatible with Docker Engine. (Kubernetes is compatible with Docker Engine’s runtime, containerd, but not with other parts of the Docker Engine tooling.)
If you’ve built a development pipeline that depends on Docker’s native commands, but you want to deploy your containers into a Kubernetes cluster, dockershim provides the compatibility layer that lets you do that.
Kubernetes developers say that maintaining dockershim has become burdensome, and so they’re going to stop supporting it. That change will likely take effect with the release of Kubernetes v1.22, which will probably debut sometime in the second half of 2021.
Does Dockershim Deprecation Matter?
Again, the Kubernetes project is going to considerable lengths to assure the world that “you do not need to panic” and that this change will cause no “catastrophic” issues.
In making these statements, the Kubernetes camp is trying partly to prevent misinterpretations of what the dockershim deprecation means for technical purposes. Given the ambiguity surrounding the actual differences between Kubernetes and Docker, they are worried that folks will think that Kubernetes is going to cease supporting Docker in general; meaning that all of the tools developers currently use to build Docker images would no longer be compatible with Kubernetes.
In fact, as the Kubernetes folks eagerly point out, that’s not the case. Images built with Docker’s tooling will continue to work just fine with Kubernetes. What will change is that Docker Engine (in conjunction with dockershim) will no longer work as a Kubernetes runtime.
How much will that matter in practice? That depends on who’s asking. There are basically three main groups of users to think about.
Companies that depend heavily on Docker Engine
The first group of users is people who bake Docker Engine into their broader development workflows. These people will need not only to find a new runtime, but to update their entire development toolchains. That’s a significant effort.
This is the group that will feel the most pain from the dockershim deprecation. They may even feel more pain than the Kubernetes developers want to admit. It’s not going to be exactly easy for them to make the change.
Exactly how large this group is is hard to say. However, I suspect that it includes a fair number of organizations that have been invested in the container ecosystem for years. If you are heavily reliant on Docker’s native tooling, it’s probably because you started using containers in production before it became clear that the ecosystem was moving away from Docker and toward Kubernetes. People who jumped on the container bandwagon in more recent years (say, after 2017 or so) are more likely to have invested in Kubernetes and its associated standards from the start.
Thus, there may be some folks who feel like they’ve been betrayed. Their early adoption of containers helped open the doors through which Kubernetes eventually walked as it grew into a massively important platform. And now, Kubernetes is abandoning the Docker-centric folks who kept those doors open.
Companies that use Docker Engine, but only as a runtime
A second group is organizations that use Docker Engine as a runtime for Kubernetes, but haven’t baked Docker Engine extensively into their workflows.
For these people — most of whom are probably companies that saw the writing on the wall and already started migrating away from Docker Engine, but didn’t switch entirely yet — the dockershim deprecation is not a huge deal. They will need to find a different runtime, but there are plenty of alternatives available. If they can switch to a new runtime without overhauling their existing development workflows, they’ll be fine.
Companies that use other runtimes
The third group, of course, is people who don’t use Docker Engine or dockershim at all. They have basically no reason to care about this news.
Dockershim Lives On
Complicating all of the above is the fact that a few days after Kubernetes announced plans to kill its own support for dockershim, Mirantis chimed in to say that it will continue developing dockershim support for Kubernetes, in partnership with Docker itself. In other words, Mirantis and Docker will work together to ensure that dockershim remains compatible with future releases of Kubernetes, even after the Kubernetes project itself ceases to do so.
So, if your company depends on Docker Engine and doesn’t want to switch, an alternative approach is simply to keep doing what you’re doing by relying on the Mirantis/Docker support for dockershim. It remains to be seen exactly how hard it’s going to be to implement this version of dockershim, although it’s a safe bet that it will be easy to do so if you use Mirantis’s Kubernetes platform. The code is going to remain open source, so theoretically it should be usable with any Kubernetes cluster.
Maybe this gives Docker Engine-dependent organizations one less reason to panic — provided they are willing to jump through whichever hoops they need to get dockershim running in their Kubernetes clusters without official support from Kubernetes itself.
Docker’s Receding Relevance
A broader takeaway from the dockershim deprecation news is that it’s yet another sign of Docker’s diminishing overall relevance. It will push more organizations away from their dependency on Docker’s tooling.
And even for those that choose to continue using dockershim, this news creates a certain amount of fear, uncertainty and doubt surrounding Docker. It’s going to get even harder for developers to justify Docker-centric strategies at a time when Kubernetes itself clearly wants little to do with Docker.
In a way, this feels like Docker’s destiny. When Docker itself debuted in 2013 to much fanfare, it stole the thunder from earlier container projects, like LXC, which had made Docker possible but which received less credit than they arguably deserved. Indeed, many folks seem to think that Docker somehow invented containers, when in reality, containers or container-like technology had existed for decades before Docker came along.
Now, Docker is meeting a similar fate at the hands of Kubernetes. A few years hence, some of us may not even remember that if Docker hadn’t come along, Kubernetes would not have, either (or at least, not as we know it). Everything’s going to be about Kubernetes, while Docker will look more like LXC or FreeBSD jails do today — a sort of obscure technology that was once interesting and important, but which doesn’t really matter anymore.
To be sure, there are probably always going to be some folks who use Docker — just as there will always be folks who enjoy compiling their own Linux kernels. But the dockershim deprecation is yet another sign that Docker is going to be more and more a solution for developers who are experimenting and need a quick way to build containers, not a production platform.