Kubernetes Deprecates Docker: Implications and Migration Guide

A few weeks ago the Kubernetes development team announced that Docker would be deprecated, a news item that spread widely across the tech community and social networks, raising questions about potential cluster disruption and how to run applications.

Containers have existed long before Docker, dating back to the late 1970s when Unix and Linux introduced chroot . The concept was later refined into BSD Jails, OpenVZ, and Linux Containers (LXC).

A container is a logical partition that runs an application isolated from the rest of the system, with its own network and virtual filesystem.

Containers are portable: an image built on one server can run on any other server, and multiple instances can run side‑by‑side without conflict.

To make containers work, a container runtime is required.

What is Docker? Docker is the most popular container runtime. It introduced containers to the mainstream and inspired platforms like Kubernetes. Docker provides a complete stack that manages container lifecycles, proxies requests, monitors activity, mounts shared directories, sets resource limits, builds images via Dockerfiles, and pushes/pulls images from registries. Modern Docker consists of two services: containerd (manages containers) and dockerd (handles the rest).

What is Kubernetes? Kubernetes takes the container idea and adds a distributed layer. It schedules containers across a set of machines, presenting them as a single unit. Key Kubernetes concepts include:

Pod – a logical group of containers sharing network, CPU, storage, and memory.

Auto‑scaling – automatically starts or stops pods based on workload.

Self‑healing – monitors containers and restarts them on failure.

Load balancing – distributes requests across healthy pods.

Rolling updates – supports automated rollouts and rollbacks (e.g., canary, blue‑green).

The control plane is the brain of the cluster, containing a controller manager, scheduler, API server, and a highly available key‑value store ( etcd ). Worker nodes run the containers and host components such as kubelet , network proxy, and a container runtime. In Kubernetes v1.20 the default runtime is Docker.

Container image format – Before running a container, an image (a filesystem containing code, binaries, configs, libraries, and dependencies) must be built or pulled. The Open Container Initiative (OCI) was created in 2015 by Docker and CoreOS to define a vendor‑neutral image format and runtime specification. OCI defines an image specification and a runtime spec (implemented by runc ), enabling interoperability across container solutions.

Docker vs. Kubernetes – Initially Kubernetes required Docker as the only supported runtime. Over time the community introduced the Container Runtime Interface (CRI), allowing alternative runtimes such as containerd, CRI‑O, and others, reducing the platform’s reliance on Docker.

Deprecating Dockershim – Docker was never designed to run inside Kubernetes. To bridge the gap, Kubernetes implemented a shim (Dockershim) that translated CRI calls to Docker commands. Starting with Kubernetes v1.20, Dockershim is deprecated, signaling the move away from Docker.

When the transition completes, the stack will be smaller and have fewer dependencies. The change is motivated by Docker’s heavier footprint; lighter runtimes like containerd or CRI‑O offer better performance, lower CPU/memory usage, and faster pod startup.

Impact of Kubernetes deprecating Docker – In v1.20 you will only see a deprecation warning if Docker is used as the runtime. Docker can still be used for development and building OCI‑compatible images, and existing CI/CD pipelines do not need immediate changes.

However, the community signals that by the end of 2021 (v1.23) all Docker dependencies will be removed. Users of managed services (EKS, GKE, AKS) should verify which runtime their clusters use and plan accordingly.

For self‑managed clusters, migration steps include switching to a CRI‑compatible runtime (e.g., containerd, CRI‑O) or using the cri‑dockerd project to keep Docker support until v1.23.

In conclusion, Kubernetes is evolving, but the transition does not need to be painful; most users can continue working unchanged while testing their workloads on the new runtimes.