Container Runtime Interface(CRI)

Container Runtime Interface(CRI)是Kubernetes與容器運行時交互的接口。

在 CRI 出現(xiàn)之前（Kubernetes v1.5 之前），Docker 作為第一個容器運行時，Kubelet 通過內(nèi)嵌的 dockershim 操作 Docker API 來操作容器，達到一個面向終態(tài)的效果。在這之后，又出現(xiàn)了一種新的容器運行時rkt，它也想要被Kubernetes支持，當(dāng)時它也合到了 Kubelet 的代碼之中。但越來越多的容器運行時出現(xiàn)，采用這種方式會使得Kubernetes的代碼越來越復(fù)雜、難以維護。

因此將 Kubelet 代碼與具體的容器運行時的實現(xiàn)代碼解耦開，只要實現(xiàn)了這樣一套接口，就能接入到 Kubernetes 的體系中，于是就有了Container Runtime Interface (CRI)。

CRI接口的通信協(xié)議是 gRPC，它的性能優(yōu)于 http/REST 模式。gRPC 不需要手寫客戶端代碼和服務(wù)端代碼，能夠自動生成通信協(xié)議代碼。

在引入了 CRI 接口之后，Kubelet 的架構(gòu)如上圖所示。

跟容器最相關(guān)的一個 Manager 是 Generic Runtime Manager，就是一個通用的運行時管理器。我們可以看到目前dockershim還是存在于 Kubelet 的代碼中的，它是當(dāng)前性能最穩(wěn)定的一個容器運行時的實現(xiàn)。remote 指的就是 CRI 接口。CRI 接口主要包含兩個部分：

• 一個是 CRI Server，即通用的比如說創(chuàng)建、刪除容器這樣的接口；
• 另外一個是流式數(shù)據(jù)的接口 Streaming Server，比如 exec、port-forward 這些流式數(shù)據(jù)的接口。

這里需要注意的是，我們的 CNI（容器網(wǎng)絡(luò)接口）也是在 CRI 進行操作的，因為我們在創(chuàng)建 Pod 的時候需要同時創(chuàng)建網(wǎng)絡(luò)資源然后注入到 Pod 中。接下來就是我們的容器和鏡像。我們通過具體的容器引擎來創(chuàng)建一個具體的容器。

給大家介紹一下 CRI 接口的設(shè)計。我們知道 Kubernetes 的一個運作的機制是面向終態(tài)的，在每一次調(diào)協(xié)的循環(huán)中，Kubelet 會向 apiserver 獲取調(diào)度到本 Node 的 Pod 的數(shù)據(jù)，再做一個面向終態(tài)的處理，以達到我們預(yù)期的狀態(tài)。

循環(huán)的第一步，首先通過 List 接口拿到容器的狀態(tài)，再通過 Sandbox 和 Container 接口來創(chuàng)建容器，另外還有鏡像接口用來拉取容器鏡像。CRI 描述了 Kubelet 期望的容器運行時行為，主要就是我們剛剛所說的 3 個部分。

比方說我們通過 kubectl 命令來運行一個 Pod，那么 Kubelet 就會通過 CRI 執(zhí)行以下操作：

• 首先調(diào)用 RunPodSandbox 接口來創(chuàng)建一個 Pod 容器，Pod 容器是用來持有容器的相關(guān)資源的，比如說網(wǎng)絡(luò)空間、PID空間、進程空間等資源；
• 然后調(diào)用 CreatContainer 接口在 Pod 容器的空間創(chuàng)建業(yè)務(wù)容器；
• 再調(diào)用 StartContainer 接口啟動容器，相對應(yīng)的銷毀容器的接口為 StopContainer 與 RemoveContainer。