CRI - Container Runtime Interface(容器運行時接口)
CRI中定義了容器和鏡像的服務的接口,因為容器運行時與鏡像的生命周期是彼此隔離的,因此需要定義兩個服務。該接口使用Protocol Buffer,基於gRPC,在Kubernetes v1.10+版本中是在pkg/kubelet/apis/cri/runtime/v1alpha2
的api.proto
中定義的。
CRI架構
Container Runtime實現了CRI gRPC Server,包括RuntimeService
和ImageService
。該gRPC Server需要監聽本地的Unix socket,而kubelet則作為gRPC Client運行。
啟用CRI
除非集成了rktnetes,否則CRI都是被默認啟用了,從Kubernetes1.7版本開始,舊的預集成的docker CRI已經被移除。
要想啟用CRI只需要在kubelet的啟動參數重傳入此參數:--container-runtime-endpoint
遠程運行時服務的端點。當前Linux上支持unix socket,windows上支持tcp。例如:unix:///var/run/dockershim.sock
、 tcp://localhost:373
,默認是unix:///var/run/dockershim.sock
,即默認使用本地的docker作為容器運行時。
CRI接口
Kubernetes 1.9中的CRI接口在api.proto
中的定義如下:
// Runtime service defines the public APIs for remote container runtimes service RuntimeService { // Version returns the runtime name, runtime version, and runtime API version. rpc Version(VersionRequest) returns (VersionResponse) {} // RunPodSandbox creates and starts a pod-level sandbox. Runtimes must ensure // the sandbox is in the ready state on success. rpc RunPodSandbox(RunPodSandboxRequest) returns (RunPodSandboxResponse) {} // StopPodSandbox stops any running process that is part of the sandbox and // reclaims network resources (e.g., IP addresses) allocated to the sandbox. // If there are any running containers in the sandbox, they must be forcibly // terminated. // This call is idempotent, and must not return an error if all relevant // resources have already been reclaimed. kubelet will call StopPodSandbox // at least once before calling RemovePodSandbox. It will also attempt to // reclaim resources eagerly, as soon as a sandbox is not needed. Hence, // multiple StopPodSandbox calls are expected. rpc StopPodSandbox(StopPodSandboxRequest) returns (StopPodSandboxResponse) {} // RemovePodSandbox removes the sandbox. If there are any running containers // in the sandbox, they must be forcibly terminated and removed. // This call is idempotent, and must not return an error if the sandbox has // already been removed. rpc RemovePodSandbox(RemovePodSandboxRequest) returns (RemovePodSandboxResponse) {} // PodSandboxStatus returns the status of the PodSandbox. If the PodSandbox is not // present, returns an error. rpc PodSandboxStatus(PodSandboxStatusRequest) returns (PodSandboxStatusResponse) {} // ListPodSandbox returns a list of PodSandboxes. rpc ListPodSandbox(ListPodSandboxRequest) returns (ListPodSandboxResponse) {} // CreateContainer creates a new container in specified PodSandbox rpc CreateContainer(CreateContainerRequest) returns (CreateContainerResponse) {} // StartContainer starts the container. rpc StartContainer(StartContainerRequest) returns (StartContainerResponse) {} // StopContainer stops a running container with a grace period (i.e., timeout). // This call is idempotent, and must not return an error if the container has // already been stopped. // TODO: what must the runtime do after the grace period is reached? rpc StopContainer(StopContainerRequest) returns (StopContainerResponse) {} // RemoveContainer removes the container. If the container is running, the // container must be forcibly removed. // This call is idempotent, and must not return an error if the container has // already been removed. rpc RemoveContainer(RemoveContainerRequest) returns (RemoveContainerResponse) {} // ListContainers lists all containers by filters. rpc ListContainers(ListContainersRequest) returns (ListContainersResponse) {} // ContainerStatus returns status of the container. If the container is not // present, returns an error. rpc ContainerStatus(ContainerStatusRequest) returns (ContainerStatusResponse) {} // UpdateContainerResources updates ContainerConfig of the container. rpc UpdateContainerResources(UpdateContainerResourcesRequest) returns (UpdateContainerResourcesResponse) {} // ExecSync runs a command in a container synchronously. rpc ExecSync(ExecSyncRequest) returns (ExecSyncResponse) {} // Exec prepares a streaming endpoint to execute a command in the container. rpc Exec(ExecRequest) returns (ExecResponse) {} // Attach prepares a streaming endpoint to attach to a running container. rpc Attach(AttachRequest) returns (AttachResponse) {} // PortForward prepares a streaming endpoint to forward ports from a PodSandbox. rpc PortForward(PortForwardRequest) returns (PortForwardResponse) {} // ContainerStats returns stats of the container. If the container does not // exist, the call returns an error. rpc ContainerStats(ContainerStatsRequest) returns (ContainerStatsResponse) {} // ListContainerStats returns stats of all running containers. rpc ListContainerStats(ListContainerStatsRequest) returns (ListContainerStatsResponse) {} // UpdateRuntimeConfig updates the runtime configuration based on the given request. rpc UpdateRuntimeConfig(UpdateRuntimeConfigRequest) returns (UpdateRuntimeConfigResponse) {} // Status returns the status of the runtime. rpc Status(StatusRequest) returns (StatusResponse) {} } // ImageService defines the public APIs for managing images. service ImageService { // ListImages lists existing images. rpc ListImages(ListImagesRequest) returns (ListImagesResponse) {} // ImageStatus returns the status of the image. If the image is not // present, returns a response with ImageStatusResponse.Image set to // nil. rpc ImageStatus(ImageStatusRequest) returns (ImageStatusResponse) {} // PullImage pulls an image with authentication config. rpc PullImage(PullImageRequest) returns (PullImageResponse) {} // RemoveImage removes the image. // This call is idempotent, and must not return an error if the image has // already been removed. rpc RemoveImage(RemoveImageRequest) returns (RemoveImageResponse) {} // ImageFSInfo returns information of the filesystem that is used to store images. rpc ImageFsInfo(ImageFsInfoRequest) returns (ImageFsInfoResponse) {} }
這其中包含了兩個gRPC服務:
- RuntimeService:容器和Sandbox運行時管理。
- ImageService:提供了從鏡像倉庫拉取、查看、和移除鏡像的RPC。
當前支持的CRI后端
我們最初在使用Kubernetes時通常會默認使用Docker作為容器運行時,其實從Kubernetes 1.5開始已經開始支持CRI,目前是處於Alpha版本,通過CRI接口可以指定使用其它容器運行時作為Pod的后端,目前支持 CRI 的后端有:
- cri-o:cri-o是Kubernetes的CRI標准的實現,並且允許Kubernetes間接使用OCI兼容的容器運行時,可以把cri-o看成Kubernetes使用OCI兼容的容器運行時的中間層。
- cri-containerd:基於Containerd的Kubernetes CRI 實現
- rkt:由CoreOS主推的用來跟docker抗衡的容器運行時
- frakti:基於hypervisor的CRI
- docker:kuberentes最初就開始支持的容器運行時,目前還沒完全從kubelet中解耦,docker公司同時推廣了OCI標准
CRI是由SIG-Node來維護的。
當前通過CRI-O間接支持CRI的后端
當前同樣存在一些只實現了OCI標准的容器,但是它們可以通過CRI-O來作為Kubernetes的容器運行時。CRI-O是Kubernetes的CRI標准的實現,並且允許Kubernetes間接使用OCI兼容的容器運行時。
- Clear Containers:由Intel推出的兼容OCI容器運行時,可以通過CRI-O來兼容CRI。
- Kata Containers:符合OCI規范,可以通過CRI-O或Containerd CRI Plugin來兼容CRI。。
- gVisor:由谷歌推出的容器運行時沙箱(Experimental),可以通過CRI-O來兼容CRI。