如何理解容器運行時CRI接口

這篇文章將為大家詳細(xì)講解有關(guān)如何理解容器運行時CRI接口，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關(guān)知識有一定的了解。

首先會為大家介紹 CRI 接口的一個由來和它的設(shè)計；其次會和大家分享目前有哪些 CRI 的實現(xiàn)；最后會給大家介紹一下相關(guān)的工具有哪些。

一、CRI 介紹

在 CRI 出現(xiàn)之前（也就是 Kubernetes v1.5 之前），Docker 作為第一個容器運行時，Kubelet 通過內(nèi)嵌的 dockershim 操作 Docker API 來操作容器，進(jìn)而達(dá)到一個面向終態(tài)的效果。在這之后，又出現(xiàn)了一種新的容器運行時 - rkt，它也想要成為 Kubernetes 支持的一個容器運行時，當(dāng)時它也合到了 Kubelet 的代碼之中。這兩個容器運行時的加入使得 Kubernetes 的代碼越來越復(fù)雜、難以維護(hù)。之后 hyber.sh 加入社區(qū)，也想成為第三個容器運行時。

此時就 有人站出來說，我們能不能對容器運行時的操作抽象出一個接口，將 Kubelet 代碼與具體的容器運行時的實現(xiàn)代碼解耦開，只要實現(xiàn)了這樣一套接口，就能接入到 Kubernetes 的體系中，這就是我們后來見到的 Container Runtime Interface (CRI)。

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

接下來我們介紹一下 CRI 接口的設(shè)計。

二、CRI 實現(xiàn)

CRI 接口

在引入了 CRI 接口之后，Kubelet 的架構(gòu)如上圖所示。

跟容器最相關(guān)的一個 Manager 是 Generic Runtime Manager，就是一個通用的運行時管理器。我們可以看到目前 dockershim 還是存在于 Kubelet 的代碼中的，它是當(dāng)前性能最穩(wěn)定的一個容器運行時的實現(xiàn)。remote 指的就是 CRI 接口。CRI 接口主要包含兩個部分：

• 一個是 CRI Server，即通用的比如說創(chuàng)建、刪除容器這樣的接口；

• 另外一個是流式數(shù)據(jù)的接口 Streaming Server，比如 exec、port-forward 這些流式數(shù)據(jù)的接口。

這里需要注意的是，我們的 CNI（容器網(wǎng)絡(luò)接口）也是在 CRI 進(jìn)行操作的，因為我們在創(chuàng)建 Pod 的時候需要同時創(chuàng)建網(wǎng)絡(luò)資源然后注入到 Pod 中。接下來就是我們的容器和鏡像。我們通過具體的容器創(chuàng)建引擎來創(chuàng)建一個具體的容器。

給大家介紹一下 CRI 接口的設(shè)計。我們知道 Kubernetes 的一個運作的機(jī)制是面向終態(tài)的，在每一次調(diào)協(xié)的循環(huán)中，Kubelet 會向 apiserver 獲取調(diào)度到本 Node 的 Pod 的數(shù)據(jù)，再做一個面向終態(tài)的處理，以達(dá)到我們預(yù)期的狀態(tài)。

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

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

比方說我們通過 kubectl 命令來運行一個 Pod，那么 Kubelet 就會通過 CRI 執(zhí)行以下操作：

• 首先調(diào)用 RunPodSandbox 接口來創(chuàng)建一個 Pod 容器，Pod 容器是用來持有容器的相關(guān)資源的，比如說網(wǎng)絡(luò)空間、PID空間、進(jìn)程空間等資源；

• 然后調(diào)用 CreatContainer 接口在 Pod 容器的空間創(chuàng)建業(yè)務(wù)容器；

• 再調(diào)用 StartContainer 接口啟動容器，相對應(yīng)的銷毀容器的接口為 StopContainer 與 RemoveContainer。

CRI streaming 接口

這里給大家介紹一下 CRI 的流式接口 exec。它可以用來在容器內(nèi)部執(zhí)行一個命令，又或者說可以 attach 到容器的 IO 流中做各種交互式的命令。它的特別之處在于，一個是節(jié)省資源，另一個是連接的可靠性。

