Kubelet CRI container runtime

CRI

---

kubelet When starting the container process , To really start these container processes , With the iteration of the version , It will gradually start these standard behaviors in the process , Abstract as one interface .

Its benefits are kubelet There is no need to be specific runtime The binding relationship is generated ,kubelet They are some code frameworks , It defines these interfaces , It only needs to call these interfaces , These interfaces are implemented by different container runtime providers .（ Let the runtime adapt to my standards , In this way, you can use or not use you ）

So we can choose to use docker still containerd or kata Other types of containers ？

So that makes kubernetes There is no specific strong binding relationship with a certain runtime , Prevent being locked by a manufacturer .

Container runtime （Container Runtime）, To run on Kubernetes（K8s） In each node of the cluster , Responsible for the whole life cycle of the container . among Docker It is the most widely used . With the development of container cloud , More and more container runtime emerge . In order to solve these problems of container runtime and Kubernetes The integration problem , stay Kubernetes1.5 In the version , The community launched CRI（Container Runtime Interface, Container runtime interface ） To support more container runtime .

CRI Namely , It abstracts these interfaces that implement the standard when the container is running , You kubelet To operate any container process is through CRI The interface of , Then different container runtimes will implement these CRI Interface , Finally, operate these container processes .

CRI yes Kubernetes A set of definitions gRPC service .kubelet As a client , be based on gRPC frame , adopt Socket Communicate with the container runtime .

It includes two types of services ∶ Image services （Image Service） And runtime services （Runtime Service）.

• Image service provides downloading 、 Check and delete the remote program call of the image .
• The runtime service contains services for managing the container lifecycle , And calls that interact with the container （exec/attach/port-forward） Remote program call .

kubelet The client side. , You can see in the kubelet There are grpc client, It will go based on grpc The framework calls the runtime service , similar docker containerd This kind of service . It's running on kubelet In addition to the , In the installation kubernetes When , I will install it first docker containerd, Install after installation kubelet.

In this case kubelet Call as a client runtime The interface of . these runtime According to CRI To implement those interfaces .

The ultimate goal of container runtime is to start container processes one by one , So you can understand that the container runtime itself is an intermediate layer , It faces up kubelet, Facing down are these container processes .

So it is divided into high-level-runtime and low-level-runtime,high-level-runtime These are provided externally grpc service . By the client grpc client To call these services , It receives these requests through low-level Of api To start and operate these containers .

It's a bit like a layer of agent , It just forwards commands , Accept requests from clients , Then operate the following container process .

It's called low-level-runtime, Containers are runc.

 

The level of runtime

---

Dockershim, containerd and CRI-O They all follow CRI When the container is running , We call them high-level runtime (High-level Runtime).

The container runtime finally follows oci A standard of ,oci Defines industry standards related to containers . This industry standard is mainly divided into three categories , Defines how images are packaged , How to decompress such a specification . A specification of how to run container processes through mirroring .

OCI（Open Container Initiative, Open container program ） Open source industry standards that define the format and runtime for creating containers , Including image specifications （Image Specification） And runtime specifications （Runtime Specification）.

The image specification defines OCI The standard of mirroring . The high-level runtime will download one OCI Mirror image , And decompress it into OCI Runtime file system package （filesystem bundle）（ And store the image file in the specified directory ）.

The runtime specification describes how to OCI The runtime file system package runs the container program , And define its configuration 、 Operating environment and life cycle . How to set a namespace for a new container （namepsaces） And the control group （cgroups）, And mount the root file system , It's all defined here . A reference implementation of it is runC. We call it low-level runtime （Low-level R untime）. except runC outside , There are many other runtimes that follow OCI standard , for example kata-runtime.

 

CRI

---

containerd It can replace docker Of , because docker Embedded in itself containerd Of ,docker It's a stand-alone product , We can go through docker Command to manage your own network , Manage your own storage , therefore docker Most of the bloated logic is docker daemon Its own logic , After these logics are processed, the request is also sent to the built-in containerd Go inside , In fact, the real logic of implementation is containerd Inside .

Storage , Network is kubernetes and docker Competition between , stay kubernetes It's full of kubernetes The management system , that docker The part of is actually redundant . No longer use docker Self daemon 了 , But I can use you docker Brought by itself containerd Of .

about CRI The main thing is runtimeservice and imageservice.

imageservice Provides a lot of interfaces , It's mainly about image Related operations .

runtimeservice Also through many interfaces , You can see that it's right sandbox There are a lot of operations , And related to the user container .

 

 

 

Open source runtime comparison

---

Above are three commonly used runtime , The top path is actually the longest .

If it is docker Runtime , So kubelet call dockeshim, call docker Then call containerd,containerd Re pass runc Interface to call the underlying container process .

If it is containerd Then there is no docker-shim and docker, Directly by the kubelet Send an order to containerd, then containerd To runc.

If it is crio So much lighter ,kubelet call crio, Then call directly runc.

More and more concise .

 

Docker and Containerd Differences in details

---

If it's through kubelet To call docker Words , This request is in kubelet Of cri Interface call docker-shim,docker-shim And then connect to docker-daemon,docker-daemon This part of the red circle inside is useful , That is, and image Related operations , And really go to call containerd This part of the operation is useful , Above the storage network , already docker Provided cli These are not needed , Then these are redundant .

If you will docker Replace it , Then there is no part beyond the red line , Then the complexity will be greatly reduced , Use it directly cri Call the interface of containerd, These unnecessary call forwarding links are removed , In this way, the whole system architecture is simpler .

The above is to understand and remove docker The meaning of , This is a necessary action .

 

 

 

Comparison of various runtime performance

---

When selecting models, one is the simplicity of the architecture , stability , And its performance .