“Dockershim deprecated with the release of Kubernetes 1.24” ¶
The above sentence is the headline of an article published in The Register. What do you think of the sentence? I was just curious about the technology implemented by containers, but didn’t think much of it because I didn’t make a living using the related technology. However, I recently found out that it was a very big topic in the related industry. In fact, Kubernetes wrote the following article.
“Don’t Panic: Kubernetes and Docker”, Kubernetes Blog
Kubernetes creator Joe Beda tweeted the above. The confusion has arisen because everything, including the company, is “Docker”. In fact, the company name and product name are “Docker”, and it would be shocking to hear that “Docker” is included in the titles of many related elements. The naming of Conainerd, which will be explained later, seems to be a ’d’ added to “Container” because it operates as a Daemon process. Although this level follows the naming conventions of numerous daemons in Linux such as systemd and httpd… Also, one of the two shells for handling Containerd is ctl and the other is nerdctl. “ctl”? Could it be that the abbreviation for “control” was used as it is? Even “nerdctl” seems to prepend “nerd”, the last four letters of “Containerd”. Ah… Containerd is a project derived from Docker, so it seems that the naming sense was also derived.
Anyway, what the above article is referring to is Dockershim, not Docker, to be exact, so Kubernetes has announced “Don’t panic” so you don’t get confused. So what is Dockershim? With this as a hot topic, let’s examine the relationship between the major technologies of the container camp.
Docker, Containerd, Kubernetes… ¶
The container camp has exploded since the advent of Docker. If you search recently, you can see that there are many technologies, centered on Containerd and Kubernetes, besides Docker. With so many technologies piling up, what could be considered a standard has emerged to ensure compatibility between them.
OCI(Open Container Initiative) ¶
OCI appeared first. After Docker, various vendors such as rkt have different container formats, so it is a standard that has emerged to ensure compatibility between them. In other words, containers and container images created by a specific OCI-runtime can be freely used in major container-runtimes such as Kubernetes, including Docker. The most popular OCI-runtime is runc. Oh, no doubt it was developed by Docker, as you can see from the naming sense of adding the “c” of the container to “run” of run. Container-related technologies are often written in Go language, but in the case of runc, since it was written in C language, “c” may have been added. Anyway, there is also an OCI-runtime called crun, which is characterized by being developed in Go on the contrary. The naming sense seems to be contagious throughout the community. Also, there are Kata-runtime and OCI-runtime such as gVisor specialized for security.
CRI(Container Runtime Interface) ¶
With the advent of CRI, OCI-runtime is separated from Docker, and another container runtime called Containerd is separated. If the OCI-runtime is responsible for actually creating the container, the container runtime is responsible for the rest. For example, importing an image from a remote location, configuring a file system to be used in a container with AUFS or OverlayFS, or configuring a network. In other words, the characteristics of containers that we find useful are not actually in the container itself, but in the external part.
On the other hand, although many people know that Kubernetes is similar to Docker, it should be viewed as a container orchestration tool that manages container runtimes like Containerd. For example, Kubernetes targets multiple containers and distributes them appropriately on multiple servers, or replaces problematic containers, and only requires Containerd, a container runtime. In addition, if you create and support a specification called CRI (Container Runtime Interface) to use various container runtimes, you can use it in Kubernetes. However, when Containerd did not exist, the Kubernetes side had to use Docker as the container runtime somehow, so Dockershim was developed. In other words, Dockershim allows Docker to be treated by Kubernetes as if it were a container runtime with CRI support.
Looking back at the contents of the previous article, Kubernetes has stopped supporting Dockershim, not Docker. Therefore, it is necessary to replace the container runtime with Containerd or CRI-O. Perhaps because Containerd, which supports CRI, is also being used by Docker, there is no reason to use Dockershim anymore. Regarding the transition to Containerd, there are some points to be aware of regarding namespaces, so it is necessary to pay attention to this part.
Containerd ¶
So far, the relationship between the major technologies of the container camp has been explored. Among them, Containerd is a container runtime used by Docker and Kubernetes, and you can see from the figure above that Docker and containers are in a very important position because they are used by many cloud platforms. Containerd has core modules such as Content Store, Snapshotter, and Runtime to provide the functions expected of a container. In addition, it provides various services based on namespace and metadata so that anyone can use it easily. I am interested in the implementation of Containerd, so I will often organize articles about these modules and services.