Skip to main content
Whenever Docker is mentioned, a common question arises: why are we still talking about Docker if it’s deprecated? There is confusion about what “Docker deprecation” actually means. This article clarifies the distinction and explains why Docker remains relevant for development, CI/CD, and learning container concepts. Historically, Docker was the original container runtime used with Kubernetes. To make Kubernetes pluggable with other runtimes, the Container Runtime Interface (CRI) was introduced. Docker, as a product, is composed of several parts: the Docker CLI, Docker API, image build tools (for example BuildKit), image distribution and storage, volume management, authentication and security features, and low-level runtime components like runc. Docker Engine historically relied on two core runtime pieces: containerd (which manages images and the container lifecycle) and runc (which creates and runs containers). Kubernetes only needs the container runtime portion to run workloads. With the CRI in place, Kubernetes communicates directly with CRI-compatible runtimes such as containerd or CRI-O and no longer requires Docker’s higher-level tooling. Kubernetes used a small adapter called dockershim so the kubelet could talk to Docker Engine. Dockershim support was deprecated (announced in Kubernetes v1.20) and later removed (in v1.24). For details see the Kubernetes announcement: https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/ Now, that doesn’t mean Docker is entirely gone.
A diagram showing container runtimes — rkt, containerd, and a deprecated Docker box — connected to Kubernetes via the Container Runtime Interface (CRI). The Docker box highlights components like CLI, API, build, volumes, auth, and security.
Key points to remember
Docker being deprecated as a Kubernetes runtime refers to the removal of the dockershim adapter — not to Docker images or Docker as a developer tool. Docker images remain OCI-compatible and will work with other CRI runtimes.
Practical substitution examples For learning and quick local development you can keep using Docker CLI commands. On Kubernetes nodes that run containerd directly, nerdctl often serves as a drop-in replacement for many Docker commands. Examples:
Equivalent commands when using containerd with nerdctl:
Summary
  • Docker (the product) is still widely used for development, CI/CD, and building images. You can continue using Docker Desktop, Docker CLI, and Docker Build for these workflows.
  • Kubernetes requires a CRI-compatible runtime on cluster nodes; Docker Engine is not required on nodes. Popular CRI runtimes include containerd and CRI-O.
  • Images built by Docker follow the OCI spec and run on other CRI runtimes without modification.
  • If Docker is not available on your machine, use nerdctl for local development against containerd.
Links and references

Watch Video