Let’s take a look at the actual relationship between kubernetes and docker
In the article “what is a container”, we mentioned that a container is not just a docker, but actually a container
A set of specifications defined by OCI organization, including runtime spec and image format spec
Kubernetes introduced CRI in version 1.5 (2016), so the relationship between docker and kubernetes becomes as follows
Dockershim is maintained by the community and allows kubernetes to use docker gasket of docker normally
CRI-O
When the container runtime standard was proposed, some people in red hat began to think that they could build a simpler runtime, which was only used by kubernetes. In this way, there is the Skunkworks project, finally named cri-o, which implements a minimum CRI interface
Finally, this structure evolved into this
In 2021 when this paper was written, that is, six years after the concept of CRI interface was put forward, kubernetes has become the de facto standard of container layout environment, and naturally began to be higher than the native docker in terms of discourse power. On the other hand, docker seems to have never seriously considered supporting CRI interface, and kubernetes community still needs to maintain dockership in the warehouse
It’s not hard to understand why kubernetes plans to start gradually removing support for docker
Not to mention that for kubernetes, docker should not support a series of interfaces of other modules
The relationship between docker and kubernetes CRI is more like the following
Docker provides more functions far beyond the needs of CRI and provides a full set of tools from operation to construction. It is precisely because of this responsibility and versatility that kubernetes has to pay more costs when docking with docker.
There are many new CRI features that have been repeatedly delayed due to their inability to implement on dockership, resulting in kubernetes finally choosing to try to remove dockership from the project.
