Please note: Mirantis has realigned its portfolio and renamed several products. These include Docker Enterprise Container Cloud (now Mirantis Container Cloud), Docker Enterprise/UCP (now Mirantis Kubernetes Engine), Docker Engine - Enterprise (now Mirantis Container Runtime), and Docker Trusted Registry (now Mirantis Secure Registry).

Home > The Future of Dockershim is cri-dockerd

The Future of Dockershim is cri-dockerd

Ryan Barry - April 16, 2021 - | | | |

Don’t panic: Docker-shim’s anticipated deprecation won’t cause disruption for folks using Docker Engine or Mirantis Container Runtime with Kubernetes

Kubernetes 1.23 will be upon us before the end of the year, and with it, dockershim will no longer be part of upstream Kubernetes. As detailed in our last post on this topic, this will be irrelevant for many users, who are leveraging containerd rather than Docker explicitly.

For users of Mirantis Kubernetes Engine (formerly Docker Enterprise/UCP), which uses the Docker-compatible Mirantis Container Runtime, Mirantis has taken steps to ensure continuous compatibility and a seamless transition once Kubernetes 1.23 arrives. Put simply, 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.”

In the meantime, we wanted to share more of the backstory and answer some questions users are asking:

What happened to the code for Dockershim?

Removal of Dockershim from the upstream Kubernetes codebase was a coordinated effort between Mirantis and the community, and Dockershim has been cleanly moved into a new repository. As part of this project, initial steps were taken to wrap Dockershim in something that can speak CRI (the Container Runtime Interface, a standard way for container engines to communicate with Kubernetes). An early, but usable version of this project is available here.

So, what is cri-dockerd? Well, for now, it’s a thin wrapper around Dockershim itself which allows Dockershim to be started as a separate daemon. That daemon presents the expected API for kubelet’s `--container-runtime=remote` and `--container-runtime-endpoint=` parameters, with enough changes to pass critest and kube-e2e test suites so we know that its compatibility is on par with other backends.

What happens next?

As noted above, for users of Mirantis Kubernetes Engine, these changes will be integrated as part of an upgrade, once the underlying Kubernetes version is >=1.23, and the upgrade will be seamless. For users of k0s, which is already using containerd instead of Docker, no changes will be needed as part of Dockershim’s migration. We’ve got you covered.

For the project itself, the current workflow is not ideal, kubelet -> cri-dockerd -> dockershim -> docker has more steps than it needs to, and we have the expertise to “cut out the middleman.” An ongoing development effort to move workflows out of Dockershim directly into cri-dockerd is in progress, so it will be simply kubelet -> cri-dockerd -> docker, which will lower the resource usage for running environments, and reduce the maintenance burden for development.

How can I test this today?

This can be used today, and is packaged as part of Mirantis Container Runtime, but there is no need to make changes to your environment right now. Kubernetes 1.23 will not release until late this year, and Dockershim is still present upstream until then.

If you want to test it now, check out cri-dockerd from Github.

There is a Makefile with a few targets. `make deb` or `make rpm` will probably have you covered, and you can install the packages as normal. If you’re using a different distribution, `make static` will give you raw binaries you can invoke.

Then start the service (systemd unit files are included), and add `--container-runtime=remote --container-runtime-endpoint=/var/run/cri-docker.sock` to your kubelet arguments, and you’re ready to go.