作者 | 知謹 阿里雲工程師
本文整理自《CNCF x Alibaba 雲原生技術公開課》第 28 講，點擊直達課程頁面。
關注“阿里巴巴雲原生”公衆號，回覆關鍵詞**“入門”**，即可下載從零入門 K8s 系列文章 PPT。
導讀：CRI 是 Kubernetes 體系中跟容器打交道的一個非常重要的部分。本文作者主要分爲三個部分來進行：首先會爲大家介紹 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 接口行爲是否是符合預期的。
- 性能工具
還有一些性能工具用來測試接口性能。
四、思考時間
- 目前 CRI 接口處於 v1 alpha2 版本，CRI 規範能不能更完善？
CRI 標準的制定是至上而下的，通過 Kubernetes 的一些 feature 反向地要求 CRI 提供這樣的功能，進而完善 CRI 規範。
- 如何通過 annotation 方式自定義 runtime 行爲？
我們目前的 CRI 肯定不能滿足所有用戶的需求，很多公司可能會對 CRI 接口做一些增強、定製，比如說 alibaba。最簡單的方式是通過 annotation 來自定義 runtime 的行爲。在每個接口都設置一個 annotation 的字段，容器運行時通過理解這些字段來去自定義 runtime 的行爲。同學們可以嘗試去在各個 CRI 接口中通過識別 annotation 的方式來達到自定義 runtime 行爲的目的。
五、本節總結
本節課的主要內容就到此爲止了，這裏爲大家簡單總結一下：
- CRI 介紹：CRI 的出現是爲了將容器運行時與 Kubernetes 解耦開；
- CRI 實現：CRI-O 與 CRI-containerd；
- CRI 工具：CRI 調試工具 cri-tools, CRI 測試工具 critest。
“阿里巴巴雲原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公衆號。”