Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Kubernetes Proceeding with Deprecation of Dockershim in Upcoming 1.24 Release

Kubernetes Proceeding with Deprecation of Dockershim in Upcoming 1.24 Release

This item in japanese

Lire ce contenu en français

Kubernetes is proceeding with deprecation and removal of dockershim in the upcoming 1.24 release. Workflows and systems that make use of the Docker Engine as the container runtime for their Kubernetes cluster will need to migrate prior to moving to the 1.24 release. The 1.23 release will retain dockershim and will be supported for another year.

Docker was the first container runtime used by Kubernetes. Originally Docker support was hardcoded into Kubernetes but as the project evolved, Kubernetes began adding support for more runtimes. The Kubernetes community decided to move to more structured, standardized interfaces instead of directly integrating third-party solutions into the core code. This led to the creation of the Container Runtime Interface (CRI), the Container Network Interface (CNI), and the Container Storage Interface (CSI).

As Adam Parco, CTO at Mirantis, states:

For most people, the deprecation of dockershim is a non-issue, because even though they’re not aware of it, they’re not actually using Docker per se; they’re using containerd, which is CRI compliant. For those people nothing will change.

As Docker is not CRI compliant, dockershim acts as a translation layer between kubelet and Docker. Docker then interfaces with containerd to execute the containers. Containerd was extracted from Docker as a self-container container runtime and became the first CRI-compliant runtime. The change to deprecate dockershim will see kubelet communicate directly with the container runtime such as containerd.

Kubernetes workflow via containerd compared with dockershim

Kubernetes workflow via containerd compared with dockershim (credit: Kubernetes)


As noted in a recent post on the Kubernetes blog, the move away from dockershim is to better align the Kubernetes codebase to the new interface model. Some new features, such as cgroups v2 and user namespace, are largely incompatible with dockershim. As the authors of this recent blog post note: "Dependencies on Docker and dockershim have crept into various tools and projects in the CNCF ecosystem, resulting in fragile code."

If Docker is currently being used to build the application containers, these containers can still be run on any container runtime. When an alternate container runtime is used, Docker commands may either not work or produce different results. For example, docker ps or docker inspect will no longer be usable to obtain container information, and docker exec will no longer function.

Other things to look out for to determine a dependency on dockershim include ensuring no privileged Pods execute Docker commands such as docker ps, restart the Docker service, or modify Docker-specific files. The Docker configuration file should be reviewed for private registries or image mirror settings. If they exist, they often need to be reconfigured for another runtime.

A review should be performed of scripts that run outside of the Kubernetes infrastructure to identify Docker commands. This might include SSH to nodes for troubleshooting, node startup scripts, or monitoring and security agents that are installed directly onto nodes.

Mirantis and Docker have agreed to partner to maintain the dockershim code as a standalone, open-source, comformant CRI interface for Kubernetes. This means that the Mirantis Container Runtime (MCR) will be CRI compliant. Their cri-dockerd could be leveraged as an external replacement for dockershim in cases where switching off dockershim is not desirable or feasible.

The Kubernetes 1.24 release team and the CNCF have committed to delivering documentation in time for the release, currently scheduled for April. This includes blog posts, updating code samples, tutorials, and a migration guide.

The team believes there are no longer any major blocks to proceeding with the migration. They do note that discussions around postponing occurred in the recent SIG Node discussion on November 11 and the Kubernetes Steering committee meeting on December 6. However, at this time they have agreed to continue with the removal of dockershim in the upcoming 1.24 release.

About the Author

Rate this Article