首先 exec 操作會發(fā)送到 apiserver，經(jīng)過鑒權(quán)，apiserver 將對 Kubelet Server 發(fā)起 exec 的請求，然后 Kubelet 會調(diào)用 CRI 的 exec 接口將具體的請求發(fā)至容器的運行時。這個時候，容器運行時不是直接地在 exec 接口上來服務(wù)這次請求，而是通過我們的 streaming server 來異步地返回每一次執(zhí)行的結(jié)果。也就是說 apiserver 其實實際上是跟 streaming server 交互來獲取我們的流式數(shù)據(jù)的。這樣一來讓我們的整個 CRI Server 接口更輕量、更可靠。

CRI 的一些實現(xiàn)

目前 CRI 的一些實現(xiàn)：

• CRI-containerd

• CRI-O

• PouchContainer @alibaba

• …

CRI-containerd 是目前社區(qū)中比較主流的新一代 CRI 的實現(xiàn)，CRI-O 來自于紅帽公司，PouchContainer 是由 alibaba 實現(xiàn)的 CRI，其它的 CRI 實現(xiàn)，這里就不一一介紹了。

CRI-containerd

下圖是 CRI-containerd 的架構(gòu)。

這套 CRI 接口是基于 containerd 實現(xiàn)的。在早期的實現(xiàn)中，CRI 其實是作為一個獨立進(jìn)程的，再跟 containerd 進(jìn)行交互。這樣一來又多了一層進(jìn)程跟進(jìn)程之間的開銷，因此在后來的版本中 CRI 的是直接以插件的形式實現(xiàn)到 containerd 中的，成為了 containerd 的一部分，從而能夠可插拔地使用 CRI 接口。

整個架構(gòu)看起來非常直觀。這里的 Meta services、Runtime service 與 Storage service 都是 containerd 提供的接口。它們是通用的容器相關(guān)的接口，包括鏡像管理、容器運行時管理等。CRI 在這之上包裝了一個 gRPC 的服務(wù)。右側(cè)就是具體的容器的實現(xiàn)，比如說，創(chuàng)建容器時就要創(chuàng)建具體的 runtime 和它的 shim，它們和 Container 一起組成了一個 Pod Sandbox。

CRI-containerd 的一個好處是，containerd 還額外實現(xiàn)了更豐富的容器接口，所以它可以用 containerd 提供的 ctr 工具來調(diào)用這些豐富的容器運行時接口，而不只是 CRI 接口。

CRI-O

下圖是 CRI-O 的實現(xiàn)思路。

它是通過直接在 OCI 上包裝容器接口來實現(xiàn)的一個 CRI 服務(wù)。它對外提供的只有具體的 CRI 接口，沒有我們前面所提到的 containerd 提供的更豐富的接口。它主要包含兩個部分，首先是對容器 runtime 的管理，另一個是對鏡像的管理。

三、相關(guān)工具

下面給大家介紹一下 CRI 相關(guān)的工具。這幾個工具都在特別興趣小組的一個 項目里面。

• crictl

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

• critest

用于驗證 CRI 接口行為是否是符合預(yù)期的。

• 性能工具

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

四、思考時間

1. 目前 CRI 接口處于 v1 alpha2 版本，CRI 規(guī)范能不能更完善？

CRI 標(biāo)準(zhǔn)的制定是至上而下的，通過 Kubernetes 的一些 feature 反向地要求 CRI 提供這樣的功能，進(jìn)而完善 CRI 規(guī)范。

1. 如何通過 annotation 方式自定義 runtime 行為？

我們目前的 CRI 肯定不能滿足所有用戶的需求，很多公司可能會對 CRI 接口做一些增強(qiáng)、定制，比如說 alibaba。最簡單的方式是通過 annotation 來自定義 runtime 的行為。在每個接口都設(shè)置一個 annotation 的字段，容器運行時通過理解這些字段來去自定義 runtime 的行為。同學(xué)們可以嘗試去在各個 CRI 接口中通過識別 annotation 的方式來達(dá)到自定義 runtime 行為的目的。

關(guān)于如何理解容器運行時CRI接口就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。