作者 | 知謹(jǐn)? ?阿里云工程師

本文整理自《CNCF x Alibaba 云原生技術(shù)公開(kāi)課》第 28 講，點(diǎn)擊直達(dá)課程頁(yè)面。

關(guān)注“阿里巴巴云原生”公眾號(hào)，回復(fù)關(guān)鍵詞“入門(mén)”，即可下載從零入門(mén) K8s 系列文章 PPT。

導(dǎo)讀：CRI 是 Kubernetes 體系中跟容器打交道的一個(gè)非常重要的部分。本文作者主要分為三個(gè)部分來(lái)進(jìn)行：首先會(huì)為大家介紹 CRI 接口的一個(gè)由來(lái)和它的設(shè)計(jì)；其次會(huì)和大家分享目前有哪些 CRI 的實(shí)現(xiàn)；最后會(huì)給大家介紹一下相關(guān)的工具有哪些。

一、CRI 介紹

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

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

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

接下來(lái)我們介紹一下 CRI 接口的設(shè)計(jì)。

二、CRI 實(shí)現(xiàn)

CRI 接口

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

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

一個(gè)是 CRI Server，即通用的比如說(shuō)創(chuàng)建、刪除容器這樣的接口；
另外一個(gè)是流式數(shù)據(jù)的接口 Streaming Server，比如 exec、port-forward 這些流式數(shù)據(jù)的接口。

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

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

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

通過(guò) CRI 操作容器的生命周期

比方說(shuō)我們通過(guò) kubectl 命令來(lái)運(yùn)行一個(gè) Pod，那么 Kubelet 就會(huì)通過(guò) CRI 執(zhí)行以下操作：

首先調(diào)用 RunPodSandbox 接口來(lái)創(chuàng)建一個(gè) Pod 容器，Pod 容器是用來(lái)持有容器的相關(guān)資源的，比如說(shuō)網(wǎng)絡(luò)空間、PID空間、進(jìn)程空間等資源；
然后調(diào)用 CreatContainer 接口在 Pod 容器的空間創(chuàng)建業(yè)務(wù)容器；
再調(diào)用 StartContainer 接口啟動(dòng)容器，相對(duì)應(yīng)的銷(xiāo)毀容器的接口為 StopContainer 與 RemoveContainer。

CRI streaming 接口

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

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

CRI 的一些實(shí)現(xiàn)

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

CRI-containerd
CRI-O
PouchContainer @alibaba
...

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

CRI-containerd

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

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

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

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

CRI-O

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

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

三、相關(guān)工具

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

crictl

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

critest

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

性能工具

還有一些性能工具用來(lái)測(cè)試接口性能。

四、思考時(shí)間

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

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

如何通過(guò) annotation 方式自定義 runtime 行為？

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

五、本節(jié)總結(jié)

本節(jié)課的主要內(nèi)容就到此為止了，這里為大家簡(jiǎn)單總結(jié)一下：

CRI 介紹：CRI 的出現(xiàn)是為了將容器運(yùn)行時(shí)與 Kubernetes 解耦開(kāi)；
CRI 實(shí)現(xiàn)：CRI-O 與 CRI-containerd；
CRI 工具：CRI 調(diào)試工具 cri-tools, CRI 測(cè)試工具 critest。

“阿里巴巴云原生關(guān)注微服務(wù)、Serverless、容器、Service Mesh 等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢(shì)、云原生大規(guī)模的落地實(shí)踐，做最懂云原生開(kāi)發(fā)者的公眾號(hào)。”

總結(jié)

以上是生活随笔為你收集整理的从零开始入门 K8s | 理解容器运行时接口 CRI的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。