This blog was written by an independent guest blogger.
On December 8, 2020, Kubernetes released version 1.20—the third and final release of the popular container orchestration platform in 2020. Kubernetes noted in a blog post that the version contained 42 enhancements. Of those enhancements, 16 entered into alpha, while the remainder moved to beta or graduated to stable at 15 and 11, respectively.
That’s not all that was in Kubernetes version 1.20, however. The new release also came with the announcement of dockershim’s forthcoming deprecation. This blog post will discuss what this change means to admins and provide some recommendations on how admins can respond. Before we do that, however, we need to cover the basics of how dockershim relates to Kubernetes and why the platform decided to deprecate the component in the first place.
An Overview of Dockershim
Dockershim is a module used by the kubelet to support Container Runtime Interface (CRI) for Docker. Released back with Kubernetes version 1.5 in 2016, CRI is a plugin that allows the kubelet to use different container runtimes without recompiling. Those Kubernetes-supported software that are responsible for containers include containerd, CRI-O and Docker for the next few months, at least.
The issue with dockershim is that this container runtime predates Kubernetes’ release of CRI. As noted in its documentation, Kubernetes’ early releases offered compatibility with just one container runtime: Docker. That changed as time went on and as cluster operators expressed the desire to interact with other container runtimes. Kubernetes created CRI to help those cluster operators, but as its support of Docker came before CRI, the container orchestration platform had to come up with an adaptor component that helped the kubelet interact with the Docker container runtime as if it were a CRI compatible runtime. This led to the emergence of dockershim.
Keeping dockershim around ultimately created problems for Kubernetes, however. The issue here is that the kubelet needs to call another component—dockershim—before it can interact with containerd, CRI-O or another supported CRI. It’s a middle man that complicates container runtimes for the platform as a whole. Indeed, in the words of Kubernetes, “that’s not great, because it gives us another thing that has to be maintained and can possibly break.”
Dockershim was only meant to be a temporary solution. Acknowledging that fact, the task of maintaining dockershim had become sufficiently problematic by the end of 2020 that it placed “a heavy burden on the Kubernetes maintainers,” according to the platform. Hence Kubernetes’ decision to deprecate the component.
Going forward, Kubernetes will inform administrators of this deprecating issue starting in version 1.20. As explained by StackRox in a blog post:
If you currently use a managed Kubernetes service or a distribution like OpenShift, your provider will likely help you ensure there is no impact to your environment when switching off the Docker runtime. If you are using open source Kubernetes on your own clusters, you will need to ensure you make changes in the coming months. Starting in 1.20, you will receive a warning that the Docker runtime is going to be deprecated.
That said, the container orchestration platform confirmed on a FAQs page that it won’t deprecate dockershim prior to its release of Kubernetes version 1.22. It explained that version 1.23 would be the earliest release to not support dockershim. This update is slated to roll out in late 2021, which gives admins some time to adjust to the upcoming change.
What this means for admins going forward
It’s true that a future version of Kubernetes will no longer support dockershim. But that doesn’t mean admins won’t be able to use Docker in general. According to Kubernetes’ FAQs page, images produced from docker build will work with all of the platform’s CRI implementations. Their images will also continue to work the same way as they currently do.
That being said, admins should consider investigating their environments for dependencies on Docker as a container runtime. As noted elsewhere in Kubernetes’ documentation, admins should confirm that the task of executing Docker commands remains outside the scope of privileged pods, third-party tools as well as scripts and apps that running on notes outside of Kubernetes. Additionally, they might need to configure tooling to keep an eye out for indirect dockershim dependencies that might affect their apps.
Once they have an understanding of and have addressed their dockershim dependencies, admins can begin the process of moving to a supported container runtime. Kubernetes recommends that admins consider their runtime resource limitations, logging configurations and other elements that might require access to Docker before they transition. Depending on their infrastructure, admins might need to make certain changes and use supplementary tooling to make a new container runtime work for them.
For more information on dockershim’s deprecation and how to respond to it, check out Kubernetes’ FAQs page here.
