How Dockershim’s Forthcoming Deprecation Affects Your Kubernetes

Container orchestration platform Kubernetes announced in December 2020 that its third and final release, Kubernetes v1.20, would deprecate dockershim and subsequently Docker as a container runtime. This deprecation has brought multiple changes that admins must be aware of and accordingly respond to. 

To best understand these changes and how dockershim’s deprecation affects admins and their work, let’s quickly dive into what dockershim is, its relevance to container security, and the reasons behind Kubernetes’ decision to deprecate it.

What is Dockershim?

The dockershim module is part of Kubernetes’ solution to use multiple container runtimes on a single kubelet without forcing it to recompile. This solution is, more specifically, known as the Container Runtime Interface (CRI) plugin and was introduced after Kubernetes developed dockershim.

The CRI plugin was a success in that it gave Kubernetes cluster operators the freedom to interact with multiple container runtimes, but it also required that Kubernetes eventually create a way for the kubelet to recognize the Docker container runtime as a CRI-compatible one. Dockershim is the adaptor component that emerged as the response to this inevitable need.

Why Is Kubernetes deprecating Dockershim?

In its early years, the Kubernetes platform offered compatibility with only the Docker container runtime. Dockershim’s emergence as a middleman solution foreshadowed the problems it would cause with Docker’s container runtimes overall. The dockershim module transformed from a temporary solution to a permanent one and eventually became too much to maintain.

The dockershim module, in particular, placed too great of a strain on the operators responsible for maintaining the Kubernetes platform. According to DevOps expert Barbara Ericson, Kubernetes provides a self-contained environment “where every application has its source code, runtime, supporting files, configuration files and so on, thereby allowing the applications to execute in remote environments.”

The fact that Kubernetes’ support for Docker predates its support for the CRI plugin makes it difficult to maintain this kind of self-contained environment with dockershim and has resulted in a tricky situation for admins.

How worried should I be?

Using containers to build applications from the ground up or porting existing apps to a containerized environment can be stressful and time-consuming. Some admins are understandably worried about dockershim’s deprecation and whether it will leave them with vestigial dependencies on Docker as a container runtime or even pose security risks during communication between the Kubernetes-supported software responsible for containers for the next few months.

Kubernetes has fortunately stated that while Dockershim is being removed from Kubelet as early as its v1.23 release, admins need not panic just yet. Admins only need to change their container runtime from Docker to a separate, Kubernetes-supported container runtime to accommodate Docker’s non-compliance with CRI and subsequent deprecation of dockershim.

Admins should also be aware that if they use managed Kubernetes service or distribution, they can likely contact their provider to confirm that there is zero impact on their environment once they turn off their Docker runtime for good. Admins using open-source Kubernetes on their clusters should apply changes themselves.

Are admins going to be affected?

The container orchestration platform has confirmed that it won’t deprecate dockershim before the release of Kubernetes v1.22 and has clarified that version 1.23 is likely the earliest release to not feature dockershim support. What this means going forward is that future versions of Kubernetes will, indeed, feature no support for the dockershim module; admins will still, however, be able to use Docker in general.

Kubernetes has noted that admins should try to execute Docker commands outside the scope of their third-party tools as well as scripts and apps running on notes outside of the Kubernetes cluster. According to Kubernetes, this will help admins locate dependencies on Docker as a container runtime once the deprecation has been implemented. Admins should continue to monitor for indirect dockershim dependencies that can affect apps and consider their runtime resource limitations and other elements that may still require Docker access.

How do I know if the depreciation will affect me?

Admins need to investigate whether their Kubernetes cluster is still using Docker as a container runtime as well as the workloads that may be affected. Dockershim plays a role when it’s being used as a container runtime. This can potentially cause complications with workloads and prevent Docker commands from being executed or yielding unexpected outputs.

Kubernetes has recommended that admins take several steps to find out whether an app they are using has a dependency on Docker. Popular monitoring and security agents that are installed on nodes outside of the kubelet can be common culprits hiding Docker dependencies.

Third-party tools that conduct privileged monitoring operations do not have a direct dependency on runtime hosting containers. There are still many telemetry and security agents, however, that do have a dependency on Docker to collect container metadata, logs, and metrics. Network device logs can offer critical information about how devices are operating and how network resources are being used.

Summary

There’s no denying that the coming versions of Kubernetes will offer no support for the dockershim module. In order for the container orchestration platform to properly use the kubelet to support CRI for Docker, it’s necessary to deprecate the once temporary dockershim solution and give it the recognition it deserves. That being said, admins should consider investigating their environments for dependencies on Docker as a container runtime.

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 continue to monitor their runtime resources and logging configurations. Depending on their infrastructure, they might need to make certain changes and use supplementary tooling to make a new container runtime work for them.

About the Author: Sam Bocetta is a freelance journalist specializing in U.S. diplomacy and national security with an emphasis on technology trends in cyberwarfare, cyberdefense and cryptography.

Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.