Understanding the Deprecation of Docker in Kubernetes and Its Impact

Several weeks ago the Kubernetes development team announced the deprecation of Docker as a container runtime, sparking widespread discussion about potential cluster disruptions and the steps required to keep applications running.

What is a container? Containers are logical partitions that isolate applications with their own network and filesystem, offering portability and the ability to run multiple instances without conflict. Historically, concepts like chroot, BSD Jails, OpenVZ, and LXC laid the groundwork before Docker popularized the model.

What is Docker? Docker became the most popular container runtime, providing a complete stack for managing container lifecycles, networking, logging, resource limits, image building (Dockerfile), and registry interactions. Modern Docker consists of two services: containerd for container management and dockerd for higher‑level functions.

What is Kubernetes? Kubernetes extends containers by distributing them across a cluster of machines, treating the group as a single logical unit. It adds features such as Pods, automatic scaling, self‑healing, load balancing, and rollout/rollback mechanisms. The control plane coordinates nodes, while worker nodes run containers via components like kubelet, kube‑proxy, and a container runtime (Docker by default in v1.20).

Docker vs. Kubernetes Initially, Kubernetes relied exclusively on Docker. Over time, the Container Runtime Interface (CRI) was introduced to allow alternative runtimes, leading to the development of an adapter called Dockershim to translate CRI calls to Docker commands.

Deprecation of Dockershim Starting with Kubernetes v1.20, Dockershim is deprecated, signaling the move away from Docker as the default runtime. By v1.23 (end of 2021) Docker support will be fully removed, encouraging clusters to adopt lighter‑weight runtimes such as containerd or CRI‑O.

The impact is modest: clusters using Docker will receive a deprecation warning after upgrading to v1.20, but existing workloads continue to run. Developers can still build images with Docker as long as they follow the OCI image format, and CI/CD pipelines need not change immediately.

However, operators must eventually switch to a CRI‑compatible runtime. Migration steps include evaluating alternatives, installing the chosen runtime, and updating the kubelet configuration. Specific concerns include Docker‑specific logging, monitoring, CLI scripts, privileged pod usage, and cloud‑provider support.

In summary, while the deprecation does not require urgent action for most users, it signals a clear direction toward a more modular, lightweight container ecosystem, and teams should begin planning and testing their workloads against the new runtimes.