Shulou(Shulou.com)06/01 Report--

This article will explain in detail how to understand the container runtime CRI interface. The content of the article is of high quality, so the editor will share it with you for reference. I hope you will have some understanding of the relevant knowledge after reading this article.

First of all, I will introduce the origin and design of the CRI interface; secondly, I will share with you the current implementation of CRI; finally, I will tell you what the relevant tools are.

1. Introduction of CRI

Before the advent of CRI (that is, before Kubernetes v1.5), when Docker ran as the first container, Kubelet manipulated the container through the embedded dockershim operation Docker API, thus achieving a terminal-oriented effect. After that, there was a new container runtime-rkt, which also wanted to be a container runtime supported by Kubernetes, which was integrated into the code of Kubelet. The addition of these two containers to the runtime makes the Kubernetes code more and more complex and difficult to maintain. After that, hyber.sh joins the community and wants to be the third container runtime.

At this point, someone came forward and said, can we abstract an interface to the operation of the container runtime and decouple the Kubelet code from the implementation code of the specific container runtime? as long as we implement such a set of interfaces, we can connect to the Kubernetes system, which is the Container Runtime Interface (CRI) we see later.

There is a good saying, "Software problems can be solved by adding a layer", and our CRI has added such a layer. The communication protocol of the CRI interface is gRPC, and one of the backgrounds here is that gRPC was just open source at that time, and its performance is better than that of http/REST mode. GRPC does not need handwritten client code and server code, and can generate communication protocol code automatically.

Next, let's introduce the design of the CRI interface.

2. CRI implements CRI interface.

With the introduction of the CRI interface, the architecture of Kubelet is shown in the figure above.

One of the Manager most relevant to the container is Generic Runtime Manager, which is a general-purpose runtime manager. We can see that dockershim still exists in the code of Kubelet, and it is currently the most stable implementation of the container runtime. Remote refers to the CRI interface. The CRI API mainly consists of two parts:

One is CRI Server, that is, general interfaces such as creating and deleting containers.

The other is the interface of streaming data Streaming Server, such as exec and port-forward.

It should be noted here that our CNI (Container Network Interface) also operates in CRI, because we need to create network resources and inject them into Pod at the same time when we create Pod. Then there are our containers and images. We create a specific container through a specific container creation engine.

Let's introduce the design of CRI interface. We know that one of the operational mechanisms of Kubernetes is end-state-oriented. In each coordination loop, Kubelet will get the data of the Pod dispatched to the Node from apiserver, and then do a terminal-state-oriented processing to achieve our expected state.

In the first step of the loop, the status of the container is obtained through the List API, and then the container is created through the Sandbox and Container interfaces. In addition, the image API is used to pull the container image. CRI describes the container runtime behavior that Kubelet expects, mainly in the three parts we just talked about.

Manipulate the lifecycle of the container through CRI

For example, if we run a Pod through the kubectl command, Kubelet will do the following through CRI:

First, call the RunPodSandbox API to create a Pod container. The Pod container is used to hold the relevant resources of the container, such as cyberspace, PID space, process space and other resources.

Then call the CreatContainer interface to create a business container in the space of the Pod container

Then call the API StartContainer to start the container, and the corresponding APIs to terminate the container are StopContainer and RemoveContainer.

CRI streaming interface

Here is a brief introduction to CRI's streaming interface exec. It can be used to execute a command inside the container, or to attach to the container's IO stream to do various interactive commands. What makes it special is that one is to save resources, and the other is the reliability of the connection.

First, the exec operation will be sent to apiserver. After authentication, apiserver will initiate an exec request to Kubelet Server, and then Kubelet will call the exec API of CRI to send the specific request to the runtime of the container. At this point, instead of serving the request directly on the exec interface, the container runtime returns the result of each execution asynchronously through our streaming server. In other words, apiserver actually interacts with streaming server to get our streaming data. This makes our entire CRI Server interface lighter and more reliable.

Some implementations of CRI

Some current implementations of CRI:

CRI-containerd

CRI-O

PouchContainer @ alibaba

...

CRI-containerd is the mainstream implementation of the new generation of CRI in the community. CRI-O comes from Red Hat, PouchContainer is CRI implemented by alibaba, and other CRI implementations will not be introduced here.

CRI-containerd

The following figure shows the architecture of CRI-containerd.

This set of CRI interfaces is based on containerd. In the early implementation, CRI actually interacted with containerd as a separate process. This adds another layer of process-to-process overhead, so in later versions, CRI is directly implemented in containerd as a plug-in and becomes a part of containerd, thus enabling the pluggable use of CRI interfaces.

The whole architecture looks very intuitive. Meta services, Runtime service and Storage service here are all interfaces provided by containerd. They are common container-related interfaces, including image management, container runtime management, and so on. CRI wraps a gRPC service on top of this. On the right is the implementation of the concrete container, for example, when you create the container, you create a specific runtime and its shim, which together with Container make up a Pod Sandbox.

One of the benefits of CRI-containerd is that containerd also implements richer container interfaces, so it can use the ctr tools provided by containerd to call these rich container runtime interfaces instead of just CRI interfaces.

CRI-O

The following figure shows the implementation of CRI-O.

It is a CRI service implemented by wrapping the container interface directly on OCI. It provides only specific CRI interfaces, not the richer interfaces provided by containerd as we mentioned earlier. It mainly consists of two parts, the first is the management of container runtime, and the other is the management of images.

III. Related tools

Let's introduce the tools related to CRI. These tools are all in a project of the special interest group.

Crictl

It is a command-line tool similar to docker that manipulates the CRI interface. It can help users and developers debug container problems, rather than by apply a yaml to apiserver, and then through the Kubelet operation to debug. Such links are too long, and this command-line tool can directly manipulate CRI.

Critest

Used to verify that the behavior of the CRI interface is as expected.

Performance tool

There are also performance tools to test interface performance.

Fourth, thinking time

At present, the CRI interface is in v1 alpha2 version, can the CRI specification be more perfect?

The formulation of the CRI standard is top-down, and through some feature of Kubernetes, CRI is required to provide this function in reverse, so as to improve the CRI specification.

How to customize runtime behavior through annotation?

Our current CRI certainly can not meet the needs of all users, many companies may make some enhancements and customizations to the CRI interface, such as alibaba. The easiest way is to customize the behavior of runtime through annotation. An annotation field is set on each interface, and the container runtime customizes the behavior of the runtime by understanding these fields. Students can try to identify annotation in each CRI interface to achieve the purpose of customizing runtime behavior.

This is the end of how to understand the container runtime CRI interface. I hope the above content can be helpful to you and you can learn more. If you think the article is good, you can share it for more people to see.

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.