天天看點

Kubernetes必備知識: 容器接口CRI

所屬技術領域:

K8s

|名詞定義|

每種容器運作時各有所長,許多使用者都希望Kubernetes支援更多的運作時。在Kubernetes 1.5釋出版裡,我們引入了CRI–一個能讓kubelet無需編譯就可以支援多種容器運作時的插件接口。CRI包含了一組protocol buffers,gRPC API,相關的庫,以及在活躍開發下的額外規範和工具。CRI目前是Alpha版本。

支援可替換的容器運作時在Kubernetes中概念中并非首次。在1.3釋出版裡,我們介紹了rktnetes項目,它可以讓rkt容器引擎作為Docker容器運作時的一個備選。然而,不管是Docker還是Rkt都需要通過内部、不太穩定的接口直接內建到kubelet的源碼中。這樣的內建過程要求十分熟悉kubelet内部原理,并且還會在Kubernetes社群引發巨大的維護反響。這些因素都在為容器運作時的初期造成了巨大的困難。我們通過提供一個清晰定義的抽象層消除了這些障礙,開發者可以專注于建構他們的容器運作時。這是很小的一步,但對于真正提供可插拔的容器運作時和建構一個更健康的生态系統卻意義非凡。

|技術特點|

 CRI的由來

在CRI之前(Kubernetes v1.5之前)

Docker作為第一個容器運作時,Kubelet通過内嵌其中的dockershim操作Docker API來操作容器

artrkt作為一種容器運作時也合入了kubelet代碼中,進一步提高維護的複雜度

hyber.sh加入社群後想成為第三個容器運作時

抽象一套條POD級别的容器接口,解耦Kubelet與容器運作時

定義通過gRPC協定通訊,gRPC在當時剛剛開源,gRPC性能優于http/REST模式

 CRI的設計

Kubernetes必備知識: 容器接口CRI
Kubernetes必備知識: 容器接口CRI
Kubernetes必備知識: 容器接口CRI

 CRIstreaming接口

Kubernetes必備知識: 容器接口CRI

 CRI的實作

1.CRI-containerd

基于containerd實作,有獨立程序演進為位插件

Kubernetes必備知識: 容器接口CRI

2.CRI-O

直接在OCI上包裝接口、同時實作對鏡像存儲的管理

Kubernetes必備知識: 容器接口CRI

 cri-tools相關工具

crictl:類docker的指令行工具,幫助使用者和開發者調試容器問題

critest:用于驗證CRI接口的測試工具,驗證是否滿足Kubelet要求

性能工具:測試接口性能

 生命周期管理

對于Pod和容器的生命周期管理,CRI提供了下面的機制:

service RuntimeService {

// Sandbox operations.

rpc RunPodSandbox(RunPodSandboxRequest) returns (RunPodSandboxResponse) {}

rpc StopPodSandbox(StopPodSandboxRequest) returns (StopPodSandboxResponse) {}

rpc RemovePodSandbox(RemovePodSandboxRequest) returns (RemovePodSandboxResponse) {}

rpc PodSandboxStatus(PodSandboxStatusRequest) returns (PodSandboxStatusResponse) {}

rpc ListPodSandbox(ListPodSandboxRequest) returns (ListPodSandboxResponse) {}

// Container operations.

rpc CreateContainer(CreateContainerRequest) returns (CreateContainerResponse) {}

rpc StartContainer(StartContainerRequest) returns (StartContainerResponse) {}

rpc StopContainer(StopContainerRequest) returns (StopContainerResponse) {}

rpc RemoveContainer(RemoveContainerRequest) returns (RemoveContainerResponse) {}

rpc ListContainers(ListContainersRequest) returns (ListContainersResponse) {}

rpc ContainerStatus(ContainerStatusRequest) returns (ContainerStatusResponse) {}

}

在資源受限的隔離環境裡的一組應用容器組成一個Pod。在CRI,這個環境被稱為PodSandbox。我們故意留下一些空間,讓容器運作時根據它們内部不同的原理來産生不同的PodSandbox。對于基于hypervisor的運作時,PodSandbox可能代表的是虛拟機。對于其他的,比如Docker,它可能是Linux命名空間。這個PodSandbox一定遵循着Pod的資源定義。在v1alpha1版API裡,kubelet将建立pod級的cgroup限制下的一組程序,并傳遞給容器運作時,由此實作。

在Pod啟動前,kubelet調用RuntimeService.RunPodSandbox來建立環境,包括為Pod設定網絡(例如:配置設定IP)等。當PodSandbox啟動後,就可以分别建立/啟動/停止/移除獨立的容器。為了删除Pod,kubelet會在停止和移除所有容器前先停止和移除PodSandbox。

Kubelet負責通過RPC來進行容器生命周期的管理,測試容器生命周期鈎子和健康/可讀性檢查,同時為Pod提供重新開機政策。

|資料來源|

名詞定義:

https://www.kubernetes.org.cn/1079.html

技術特點:

繼續閱讀