Shulou(Shulou.com)05/31 Report--

This article mainly explains "how to use Containerd as Kubernetes runtime". The content in the article is simple and clear, easy to learn and understand. Please follow the editor's train of thought to study and learn "how to use Containerd as Kubernetes runtime".

Kubernetes announces abandonment of dockershim

Many media claimed that the incident was Kubernetes announced the abandonment of Docker, in fact, this is a misleading. So how to treat it correctly? The first thing is to understand the causes and consequences of the whole thing, and you need to know what dockershim is.

Dockershim

Dockershim is a component of Kubernetes, the main purpose is to manipulate Docker through CRI. Docker has been around since 2013, when Kubernetes released in 2014 and uses Docker as a container by default, while dockershim first officially appeared in 2016. Docker did not consider container orchestration or Kubernetes at the beginning of its creation, but when Kubernetes uses Docker as its default container at the beginning of its creation, the subsequent code contains a lot of operation logic related to Docker. In order to decouple and be compatible with more containers in the later stage of Kubernetes, the operation of Docker-related logic is composed of dockershim as a whole.

Container Runtime Interface

In addition, CRI (Container Runtime Interface) is the container runtime interface, which was put forward by Kubernetes and applied at the end of 2016. its main goal is to enhance the scalability of Kubernetes, which can be unfixed or bundled with a container runtime to achieve pluggable container progressive time. For example, you can use Docker to run for the container, and you can also use other rkt, and you want to improve the maintainability of the code by opening the unified interface of CRI, instead of adapting Docker when you need to support Docker. If you need to support another runtime, you have to adapt to it. It hopes that any container runtime that becomes Kubernetes complies with the unified interface and specification of CRI, and that CRI can be used as a runtime of Kubernetes without paying attention to what it is.

Why abandon dockershim

The purpose of dockershim is for Kubernetes to operate Docker through CRI, so if there are any functional changes in Kubernetes or any functional changes in Docker, the dockershim code must be modified to support the changes. Another reason is that with the development of container technology, there are a variety of container runtimes, such as Containerd, the protagonist of this sharing, and the container runtimes of cri-o and rkt, but the project of this rkt container runtime is no longer maintained.

In addition, the original Kubernetes needs to call dockershim to communicate with Docker, the underlying runtime of Docker is containerd, you can find that eventually you have to call containerd, and containerd itself can support CRI. So why bypass a layer of Docker first? Is it possible to interact with Containerd directly through CRI? This has led to the desire of the Kubernetes community to abandon dockershim.

The influence of abandoning dockershim

The terminal is not responsible for any impact. This refers to end users from cloud vendors / Kubernetes clusters provided by others, who do not need to pay attention to what the container runtime of the cluster itself is, because you are interacting with Kubernetes's own CRI, and anything that can be used as the underlying container runtime of Kubernetes must be compatible with CRI interface, which has been blocked out by the upper layer.

It has a certain impact on the staff responsible for maintaining the Kubernetes cluster. When upgrading the Kubernetes cluster version, you need to consider whether to switch container travel times. If you are currently using the latest version of Kubernetes V1.20 and are running with Docker as a container, consider whether it works properly. In fact, it works normally, but when you start Kubernetes, you will find a log reminding you that the container runtime Docker is no longer supported by Kubernetes, because you are ready to discard dockershim.

The Kubernetes community plans to formally remove dockershim in 2021. On the other hand, since the community doesn't want to maintain dockershim in the Kubernetes source code, can the dockershim components be taken out separately? The answer is yes, now that Mirantis and Docker have decided to work together to maintain the dockershim component. In addition, you can also use dockershim independent components outside the tree to continue to use Docker as a container runtime, and to use this way, you only need to do some simple configuration to change the original use of the built-in dockershim components carried by Kubernetes itself to use a separate dockershim component with little change.

So can Docker still be used? In my opinion, there is no doubt that Docker is still the best choice for building and running containers at this stage.

Get to know Containerd quickly

Containerd is the container runtime for the middle tier. It is built under the platform and acts as a container runtime at the lower level of the platform, but it is a little higher than the lowest container runtime such as runc and gVisor, so it is called the middle-tier container runtime. In addition, it can also be called a resource manager, which can be used to manage container processes, mirrors, and snapshots of file systems, as well as metadata and dependency management. Since it can be used as a resource manager, it will be convenient if you want to build your own container platform on top of it.

Containerd was founded by Docker and donated to CNCF,2019 in 2017. Containerd graduated from CNCF in 2017. The initial goal of the Containerd project is to manage the process of the container, and then gradually change to a complete container runtime, which is the underlying container runtime of Docker. To be clear, containerd can work independently of Docker and Kubernetes itself.

Containerd and CRI

Containerd took CRI into account in previous versions, but it existed CRI as a separate process. CRI-Containerd is actually a stand-alone component. Kubernetes calls CRI-Containerd through the CRI interface, and this component invokes containerd. This feature is redesigned after the Containerd1.1 version, which implements the support of CRI through plug-ins. Kubernetes calls the plug-ins of CNI in Containerd through the CRI interface, so as to achieve the purpose of communication, and the call chain is less and shorter.

Characteristics of Containerd

Support for OCI mirroring specification, that is, runc mentioned earlier

The OCI runtime specification is supported. Docker led the establishment of the OCI organization, which has two main specifications: the mirror specification and the runtime specification. When Docker was established, these two specifications donated both the Docker image specification and the underlying container runtime specification as their initial work.

