Introduction
As someone who has worked with Kubernetes and Docker, I often wondered, why did Kubernetes move away from Docker as its container runtime? After digging into the details, I finally uncovered the reasons and it all starts with dockershim.
What is Dockershim?
In simple terms, dockershim was a translator. Kubernetes needed to talk to Docker to manage containers, but Kubernetes and Docker didn’t speak the same “language”. Here is why:
- Kubernetes uses CRI: The Container Runtime Interface(CRI) is a standard API Kubernetes uses to communicate with container runtimes.
- Docker uses its own API: Docker was created before CRI existed and didn’t follow the CRI standard.
To bridge this gap, Kubernetes introduced dockershim. It acted as a middleman, converting Kubernetes CRI commands into Docker API commands.
How Dockershim Worked(Simplified Example)
Imagine Kubernetes wants to start a container. Here is how it worked with dockershim:
- Kubernetes sends a CRI command:
StartContainer- Dockershim translates this into a Docker command:
StartContainer -> docker run- Docker executes the docker run command and starts the container.
So, Kubernetes and Docker are like two people speaking different languages. Dockershim acts as the translator, ensuring they understand each other.
Why Did Kubernetes Move Away from Docker?
While dockershim worked, it wasn’t the best long-term solution. Here is why:
- Extra Complexity: Having a translator added unnecessary overhead.
- Performance Impact: The extra layer slowed things down.
- Maintenance Burden: The Kubernetes team had to maintain dockershim to keep it compatible with Docker updates.
- Standardization: Kubernetes aimed to use CRI-compliant runtimes like containerd and CRI-O that directly understood CRI commands, eliminating the need for dockershim.
Dockershim Deprecation
To simplify Kubernetes and improve performance, dockershim was:
- Deprecated in Kubernetes 1.20
- Removed in Kubernetes 1.24
Now, Kubernetes uses lightweight, CRI-compliant runtimes like containerd or CRI-O.
What Does This Mean for Docker?
Docker is still widely used to build and manage container images. You can continue using Docker for development and testing. Kubernetes just doesn’t use Docker directly as a runtime anymore. It uses containerd under the hood instead.
Conclusion
Dockershim was an important part of Kubernetes journey, helping it work with Docker before CRI-compliant runtimes like containerd became popular. Now that Kubernetes has matured, it no longer needs the translator(dockershim).
Understanding why Kubernetes moved away from Docker clarified how Kubernetes has evolved to become more modular and efficient. Docker still remains a valuable tool for building and managing container images, but Kubernetes now relies on lightweight, CRI-compatible runtimes for managing containers in production.
If you have any query related to this topic, please add a comment or ping me on LinkedIn. Stay curious and keep exploring!
