Understanding the Deprecation of Docker in Kubernetes and Its Impact
The article explains the history of containers, the role of Docker and Kubernetes, why Kubernetes is deprecating Docker's dockershim, the timeline for the change, its impact on users, and the steps required to migrate to OCI‑compatible runtimes such as containerd or CRI‑O.
Several weeks ago the Kubernetes team announced the deprecation of Docker as a container runtime, sparking widespread discussion about potential cluster disruptions and the steps needed to adapt applications.
What is a container? Containers are logical partitions that run applications isolated from the host system, each with its own network and virtual filesystem. Early forms include chroot, BSD Jails, OpenVZ, and Linux Containers (LXC).
What is Docker? Docker is the most popular container runtime, providing a complete stack that manages container lifecycles, networking, storage, resource limits, image building (Dockerfile), and registry interactions. Initially it used LXC, later switching to its own implementation with components containerd and dockerd .
What is Kubernetes? Kubernetes orchestrates containers across a cluster of machines, grouping containers into Pods, handling automatic scaling, self‑healing, load balancing, and rollout/rollback. Its control plane stores state in etcd and schedules Pods onto worker nodes that run a container runtime.
Container image formats are standardized by the Open Container Initiative (OCI), which defines an image specification and a runtime specification (implemented by runc ). OCI ensures interoperability across different container solutions.
Docker vs. Kubernetes Historically Docker was the only runtime supported by Kubernetes, but Docker was never designed to run inside Kubernetes. The Container Runtime Interface (CRI) was introduced to allow alternative runtimes, leading to the creation of the dockershim adapter that translated CRI calls to Docker commands.
Deprecating dockershim Kubernetes v1.20 marks Docker as deprecated, signaling a shift toward lighter‑weight runtimes such as containerd or CRI‑O, which offer better performance and lower resource consumption.
Why change? Docker adds unnecessary overhead; newer runtimes reduce memory and CPU usage and start Pods faster. For many users the impact is minimal—Docker continues to run OCI‑compatible images, and existing CI/CD pipelines remain functional.
Impact on users After upgrading to v1.20 you will see a deprecation warning if Docker is still used. By v1.23 all Docker dependencies will be removed, requiring clusters to adopt a CRI‑compatible runtime.
What needs to change? Cluster administrators should plan migration to runtimes like containerd, CRI‑O, or, if they wish to keep Docker, use the cri‑dockerd project. Cloud providers may still offer Docker as an option for a limited time. Timeline The full removal of Docker support is scheduled for the end of 2021 (v1.23). Users should test their workloads with the new runtimes and adjust any Docker‑specific scripts, logging, or monitoring tools.
Conclusion While Kubernetes is evolving, the transition away from Docker does not require drastic changes for most users; it mainly involves selecting a CRI‑compatible runtime and ensuring compatibility with existing workloads.
Architects' Tech Alliance
Sharing project experiences, insights into cutting-edge architectures, focusing on cloud computing, microservices, big data, hyper-convergence, storage, data protection, artificial intelligence, industry practices and solutions.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.