Author: Bach (only cloud), bot (only cloud)
technology proofread: Tsai (only cloud) under the stars
Deprecate Docker
The latest version of Kubernetes, Kubernetes v1.20.0-rc.0, is now officially released. Kubernetes plans to deprecate Docker Engine support in kubelet, and support for dockershim will also be dropped in the next version. [1]
But don't worry, in the current Kubernetes v1.20, Kubernetes administrators can continue to use Docker commands and kubectl commands to manage Kubernetes clusters, and the use of mirroring will not be affected in any way. In the future releases of Kubernetes, including minor versions that will be released one after another, support for dockershim will eventually be removed (Dockershim will be removed from Kubelet as early as v1.23), and Docker commands will not be available for checking at that time Cluster.
What Kubernetes deprecated this time is dockershim[2], which is one of the components in the Kubernetes kubelet implementation, which can communicate with Docker Engine.
In fact, Docker already includes containerd, why does Kubernetes still need Dockershim? This is because Docker is not compatible with CRI (Container Runtime Interface). In short, Docker does not support CRI (Container Runtime Interface), a Kubernetes runtime API, and what Kubernetes users have been using is actually a bridging service called "dockershim". Dockershim can convert the Docker API and CRI, but in the future, Kubernetes will no longer provide this bridging service.
Why deprecated
Kubernetes is an infrastructure tool that can group a variety of different computing resources (such as virtual and physical machines) and make them appear as a unified huge computing resource, which can be used by applications or shared with others. In such an architecture, Docker (or container runtime) is only used for scheduling through the Kubernetes control plane to run applications on the actual host.
Through the above architecture diagram, you can see that each Kubernetes node communicates with the control plane. The kubelet on each node obtains metadata and executes CRI to create and delete containers on that node. Kubernetes can only communicate with CRI, so to communicate with Docker, you must use the bridging service "dockershim". This is the first reason.
Here's another look at the Docker architecture diagram:
Kubernetes actually only needs the content in the red box, the Docker network and storage volume are external, and these unused functions may bring security risks. As we all know, the fewer functions you have, the smaller the *** area. This is the second reason.
Therefore, we need to consider the use of alternatives, namely CRI runtime, such as containerd and CRI-O, the following is the difference between choosing the two:
-
containerd is compatible with Docker, and both share the same core components.
- If you mainly use the minimal functional options of Kubernetes, CRI-O may be more suitable. [4]
how to respond
For Kubernetes end users , this adjustment will not have much impact. Docker will not die here, you can still continue to use Docker as a development tool. Docker can continue to build containers, and the image generated by running the docker build command can also run normally in the Kubernetes cluster.
If you are using a Kubernetes managed service , you need to ensure that a supported container runtime is introduced for worker nodes before Docker support is completely abandoned in future Kubernetes versions. If the node contains customization items, it may need to be updated according to the current environment and runtime requirements to ensure that the upgrade test and planning are completed correctly.
If the cluster is continuously expanding , it is necessary to cooperate with variables to avoid service interruption. In v1.20, we will receive a Docker deprecation warning. In the future version of Kubernets (v1.23 scheduled to be released in the second half of 2021), the Docker runtime will be completely removed and will no longer be supported. You must switch to other compatible container runtimes, such as containerd or CRI-O. We only need to ensure that the runtime we are using can support the current Docker daemon configuration (such as logging). [3]
Deprecation FAQ
Why is dockershim deprecated?
Maintaining dockershim has become a heavy burden for Kubernetes maintainers. The CRI standard was created to reduce this burden and allow smooth interoperability of different container runtimes. Docker itself has not yet implemented CRI, so there is a problem. In addition, these newer CRI runtimes are implementing features that are basically incompatible with dockershim, such as cgroups v2 and user namespaces. Abandoning support for dockershim can have more energy for further development in these areas.
Can Docker be used in Kubernetes v1.20?
Yes, the only change in v1.20 is that if Docker is used as the runtime, a warning log will be printed when the kubelet starts.
When will dockershim be removed?
It will not be removed before Kubernetes v1.22, which means that the earliest version that does not use dockershim will be v1.23 at the end of 2021.
Will the existing Docker image still work?
Yes, the images generated from the docker build will work with all CRI implementations, and all existing images will continue to work exactly the same.
Can the private image continue to work?
Yes, all CRI runtimes support the same pull secret configuration used in Kubernetes, whether through PodSpec or ServiceAccount. [5]
Reference materials:
[1]https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#deprecation
[2]https://github.com/kubernetes/kubernetes/tree/master/pkg/kubelet/dockershim
[3]https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/
[4]https://dev.to/inductor/wait-docker-is-deprecated-in-kubernetes-now-what-do-i-do-e4m