1. Background
Recently, Kubernetes version 1.20 was released. Looking at this version of CHANGELOG, we found that Kubernetes will be deprecated after version 1.20. Use Dockershim as the standard implementation of the Container Runtime Interface (CRI). We know that Dockershim is an implementation of the Container Runtime Interface (CRI). The specification of the CRI interface was first introduced in Kubernetes version 1.5: [https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/](https://kubernetes.io/ blog/2016/12/container-runtime-interface-cri-in-kubernetes/). Its purpose is to adapt to multiple container runtimes and allow all systems that manage the container life cycle to implement this unified standard interface (container viewing, creation, deletion, update, etc.), so as to achieve unified management through the upper Kubernetes. In Kubernetes version 1.20, Docker as the underlying CRI implementation is being deprecated and replaced by the CRI implementation created for Kubernetes itself. Of course, this does not mean that Docker is no longer suitable for Kubernetes. Docker is still a useful tool for building containers, and the images produced by running Docker build can still run in Kubernetes clusters.
2. The relationship between docker-shim, docker, containerd, containerd-shim and runc
OCI (Open Container Standard)
It is essentially a document that stipulates two points:
- What the container image should look like, that is, ImageSpec. The general rule is that your thing needs to be a compressed folder, with xxx files in the xxx structure;
- What instructions does the container need to be able to receive and what is the behavior of these instructions, that is, RuntimeSpec. The general content here is that the “container” must be able to execute the commands “create”, “start”, “stop”, and “delete”, and its behavior must be standardized.
Docker encapsulated libcontainer into runC and donated it as a reference implementation of OCI. After Docker is installed successfully, the container engine runs two daemon processes: dockerd and docker-containerd. When a new container is created, Docker will create a new process docker-containerd-shim to control the underlying runc.
CRI (Container Runtime Interface)
Essentially a set of gRPC interfaces:
- Interface for operating containers, including creating, starting and stopping containers, etc.
- Interface for operating images, including pulling and deleting images, etc.
- Operate PodSandbox (container sandbox environment) interface
Due to historical reasons, Docker was initially incompatible with CRI. If Kubelet needs to control Docker through CRI, it needs a converter to adapt it to CRI. This is the docker shim (shim). The shim’s responsibility is to serve as an adapter. The interfaces of various container runtimes are adapted to the CRI interface of Kubernetes. Therefore, the role of docker-shim is to control Docker under the conditions of meeting the CRI specification, while docker-containerd-shim is to make containerd meet the OCI specification (Open Container Initiative, open container standard).
3. Why is dockershim deprecated?
Because the implementation of Kubelet by calling Docker to operate the container was too complicated, Kubernetes later introduced the concept of CRI-O and gradually marginalized Docker. CRI-O is a Kubernetes-specific container runtime implementation that is compatible with CRI and OCI.
As early as July 2020, a proposal to remove dockershim appeared in the Kubernetes community: [https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/1985-remove-dockershim](https ://github.com/kubernetes/enhancements/tree/master/keps/sig-node/1985-remove-dockershim)
Using Docker as the runtime in Kubernetes 1.20, print a warning log when the kubelet starts. (It is not removed yet, just deprecated. The official said it will not be removed before Kubernetes 1.22, which means that the earliest version that does not use dockershim will be 1.23 at the end of 2021)
4. Impact on operation and maintenance and developers
For developers, Docker can still be used when building images because it meets the OCI standard, and the built image naturally meets OCI. Any OCI-compliant image will look the same to Kubernetes, no matter what tool you use to build it. For operation and maintenance personnel who want to operate runtime containers, crictl seems to be a good choice. Of course, this may also bring a certain time cost.