The push/pull function of image is supported.

Container network management is supported. Because the container can be started and run, and the container supports mutual access or network isolation after startup, it is necessary to support the management of the container network.

Storage supports multi-tenancy. Some of the operations related to Containerd are isolated through namespace. You can specify different namespace to implement. Its default namespace is default. Download multiple images under the namespace of default. But these images are not seen or used under other namespace to achieve multi-tenant isolation.

Support for container runtime and container lifecycle management

Support to manage network namespace containers to add existing namespaces, and you can add a container to an existing namespace

The overall architecture of Containerd

The image above shows the overall architecture of Containerd. From the bottom up, Containerd supports operating systems and architectures such as Linux, Windows, and platforms like ARM. Running on top of these underlying operating systems is the underlying container runtime, including runc, gVisor, and so on. On top of the underlying container runtime are Containerd-related components, such as Containerd's runtime, core, API, backend, store, and metadata. Building on Containerd components and interacting with these components are Containerd's client,Kubernetes which acts as a client of Containerd when it interacts with Containerd through CRI. Containerd itself provides a CRI called ctr, but this command-line tool is not very useful.

On top of these components are real platforms, such as Google Cloud, Docker, IBM, Aliyun, Microsoft Cloud, RANCHER, and so on, all of which currently support containerd, and some of them already run as their default containers.

Main functions and hands-on practice of Containerd

Mirror management

The first is mirror management, which is frequently mentioned above. The specific operation is to interact with Containerd through a client. As shown in the figure, ctr's command line tool is selected here. Ctr specifies an address parameter to interact with Containerd, which is a service that runs continuously in the background and needs to specify its address. In the figure, you can see a redis alpine linux image through pull, and then you can see the image that has been successfully pull via image ls.

Container management

Managing containers when running as a container is an essential function. Similarly, the-a parameter is used to specify address to communicate with Containerd, and a container is created by container create+ image name + container name. You can see the container you just created through container ls. It is important to note that the last column is called runtime, and its runtime is called io.containerd.runc.v2, indicating that it is a v2 version of Containerd API.

The container created through container create in Containerd doesn't really work, and you need to make it work. At this point, you usually think of it as a task, execute task start on it, and you can run the image you just created. Through task ls, you can see a Containerd called redis, which has a running process and shows the process number.

Namespace

To be clear, you can specify a default namespace called default with-n, and then you can see through task ls that the process that just started the container is actually running. If you replace the namespace, for example, the moby in the figure is the namespace name currently used by the Docker project, Docker will use it by default when using Containerd as the container runtime.

Read on, specify the use of the moby namespace through ctr-n, specify the address of the containerd with the-a parameter, and then task ls to see what's running in the moby project. You can see that there is a record that is running. How does this record match with containers or tasks in Docker? A simple way is to use docker ps-- no-trunc-- format with the container's full ID, and then grep can see the ID you just got through the ctr command.

It is important to note that if you use Containerd as a container for Kubernetes, then its namespace is called k8s.io. Some of you may have found that Containerd can use different namespaces, such as moby, as the runtime of Docker. You can also use different namespaces, such as k8s.io, when running as a Kubernetes container. Is there a way to have both Kubernetes and Docker and Containerd in the platform? The answer is yes, just put it all together, but it's also a way to watch for a while when you don't configure Docker to run as a container.

Containerd is used as runtime for Kubernetes

The figure above is the entire flowchart of runtime in which Containerd is used as Kubernetes. Kubernetes calls to CRI plugin,plugin through the CRI interface, which is a built-in plug-in for Containerd, which contains two main parts: one is image service, which contains the image service, and the other is runtime service, that is, the runtime service. If a project or service is deployed in containerd, it will first be dispatched to a certain machine, and the Kubernetes on this machine will start to work. It will query the service and which images are needed, then pull down the relevant images to the runtime, and then start the corresponding pod or related containers.

Second, it also interacts with CNI. CNI, or Container Network Interface, is a container network interface provided by Kubernetes. The main thing to note is that the container of pause may be created in advance during the interaction, which is a placeholder process, so I won't go any further here.

When Containerd runs as a container for Kubernetes, the configuration is relatively simple: the complete default configuration of Containerd can be queried directly through the containerd config default command, as you can see in the following figure, mainly configuring CRI. So in the configuration file here, you configure it through plugins.io.containerd.grpc.vi.cri, first default-runtime, and then a runtime.runc.

Here is a brief introduction to the parameters that you need to pay attention to when configuring runc. For example, io.containerd.runc.v2 needs to configure runtime.type;, which involves configuring some configurations related to runc, including some CNI configurations, directories, and so on, as shown in the figure above. All in all, if you want to mention a service, a pod, or a container, note that it all needs to be configured. It all has a pause image, sandbox_image, from which you can specify a default image. Of course, you can also change the source here to speed up the pulling speed in the domestic environment.

Finally, there are some other resources, such as a project I have been involved in for a long time, KIND (Kubernetes in docker). This project is equivalent to using a docker container as a different node, which can be used to form a cluster network and build a set of Kubernetes. The container used in this cluster is containerd. Although Docker was used at the beginning, it was gradually replaced with containerd later, including K3C and K3S, and the effect is similar.

Thank you for your reading, the above is the content of "how to use Containerd as Kubernetes runtime", after the study of this article, I believe you have a deeper understanding of how to use Containerd as Kubernetes runtime, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.