雲栖号資訊：【 點選檢視更多行業資訊】
在這裡您可以找到不同行業的第一手的上雲資訊，還在等什麼，快來！
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 中的，成為了 containerd 的一部分，進而能夠可插拔地使用 CRI 接口。
整個架構看起來非常直覺。這裡的 Meta services、Runtime service 與 Storage service 都是 containerd 提供的接口。它們是通用的容器相關的接口，包括鏡像管理、容器運作時管理等。CRI 在這之上包裝了一個 gRPC 的服務。右側就是具體的容器的實作，比如說，建立容器時就要建立具體的 runtime 和它的 shim，它們和 Container 一起組成了一個 Pod Sandbox。
CRI-containerd 的一個好處是，containerd 還額外實作了更豐富的容器接口，是以它可以用 containerd 提供的 ctr 工具來調用這些豐富的容器運作時接口，而不隻是 CRI 接口。
下圖是 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 規範。
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。
【雲栖号線上課堂】每天都有産品技術專家分享！
課程位址：
https://yqh.aliyun.com/zhibo立即加入社群，與專家面對面，及時了解課程最新動态！
【雲栖号線上課堂 社群】
https://c.tb.cn/F3.Z8gvnK
原文釋出時間：2020-03-29
本文作者：知謹
本文來自：“
InfoQ”，了解相關資訊可以關注“
”