X
Business

Kubernetes dockershim to live on

Kubernetes is depreciating dockershim, but Mirantis will continue to maintain the Kubernetes Docker shim code outside Kubernetes as a CRI interface for Docker Engine.
Written by Steven Vaughan-Nichols, Senior Contributing Editor

When Kubernetes 1.23 is released towards the end of 2021, it will no longer include dockershim. This program enables you to use the Docker containerd container runtime within Kubernetes. Unfortunately, Docker was never designed to be embedded inside Kubernetes, and it's incompatible with Kubernetes' Container Runtime Interface (CRI). The fix was for dockershim to bridge the gap between Docker's containerd and CRI. Maintaining dockershim, however, was a pain so Kubernetes started depreciating it. Mirantis, which now owns the Docker program, will continue to support dockershim in Docker Engine and Mirantis Container Runtime with Kubernetes.

First, though I should note you don't actually need "Docker," which is an entire stack of software, to run Docker containers in Kubernetes. As the Kubernetes developers point out, "Docker is still a useful tool for building containers, and the images that result from running docker build can still run in your Kubernetes cluster."  But, you may need to make changes to avoid your clusters breaking when dockershim is no longer around to connect you with the Docker runtime. Instead, you'll have to move to a supported container runtime such as the runc-based containerd and CRI-O

Or, Mirantis Kubernetes Engine (formerly Docker Enterprise/UCP) users can turn to the Docker-compatible Mirantis Container Runtime. This will ensure continuous compatibility and a seamless transition once Kubernetes 1.23 arrives. "Put simply," Ryan Barry for Mirantis says, "when Mirantis updates the Kubernetes version in Mirantis Kubernetes Engine to 1.23, we'll also update Mirantis Container Runtime so that everything 'just works.'"

How? By continuing to maintain dockershim as a separate program. To ensure it works with Kubernetes it includes a CRI-wrapper, cri-dockerd.

With this, dockershim can run as a separate daemon. This presents the expected API for kubelet's `--container-runtime=remote` and `--container-runtime-endpoint=` parameters, with enough changes to pass the critest and kube-e2e test suites.

That's a little too complex for comfort though. Mirantis and other open-source developers are working on moving workflows out of dockershim directly into cri-dockerd. In this event, the workflow will be simply kubelet -> cri-dockerd -> docker. This will lower both the resource usage for running it and reduce the development maintenance burden.

The bottom line is if you want to stick with what you already know about using Docker with Kubernetes you'll be able to do so with cri-dockerd and dockershim.

Related Stories:

Editorial standards