I’ve recently begun learning Kubernetes and came across the statement, “Update: Kubernetes support for Docker via dockershim is now removed.” At first, I felt a little nervous, thinking, “Do I have to learn yet another container runtime? Is there any point in learning Docker and Swarm anymore?” So, I decided to explore what was happening. Let me explain.
The History of Kubernetes
In the early days, Docker was the dominant container tool, and Kubernetes entered the scene as a Google-developed project. It served as an orchestration tool but was tightly coupled with Docker. Kubernetes only required the Docker Runtime, also known as ContainerD,to work but things weren’t that straightforward. Let me elaborate on why.
Components of Docker
To understand the situation better, let’s explore the various components of Docker. Docker has three main components:
Docker CLI
Docker Server (Daemon)
Docker API
The Docker CLI is the interface through which we interact with Docker. The Docker API is the means by which the Docker CLI communicates with the Docker Server (Daemon), and the Docker Daemon is where all actions related to images, volumes, and networking take place. Among these components, there’s something called the Container Runtime, which, in this case, is ContainerD. Kubernetes only needed to communicate with this runtime, but ContainerD wasn’t initially designed for this purpose. As a result, Kubernetes had to rely on the entire Docker ecosystem to communicate with ContainerD.
© Copyright @blogpureshttps://blog.purestorage.com/
The Challenge
Initially, this wasn’t a significant issue. However, as Kubernetes gained popularity, other container runtimes like CRI-O and RKT wanted to integrate with Kubernetes. To address this, Kubernetes introduced the Container Runtime Interface (CRI), which allowed Kubernetes to support any container runtime following OCI standards. Here’s where it gets interesting: ContainerD wasn’t a standalone project; it was part of Docker. However, Docker couldn’t integrate with CRI because it was developed before CRI existed and didn’t support it. Docker remained popular, so Kubernetes had to find a way to support it. This led to the creation of “Dockershim.” It was a temporary solution, and Kubernetes had to maintain both CRI and Dockershim.
The Transition
In the meantime, Docker separated its runtime, ContainerD, and made it available as a standalone project. ContainerD could seamlessly integrate with CRI and Kubernetes. Over time, support for Dockershim was deprecated, which means you can no longer integrate Docker with Kubernetes. Instead, you integrate ContainerD for orchestrating containers.
Conclusion
It’s a quick history lesson about Kubernetes. I hope you found it informative. If you enjoyed the lesson, feel free to show your appreciation by giving it a clap — it’s always free! :-)
You can buy me a coffee ☕ , you can also follow me on Linkedin and Youtube.