從零開始入門 K8s | 理解容器運行時接口 CRI

做者 | 知謹   阿里雲工程師

本文整理自《CNCF x Alibaba 雲原生技術公開課》第 28 講，點擊直達課程頁面。

關注「阿里巴巴雲原生」公衆號，回覆關鍵詞**「入門」**，便可下載從零入門 K8s 系列文章 PPT。

導讀：CRI 是 Kubernetes 體系中跟容器打交道的一個很是重要的部分。本文做者主要分爲三個部分來進行：首先會爲你們介紹 CRI 接口的一個由來和它的設計；其次會和你們分享目前有哪些 CRI 的實現；最後會給你們介紹一下相關的工具備哪些。

1、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 接口的設計。

2、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 的管理，另外一個是對鏡像的管理。

3、相關工具

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

• crictl

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

• critest

用於驗證 CRI 接口行爲是不是符合預期的。

• 性能工具

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

4、思考時間

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

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

2. 如何經過 annotation 方式自定義 runtime 行爲？

咱們目前的 CRI 確定不能知足全部用戶的需求，不少公司可能會對 CRI 接口作一些加強、定製，好比說 alibaba。最簡單的方式是經過 annotation 來自定義 runtime 的行爲。在每一個接口都設置一個 annotation 的字段，容器運行時經過理解這些字段來去自定義 runtime 的行爲。同窗們能夠嘗試去在各個 CRI 接口中經過識別 annotation 的方式來達到自定義 runtime 行爲的目的。

5、本節總結

本節課的主要內容就到此爲止了，這裏爲你們簡單總結一下：

• CRI 介紹：CRI 的出現是爲了將容器運行時與 Kubernetes 解耦開；
• CRI 實現：CRI-O 與 CRI-containerd；
• CRI 工具：CRI 調試工具 cri-tools, CRI 測試工具 critest。

「阿里巴巴雲原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，作最懂雲原生開發者的公衆號。」