如何理解容器運行時CRI接口

這篇文章將為大家詳細講解有關如何理解容器運行時CRI接口，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

首先會為大家介紹 CRI 接口的一個由來和它的設計；其次會和大家分享目前有哪些 CRI 的實現；最后會給大家介紹一下相關的工具有哪些。

一、CRI 介紹

在 CRI 出現之前（也就是 Kubernetes v1.5 之前），Docker 作為第一個容器運行時，Kubelet 通過內嵌的 dockershim 操作 Docker API 來操作容器，進而達到一個面向終態的效果。在這之后，又出現了一種新的容器運行時 - rkt，它也想要成為 Kubernetes 支持的一個容器運行時，當時它也合到了 Kubelet 的代碼之中。這兩個容器運行時的加入使得 Kubernetes 的代碼越來越復雜、難以維護。之后 hyber.sh 加入社區，也想成為第三個容器運行時。

此時就 有人站出來說，我們能不能對容器運行時的操作抽象出一個接口，將 Kubelet 代碼與具體的容器運行時的實現代碼解耦開，只要實現了這樣一套接口，就能接入到 Kubernetes 的體系中，這就是我們后來見到的 Container Runtime Interface (CRI)。

有一句話說得很好，「軟件問題都可以通過加一層來解決」，我們的 CRI 就是加了這樣一層。CRI 接口的通信協議是 gRPC，這里的一個時代背景就是當時的 gRPC 剛剛開源，此外它的性能也是優于 http/REST 模式的。gRPC 不需要手寫客戶端代碼和服務端代碼，能夠自動生成通信協議代碼。

接下來我們介紹一下 CRI 接口的設計。

二、CRI 實現

CRI 接口

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

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

• 一個是 CRI Server，即通用的比如說創建、刪除容器這樣的接口；

• 另外一個是流式數據的接口 Streaming Server，比如 exec、port-forward 這些流式數據的接口。

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

給大家介紹一下 CRI 接口的設計。我們知道 Kubernetes 的一個運作的機制是面向終態的，在每一次調協的循環中，Kubelet 會向 apiserver 獲取調度到本 Node 的 Pod 的數據，再做一個面向終態的處理，以達到我們預期的狀態。

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

通過 CRI 操作容器的生命周期

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

• 首先調用 RunPodSandbox 接口來創建一個 Pod 容器，Pod 容器是用來持有容器的相關資源的，比如說網絡空間、PID空間、進程空間等資源；

• 然后調用 CreatContainer 接口在 Pod 容器的空間創建業務容器；

• 再調用 StartContainer 接口啟動容器，相對應的銷毀容器的接口為 StopContainer 與 RemoveContainer。

CRI streaming 接口

這里給大家介紹一下 CRI 的流式接口 exec。它可以用來在容器內部執行一個命令，又或者說可以 attach 到容器的 IO 流中做各種交互式的命令。它的特別之處在于，一個是節省資源，另一個是連接的可靠性。

首先 exec 操作會發送到 apiserver，經過鑒權，apiserver 將對 Kubelet Server 發起 exec 的請求，然后 Kubelet 會調用 CRI 的 exec 接口將具體的請求發至容器的運行時。這個時候，容器運行時不是直接地在 exec 接口上來服務這次請求，而是通過我們的 streaming server 來異步地返回每一次執行的結果。也就是說 apiserver 其實實際上是跟 streaming server 交互來獲取我們的流式數據的。這樣一來讓我們的整個 CRI Server 接口更輕量、更可靠。

CRI 的一些實現

目前 CRI 的一些實現：

• CRI-containerd

• CRI-O

• PouchContainer @alibaba

• …

CRI-containerd 是目前社區中比較主流的新一代 CRI 的實現，CRI-O 來自于紅帽公司，PouchContainer 是由 alibaba 實現的 CRI，其它的 CRI 實現，這里就不一一介紹了。

CRI-containerd

下圖是 CRI-containerd 的架構。

這套 CRI 接口是基于 containerd 實現的。在早期的實現中，CRI 其實是作為一個獨立進程的，再跟 containerd 進行交互。這樣一來又多了一層進程跟進程之間的開銷，因此在后來的版本中 CRI 的是直接以插件的形式實現到 containerd 中的，成為了 containerd 的一部分，從而能夠可插拔地使用 CRI 接口。

整個架構看起來非常直觀。這里的 Meta services、Runtime service 與 Storage service 都是 containerd 提供的接口。它們是通用的容器相關的接口，包括鏡像管理、容器運行時管理等。CRI 在這之上包裝了一個 gRPC 的服務。右側就是具體的容器的實現，比如說，創建容器時就要創建具體的 runtime 和它的 shim，它們和 Container 一起組成了一個 Pod Sandbox。

CRI-containerd 的一個好處是，containerd 還額外實現了更豐富的容器接口，所以它可以用 containerd 提供的 ctr 工具來調用這些豐富的容器運行時接口，而不只是 CRI 接口。

CRI-O

下圖是 CRI-O 的實現思路。

它是通過直接在 OCI 上包裝容器接口來實現的一個 CRI 服務。它對外提供的只有具體的 CRI 接口，沒有我們前面所提到的 containerd 提供的更豐富的接口。它主要包含兩個部分，首先是對容器 runtime 的管理，另一個是對鏡像的管理。

三、相關工具

下面給大家介紹一下 CRI 相關的工具。這幾個工具都在特別興趣小組的一個 項目里面。

• crictl

它是一個類似 docker 的命令行工具，用來操作 CRI 接口。它能夠幫助用戶和開發者調試容器問題，而不是通過 apply 一個 yaml 到 apiserver、再通過 Kubelet 操作的方式來調試。這樣的鏈路太長，而這個命令行工具可以直接操作 CRI。

• critest

用于驗證 CRI 接口行為是否是符合預期的。

• 性能工具

還有一些性能工具用來測試接口性能。

四、思考時間

1. 目前 CRI 接口處于 v1 alpha2 版本，CRI 規范能不能更完善？

CRI 標準的制定是至上而下的，通過 Kubernetes 的一些 feature 反向地要求 CRI 提供這樣的功能，進而完善 CRI 規范。

1. 如何通過 annotation 方式自定義 runtime 行為？

我們目前的 CRI 肯定不能滿足所有用戶的需求，很多公司可能會對 CRI 接口做一些增強、定制，比如說 alibaba。最簡單的方式是通過 annotation 來自定義 runtime 的行為。在每個接口都設置一個 annotation 的字段，容器運行時通過理解這些字段來去自定義 runtime 的行為。同學們可以嘗試去在各個 CRI 接口中通過識別 annotation 的方式來達到自定義 runtime 行為的目的。

關于如何理解容器運行時CRI接口就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。