Painless Docker - 2nd Edition

Does CRI Mean the Death of Docker?

You generally don't run containers directly in production at scale. Once an application moves beyond a single host, an orchestrator such as Kubernetes or Docker Swarm is typically required to manage container lifecycle, scheduling, networking, and resource allocation.

Kubernetes is the most widely adopted container orchestration system. As the container ecosystem evolved and multiple runtimes emerged, Kubernetes needed a way to remain extensible without being tightly coupled to a single runtime implementation. In its early days, Kubernetes relied on Docker as the default container runtime, and this remained the case until Kubernetes version 1.20. As of version 1.20, Kubernetes deprecated Docker as its runtime.

"Don't panic," was the title of a blog post published by the Kubernetes project to explain the deprecation of Docker as a container runtime. The post clarified that Docker itself was not being removed from the container ecosystem. As the authors explained:

Docker as an underlying runtime is being deprecated in favor of runtimes that use the Container Runtime Interface (CRI) created for Kubernetes. Docker-produced images will continue to work in your cluster with all runtimes, as they always have.
If you're an end-user of Kubernetes, not a whole lot will be changing for you. This doesn't mean the death of Docker, and it doesn't mean you can't, or shouldn't, use Docker as a development tool anymore. 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.

So is Docker dead? Absolutely not. Docker remains a widely used and effective tool for building container images, and images produced with docker build continue to run unchanged in Kubernetes clusters.

The same blog post explained the technical motivation behind this decision. What many people refer to as "Docker" is actually a stack of components. One of those components is containerd, which is itself a container runtime. Docker adds a human-friendly layer on top of containerd, providing workflows and user experience features that are useful for developers but unnecessary for Kubernetes, which interacts with runtimes programmatically.

Because Docker doesn't implement the Container Runtime Interface directly, Kubernetes historically relied on an additional compatibility layer called dockershim