![0.png](https://ucc.alicdn.com/pic/developer-ecology/7ab546a5e3874cffa691c08d785baf05.png)

作者 | 知謹   阿里雲工程師

本文整理自《CNCF x Alibaba 雲原生技術公開課》第 28 講，[點選直達課程頁面](https://edu.aliyun.com/roadmap/cloudnative)。

關注“阿里巴巴雲原生”公眾號，回覆關鍵詞**“入門”**，即可下載從零入門 K8s 系列文章 PPT。

**導讀**：CRI 是 Kubernetes 體系中跟容器打交道的一個非常重要的部分。本文作者主要分為三個部分來進行：首先會為大家介紹 CRI 介面的一個由來和它的設計；其次會和大家分享目前有哪些 CRI 的實現；最後會給大家介紹一下相關的工具有哪些。

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

此時就[有人站出來說](https://github.com/kubernetes/kubernetes/issues/13768)，我們能不能對容器執行時的操作抽象出一個介面，將 Kubelet 程式碼與具體的容器執行時的實現程式碼解耦開，只要實現了這樣一套介面，就能接入到 Kubernetes 的體系中，這就是我們後來見到的 Container Runtime Interface (CRI)。

![1.png](https://ucc.alicdn.com/pic/developer-ecology/ffaa913b9d664037a0d66642eee375a7.png)

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

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

# 二、CRI 實現

## CRI 介面

![2.png](https://ucc.alicdn.com/pic/developer-ecology/5df609b50f6841bd856fb0124db0b99e.png)

在引入了 CRI 介面之後，Kubelet 的架構如上圖所示。

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

- 一個是 CRI Server，即通用的比如說建立、刪除容器這樣的介面；
- 另外一個是流式資料的介面 Streaming Server，比如 exec、port-forward 這些流式資料的介面。

這裡需要注意的是，我們的 CNI（容器網路介面）也是在 CRI 進行操作的，因為我們在建立 Pod 的時候需要同時建立網路資源然後注入到 Pod 中。接下來就是我們的容器和映象。我們透過具體的容器建立引擎來建立一個具體的容器。

![3.png](https://ucc.alicdn.com/pic/developer-ecology/2f80e46334f64649b8042899af349229.png)

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

迴圈的第一步，首先透過 List 介面拿到容器的狀態，再透過 Sandbox 和 Container 介面來建立容器，另外還有映象介面用來拉取容器映象。CRI 描述了 Kubelet 期望的容器執行時行為，主要就是我們剛剛所說的 3 個部分。

## 透過 CRI 操作容器的生命週期

![4.png](https://ucc.alicdn.com/pic/developer-ecology/7039cd18ad744aada68a1735838aa6d8.png)

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

- 首先呼叫 RunPodSandbox 介面來建立一個 Pod 容器，Pod 容器是用來持有容器的相關資源的，比如說網路空間、PID空間、程式空間等資源；
- 然後呼叫 CreatContainer 介面在 Pod 容器的空間建立業務容器；
- 再呼叫 StartContainer 介面啟動容器，相對應的銷燬容器的介面為 StopContainer 與 RemoveContainer。

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

![5.png](https://ucc.alicdn.com/pic/developer-ecology/0a964fd3282c4c8696ba7f153250fc0a.png)

首先 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 的架構。

![6.png](https://ucc.alicdn.com/pic/developer-ecology/f3ae28f91d964cdb892d362317326567.png)

這套 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 的實現思路。

![7.png](https://ucc.alicdn.com/pic/developer-ecology/25f8d7f316b44cb6a4853d1d068e6fea.png)

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

# 三、相關工具
下面給大家介紹一下 CRI 相關的工具。這幾個工具都在特別興趣小組的一個[專案](https://github.com/kubernetes-sigs/cri-tools)裡面。

- crictl

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

- critest

用於驗證 CRI 介面行為是否是符合預期的。

- 效能工具

還有一些效能工具用來測試介面效能。

# 四、思考時間

1. 目前 CRI 介面處於 v1 alpha2 版本，CRI 規範能不能更完善？

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

2. 如何透過 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。

![3 群直播海報.png](https://ucc.alicdn.com/pic/developer-ecology/813c4f6aa95d4656a3fab7d85c2dc261.png)

> “[阿里巴巴雲原生](https://mp.weixin.qq.com/s/aexS9HmlxCpmY7gn3MIFsA)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公眾號。”

從零開始入門 K8s | 理解容器執行時介面 CRI

相關文章