Why Kubernetes Dropped Docker: Understanding CRI, containerd, and the Future

CRI (Container Runtime Interface)

To grasp why Kubernetes (K8s) moved away from Docker, we must revisit its early history. In 2014 Docker was at its peak while K8s was just born. K8s initially supported Docker, but by 2016 it joined CNCF and introduced the CRI, a new set of protobuf‑based gRPC interfaces that let the kubelet talk to any container runtime, deliberately breaking compatibility with Docker's native APIs.

CRI enabled a “shim” layer—commonly called dockershim —that translated Docker calls into CRI‑compatible ones, allowing K8s to keep Docker as a runtime while preparing for alternatives.

containerd

Facing the shift, Docker split its monolithic engine, donating the daemon component to the CNCF and creating containerd as a separate project. As a CNCF‑hosted runtime, containerd must implement the CRI, yet Docker continued to invoke containerd internally, preserving its original Docker‑centric API.

This resulted in two possible call chains inside K8s:

CRI → dockershim → Docker Engine → containerd to manage containers.

CRI → containerd directly, bypassing dockershim and Docker.

The second path is simpler and offers better performance. When Kubernetes 1.10 was released in 2018, containerd 1.1 was integrated, showing roughly 20% lower pod startup latency, 68% lower CPU usage, and 12% lower memory usage compared with Docker 18.03.

Deprecating Docker

In Kubernetes 1.20 (2020) the kubelet announced the formal deprecation of Docker support, planning to remove it in future releases. Media headlines simplified this to “K8s deprecates Docker,” causing panic among users who feared their Docker investments would be lost.

In reality, only the dockershim component is being removed; the underlying container runtime is now containerd. Existing Docker images continue to run unchanged because they conform to the OCI image format. The removal of dockershim was delayed until version 1.24, when the code was finally stripped from the kubelet.

Docker’s Future

Despite losing its default status in K8s, Docker remains viable. OCI‑standard images are still accepted, so developers can pull from Docker Hub or build with Dockerfiles without altering CI/CD pipelines.

Docker also offers a broader product suite beyond containerd, including image building, distribution, testing, and the Docker Desktop environment that bundles a lightweight Kubernetes.

To bridge the gap, the community created cri‑dockerd, which adapts Docker Engine to the CRI, allowing the kubelet to interact with Docker as if the deprecation never happened.

Overall, Docker’s extensive ecosystem, mature tooling, and large user base ensure it remains a practical entry point for learning containers and cloud‑native development.