Categories
程式開發

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


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)。

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

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

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

二、CRI 實現

CRI 接口

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

CRI streaming 接口

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

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

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

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

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

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

它是通過直接在 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 介紹:CRI 的出現是為了將容器運行時與 Kubernetes 解耦開;

  • CRI 實現:CRI-O 與 CRI-containerd;

  • CRI 工具:CRI 調試工具 cri-tools, CRI 測試工具 critest。

本文轉載自阿里巴巴雲原生微信公眾號(ID:Alicloudnative)。

相關閱讀:

從零開始入門 K8s:理解 CNI 和 CNI 插件

從零開始入門 K8s:Kubernetes 網絡模型進階

從零開始入門 K8s:Kubernetes API 編程範式

從零開始入門 K8s:Kubernetes API 編程利器 Operator 和 Operator Framework

從零開始入門 K8s:有狀態應用編排 – StatefulSet

從零開始入門 K8s:Kubernetes 存儲架構及插件使用

從零開始入門 K8s:GPU 管理和 Device Plugin 工作機制

從零開始入門 K8s:調度器的調度流程和算法介紹

從零開始入門 K8s:Kubernetes 調度和資源管理

從零開始入門 K8s:etcd 性能優化實踐

從零開始入門 K8s:手把手帶你理解 etcd

從零開始入門 K8s:深入剖析 Linux 容器

從零開始入門 K8s:Kubernetes 中的服務發現與負載均衡

從零開始入門 K8s:Kubernetes 網絡概念及策略控制

從零開始入門 K8s:監控與日誌的可觀測性

從零開始入門 K8s:應用存儲和持久化數據卷:存儲快照與拓撲調度

從零開始入門 K8s:應用存儲和持久化數據卷的核心知識

從零開始入門 K8s:應用配置管理

從零開始入門 K8s:應用編排與管理:Job & DaemonSet

從零開始入門 K8s:應用編排與管理

從零開始入門 K8s:K8s 的應用編排與管理

從零開始入門 K8s:詳解 Pod 及容器設計模式

從零開始入門 K8s:詳解 K8s 容器基本概念

從零開始入門 K8s:詳解 K8s 核心概念