Kubernetes No Longer Supports Docker as a Runtime: Implications and Migration Guidance

After version 1.20, Kubernetes will no longer support Docker as a container runtime.

Do not panic – the impact is limited. The change only discourages using Docker as the underlying runtime; you can still run Docker images in the cluster via the Kubernetes Container Runtime Interface (CRI).

For end‑users, Docker will not disappear; it remains a valuable development tool for building OCI‑compatible images, which continue to run unchanged on Kubernetes.

If you use managed services such as GKE or EKS, ensure you switch worker nodes to a supported runtime (e.g., containerd or CRI‑O) before Docker support is fully removed, and coordinate upgrade testing with your provider.

Clusters that perform rolling updates should handle the deprecation warning in 1.20 and plan to replace Docker with a compatible runtime by the expected removal in version 1.23, making sure the new runtime can work with existing Docker daemon configurations (e.g., logging).

The panic often stems from misunderstanding the role of the container runtime inside Kubernetes. Docker is a popular runtime, but it was not originally designed for direct embedding in Kubernetes, leading to the need for the Dockershim shim, which has already been removed as of Kubelet 1.23.

When Docker sockets (e.g., /var/run/docker.sock ) are used in workflows (Docker‑in‑Docker), switching runtimes may break those pipelines; alternatives such as Kaniko, Img, or Buildah can be employed.

Developers should note that the Docker installation on their workstation is unrelated to the Docker runtime inside the cluster. Docker‑built images are OCI images and are compatible with any CRI‑compliant runtime, so existing Dockerfiles remain valid.

In summary, while the runtime change may cause some inconvenience, it is not a major disruption and ultimately benefits the cloud‑native ecosystem.