Hello everyone, I’m Zhang Jintao.

It has been confirmed that Dockershim code will be officially removed from The Kubernetes repository in Kubernetes V1.24, which is expected to be released around April next year. The dockershim code will be officially removed from Kubernetes source repository next month, so you can try using the alpha version for testing or self-compiling.

Old fans may have seen my post last year, “K8S abandoned Docker? Docker can not be used? In which, I detailed the so-called “origin and result of Kubernetes’ discarding of Docker”, etc.

Now that it’s been almost a year since it was officially announced, let’s take a look at how it’s changed and updated.

In order to take care of new partners, let’s clarify the impact of Kubernetes’ removal of dockershim’s in-tree code on different roles (architecture, development, cluster administrator, etc.) and what needs to be done.

Kubernetes remove tree dockershim code does not mean Docker is not available! ** The function of Dockershim itself is to connect Kubelet and Docker through CRI. **Kubernetes has launched CRI to meet support for different container runtimes! We need to fundamentally understand the positioning of Docker and what Dockershim means to Kubernetes.

Trace back to the source – Positioning of Docker and Kubernetes CRI

The more you know, the less you fear.

Docker

Docker is positioned as the Development Platform, that is, as a developer tool, not as an underlying container runtime.

So, we can see that Docker added Containerd to CNCF in 2017, and Kubernetes added containerd support in November of the same year (2018, Kubernetes containerd integration, official GA).

Figure 1. Integration of Kubernetes CRI with container runtime Containerd

Figure 1 shows what the entire processing link is if the container runtime is replaced with containerd. As you can see, the processing link is shortened.

Kubernetes CRI

In December 2016, Kubernetes released CRI (Container Runtime Interface).

As mentioned in the previous article, Kubernetes was born in 2014 to solve the problem of Docker container choreography in large-scale scenarios. At that time, Docker was the most popular and only container runtime, and the support for Docker made Kubernetes welcome a large number of users in the early days.

In order to prevent being locked in the Docker container runtime, and to reduce the development workload in the integration of other runtime, Kubernetes introduced a unified CRI interface, all support CRI runtime, can be directly as Kubernetes bottom runtime. In order to deal with more complex requirements and scenarios.

From the historical track of development, in 2014, Kubernetes had no more choices. Dockershim was built to cater to a large number of Docker users. Kubernetes has benefited from this. The emergence of CRI is inevitable (after all, Kubernetes won the container choreography war in 2016).

Figure 2 shows Kubernetes adding support for Containerd

So what is CRI?

CRI was introduced in Kubernetes V1.5 (released as Alpha), a plug-in interface that enables Kubelet to use various container runtimes without recompiling. The advent of CRI is a decoupling that reduces the maintenance costs of the Kubernetes community and reduces the barriers that developers need to have a deep understanding of Kubelet internals and code, as well as breaking down the high barriers to access to Kubernetes by the nascent container runtime.

Kubelet uses the gRPC framework to communicate with the container runtime (or runtime CRI Shim) over Unix sockets, with Kubelet as the client and CRI Shim as the server.

Figure 3. CRI implementation principle

The API includes two gRPC services:

  • ImageService – Provides RPC to extract, examine, and delete images from the repository.
  • RuntimeService – contains RPC to manage the Pod and container lifecycle, as well as calls to interact with the container (exec/ ATTACH /port-forward).

A little embarrassed and confused dockershim?

Dockershim has always been a compatible program maintained by the Kubernetes community in order to make Docker a supported container runtime.

And we don’t have to worry too much about Dockershim. Mirantis has promised to take over and continue supporting Dockershim. That is, while Kubernetes removes dockershim code from its repository, Mirantis maintains a copy of dockershim out of the tree. If you want to continue using Docker as the Kubernetes container runtime, then you need to run Dockershim outside the tree.

Please also check the video below patiently, www.youtube.com/watch?v=epo…

Mirantis is once again on record as saying that we shouldn’t be worried about the future of Dockershim.

impact

I believe that many friends are most concerned about what changes this change will bring to our daily production and development environment. How do we respond quickly?

Instead, ask your friends to evaluate their actual production environment.

  • Kubernetes upgrade cycle in production
  • What is the container runtime currently used in the production cluster

Of course, as the developers of application software, the change, does not bring any development Angle of impact (unless, you are a container and container choreography development ヾ(◍°∇) ◍ blue).

If you are a container, container layout developer, cluster maintenance manager, architect, and container technology focused partner, please pay attention and actively test and respond to the alpha and beta releases of Kubernetes V1.24, which will be released in December. You also need to dig into CRI and the more popular container runtimes (Containerd, Cri-O).

I encourage you to learn more about Containerd. Consider the containerd Hands-on post I did last year. PPT available here github.com/tao12345666…

Although Mirantis claims that it will maintain DockerShim together with Docker, there is no substantial progress in dockerShim maintained by Mirantis so far. Containerd is used as a runtime for Its Kubernetes in many cloud vendor and company production environments.

Finally, guys, embrace change!

Please feel free to subscribe to my official account [MoeLove]