Recently，The hottest news in the Kubernetes circle that docker will be deprecated has been confirmed by the release of 1.20.
Docker support in the Kubelet is now deprecated and will be removed in a future release. The Kubelet uses a module called “dockershim” which implements CRI support for Docker and it has seen maintenance issues in the Kubernetes community. We encourage you to evaluate moving to a container runtime that is a full-fledged implementation of CRI (v1alpha1 or v1 compliant) as they become available. — from Kubernetes 1.20 changelog
The news caused a tremendous response, and almost everyone around was discussing it. But at the same time, the Kubernetes community immediately published several articles to ease the panic, stating that most users will not be affected once implemented.
For official reasons, Docker’s API is relatively old and not compatible with CRI(Container Runtime Interface), so that Kubernetes implemented an adaptation layer from docker to CRI, dockershim.
According to KEP, CRI is already a standard interface for container runtime, and docker as a container runtime should not enjoy privileges. Meanwhile, the removal of dockershim achieves the decoupling of Kubernetes and Docker, reduces the burden on the Kubernetes community, and also enables Kubernetes to have better evolution and development in runtime support.
In summary,
- Docker should be stripped because integrating it causes many troubles for the subsequent maintenance of Kubernetes.
- Docker integration is just an implementation in CRI (Container Runtime Interface), while general users cannot perceive it at all.
- There is no need to worry about stability since containerd and CRI-O are both mature CRI implementations.
Docker’s death is doomed
Look backing, and we will find that to combine Kubernetes and Docker is far-fetched, and the separation has long been doomed. Perhaps Kubernetes had already considered ending this “war” of huge strength disparity when Kubernetes CRI standard was released in 2016.
Docker became popular worldwide after its first release at PyCon in 2013. It brings us a brand new concept, encapsulating the underlying cgroup, union filesystem, namespace, and other technologies, enabling general users to run programs through docker build + docker run. All you have to do is implementing a Dockerfile.
Of course, everyone is now tired of writing Dockerfile when you have Buildpacks, jib, etc. But back at that time, Docker was just like a flash of lightning across the dark sky or a beam of sunlight that ended the long night. How rejoicing! After all, Docker was the only option at the time!
However, the giant, Google, launched Kubernetes in 2014 to solve Docker container orchestration in large-scale scenarios, which ushered in a large number of users by supporting Docker. And then, Kubernetes has been moving forward in an unstoppable way since the release of Kubernetes 1.0 in 2015.
In the same year, large Internet companies established OCI (Open Container Initiative) and formulated standardized mirror production specifications. Since then, the image was no longer a Docker image but an OCI image. And Docker also contributed its runc to OCI.
Docker realized the problem and launched its own container orchestration management tool, swam, in 2016, to form a complete ecological closed-loop relying on Docker + swam + compose. We do not discuss the design of swam or compare it with Kubernetes here.
But the fact is that Kubernetes has taken the lead, while the swap is hardly able to stir up the ripple.
In 2018, CNB (Cloud Native Buildpacks) that Heroku and Pivotal jointly launched even resulted in many users’ abandoning Dockerfile directly, undoubtedly also various docker commands. Gradually, Docker has become a “daemon” on our computer.
Then emerged the containerd and CRI-O naturally.
The recent news that Slack was sold to Salesforce for $27.7 billion, even if it has had a substantial increase in users and a rapid improvement in performance during the pandemic this year. Why? Because its opponent is Microsoft Teams, which already has more than 100 million users in just one year, far surpassing Slack.
A small company is most valuable when it is in the most glorious moment!
The technology behind CRI
As a developer, we should return to technology. Let us see the real impact.
To understand CRI, we need to know Kubelet first.
The kubelet is the primary “node agent” that runs on each node. — kubernetes.io
Kubelet is a crucial component in Kubernetes, responsible for managing Pod and giving Pod its due functions. It works following the controller pattern.
When the control manager publishes the related Pod events, Kubelet responds to these events, including image, network, node, volume, etc.
For different events, Kubelet calls CRI, CNI, and CSI respectively to deal with runtime, network, and storage. These standard interface definitions follow the standard adapter pattern. Regardless of the implementation, it only needs to conform to the interface definition and provide service as a plugin.
Dockershim, deprecated in 1.20, is just one of the complex middlewares. It can convert Docker API and CRI. But Kubernetes will no longer provide this bridging service in the future.
Alternatives
The remaining two implementations of CRI are containerd and CRI-O.
- containerd is the runtime Docker contributed to the CNCF community in 2018, hoping to change its slow iteration with the community meanwhile. Now GKE and Amazon EKS are supportive of containerd.
- CRI-O, is a more lightweight runtime implementation. Openshift uses it currently.
Either of them supports Docker since they both use OCI mirroring essentially.
By deprecating dockershim, Kubernetes has also gotten rid of the tech debt of integrating Docker for easier popularization.
Official Docker doesn’t have CRI implementation! Maybe this is Docker’s aftermost insistence.
What does this expectedly affect us?
Generally speaking, whether you are a general Kubernetes user or a Kubernetes administrator using a cloud provider such as GKE/EKS, you will not be affected since what you do is just configuring YAML and deploying services. And your YAML configuration does not need to be changed.
You will be affected only in one situation that you are using a self-built Kubernetes cluster and required to install the controller runtime yourself. Then your choice would be,
- Install containerd or CRI-O
- Install dockershim. Docker announced that they would continue to maintain dockershim as open-source software.
Of course, in version 1.20, dockershim is only deprecated. The actual deletion will be in version 1.22, before which you still have time to make a decision.
Although Kubernetes has deprecated dockershim, it does not mean that we should remove Docker from the computer.
Container runtime is only part of the Docker ecosystem. Docker offers excellent tools such as Docker desktop and Dockerhub, the complete mirror library.
Simultaneously, for the various solution providers based on the entire Kubernetes ecosystem, the current Kubernetes-based orchestration is on de facto standard, and the container image format complies with OCI. So that all the previously delivered components will actually not be affected, regardless of the container runtime changes.
In local development, we can still choose Docker as a container and debug with various docker commands. The OCI image built by local Docker can also be uploaded and used in the Kubernetes environment.
After all, the inertia on technology is huge, and not everyone can or must exclude it. So let’s keep the two points in mind.
- The OCI specification includes the OCI image specification and the OCI runtime specification, and the mirror is universal. We can still use the mirror of Dockerhub in Kubernetes.
- We can still use Docker to build the image.
In the end
Times change and technologies evolve just like human metabolism. As a developer, we should always go with the tide, understanding the industry dynamics, and updating the tools in hand to better adapt to the future.
Note: The post is authorized by original author to republish on our site. Original author is Stefanie Lai who is currently a Spotify engineer and lives in Stockholm, original post is published here.
