好久沒(méi)發(fā)文了，最近這段時(shí)間都在學(xué) K8S。不知道大家是不是和咸魚一樣，剛開(kāi)始學(xué) K8S 的時(shí)候，往往被 CRI、OCI、CRI shim、containerd 這些名稱搞得暈乎乎的，不清楚它們到底是干什么用的。所以今天，咸魚打算借這篇文章來(lái)解釋一下這些名稱，幫助大家理清它們的關(guān)系。

我們以 K8S 創(chuàng)建容器的過(guò)程為例，來(lái)引申出各個(gè)概念。

K8S 如何創(chuàng)建容器？

下面這張圖，就是經(jīng)典的 K8S 創(chuàng)建容器的步驟，可以說(shuō)是冗長(zhǎng)復(fù)雜，至于為什么設(shè)計(jì)成這樣的架構(gòu)，繼續(xù)往下讀。

圖片

前半部分

CRI（Container Runtime Interface，容器運(yùn)行時(shí)接口）

在 K8S 中，真正負(fù)責(zé)創(chuàng)建容器運(yùn)行時(shí)的是 kubelet 這個(gè)組件。

當(dāng) kubelet 對(duì)容器運(yùn)行時(shí)進(jìn)行操作時(shí)，并不會(huì)直接調(diào)用 Docker 的 API，而是通過(guò)一組叫作 CRI 的 gRPC 接口來(lái)間接執(zhí)行的。

其實(shí)對(duì)于 1.6 版本之前的 K8S 來(lái)講，kubelet 是直接與 Docker 的 API 交互的，為什么要單獨(dú)多出這一層抽象，其實(shí)是商戰(zhàn)的結(jié)果。

當(dāng)時(shí)，Docker 風(fēng)靡全球，許多公司都希望能在這一領(lǐng)域分一杯羹，紛紛推出了自家的容器運(yùn)行時(shí)。其中最著名的要屬 CoreOS 公司的 rkt 項(xiàng)目。雖然 Docker 是 K8S 最依賴的容器運(yùn)行時(shí)，但憑借與 Google 的特殊關(guān)系，CoreOS 公司在 2016 年成功地將對(duì) rkt 容器的支持寫進(jìn)了 kubelet 的主代碼里。

這下把專門維護(hù) kubelet 的小組 sig-node 坑慘了。因?yàn)樵谶@種情況下，kubelet 的任何重要功能更新都必須同時(shí)考慮 Docker 和 rkt 這兩種容器運(yùn)行時(shí)的處理場(chǎng)景，并分別更新 Docker 和 rkt 的代碼。

更麻煩的是，由于 rkt 比較小眾，每次修改 rkt 代碼都必須依賴 CoreOS 公司的員工。這不僅降低了開(kāi)發(fā)效率，還給項(xiàng)目的穩(wěn)定性帶來(lái)了極大的隱患。

sig-node 一看這可不行，今天出個(gè) rkt，明天出個(gè) xxx，這下我們組也不用干活了，每天使勁折騰兼容性得了。所以把 kubelet 對(duì)容器運(yùn)行時(shí)的操作統(tǒng)一抽象成了一個(gè) gRPC 接口，然后告訴大家，你們想做容器運(yùn)行時(shí)可以啊，我熱烈歡迎，但是前提是必須用我這個(gè)接口。

這一層統(tǒng)一的容器操作接口，就是 CRI ，這樣 kubelet 就只需要跟這個(gè)接口打交道就可以了。而作為具體的容器項(xiàng)目，比如 Docker、 rkt，它們就只需要自己提供一個(gè)該接口的實(shí)現(xiàn)，然后對(duì) kubelet 暴露出 gRPC 服務(wù)即可。

下面這幅圖展示了 CRI 里主要的接口：

圖片

可以簡(jiǎn)單把 CRI 分為兩組：

1. 第一組，是 RuntimeService。它提供的接口，主要是跟容器相關(guān)的操作。比如，創(chuàng)建和啟動(dòng)容器、刪除容器、執(zhí)行 exec 命令等等。
2. 而第二組，則是 ImageService。它提供的接口，主要是容器鏡像相關(guān)的操作，比如拉取鏡像、刪除鏡像等等。

CRI shim

但是說(shuō)到底 CRI 只是 K8S 推出的一個(gè)標(biāo)準(zhǔn)而已，當(dāng)時(shí)的 K8S 還沒(méi)有達(dá)到如今這般武林盟主的統(tǒng)治地位，各家公司的容器項(xiàng)目也不能說(shuō)我只跟 K8S 綁死，只適配 CRI 接口。所以， shim （墊片）就誕生了。

一個(gè) shim 的工作就是就是作為適配器將各種容器運(yùn)行時(shí)本身的接口適配到 K8S 的 CRI 接口上，以便用來(lái)響應(yīng) kubelet 發(fā)起的 CRI 請(qǐng)求。

每一個(gè)容器運(yùn)行時(shí)都可以自己實(shí)現(xiàn)一個(gè) CRI shim，用來(lái)把 CRI 請(qǐng)求 “翻譯”成自家容器運(yùn)行時(shí)能夠聽(tīng)懂的請(qǐng)求。

圖片

如果你用 Docekr 作為容器運(yùn)行時(shí)，那你的 CRI shim 就是 dockershim，因?yàn)楫?dāng)時(shí) Docker 的江湖地位很高，kubelet 是直接集成了 dockershim 的，所以 K8S 創(chuàng)建容器的前半部分如下圖紅框所示：

圖片

后半部分

當(dāng) dockershim 收到 CRI 請(qǐng)求之后，它會(huì)把里面的內(nèi)容拿出來(lái)，然后組裝成 Docker API 請(qǐng)求發(fā)送給 Docker daemon。

請(qǐng)求到了 Docker daemon 之后就是 Docker 創(chuàng)建容器的流程了。

圖片

從 Docker 1.11 版本開(kāi)始，Docker 容器就不再是通過(guò)簡(jiǎn)單的 Docker Daemon 來(lái)啟動(dòng)了，而是通過(guò)一個(gè)守護(hù)進(jìn)程 containerd 來(lái)完成的，因此 Docker Daemon 仍然不能幫我們創(chuàng)建容器，而是要請(qǐng)求 containerd 創(chuàng)建一個(gè)容器。

圖片

containerd  收到請(qǐng)求之后也并不會(huì)直接去操作容器，而是創(chuàng)建一個(gè)叫 containerd-shim 的進(jìn)程來(lái)處理，這是因?yàn)槿萜餍枰粋€(gè)父進(jìn)程來(lái)做狀態(tài)收集、維持 stdin 等 fd 打開(kāi)等工作的。

假如這個(gè)父進(jìn)程就是 containerd，如果 containerd 掛掉的話，整個(gè)宿主機(jī)上所有的容器都得退出了，而引入 containerd-shim 就可以避免這種問(wèn)題。

我在這篇文章《兩個(gè)關(guān)鍵詞帶你了解容器技術(shù)的實(shí)現(xiàn)》里提到過(guò)，容器其實(shí)是宿主機(jī)上的一個(gè)進(jìn)程，只不過(guò)通過(guò) Linux 內(nèi)核的 namespace 和 cgroups 機(jī)制，以及掛載 root 文件系統(tǒng)等操作來(lái)實(shí)現(xiàn)隔離和資源限制。

對(duì)于 namespaces 和 cgroups 的配置，以及掛載 root 文件系統(tǒng)等操作這塊內(nèi)容已經(jīng)有了標(biāo)準(zhǔn)的規(guī)范，那就是 OCI （Open Container Initiative，開(kāi)放容器標(biāo)準(zhǔn)）。

OCI 標(biāo)準(zhǔn)其實(shí)就是一個(gè)文檔，主要規(guī)定了容器鏡像的結(jié)構(gòu)、以及容器需要接收哪些操作指令：

1. 容器鏡像要長(zhǎng)啥樣，即 ImageSpec。里面的大致規(guī)定就是你這個(gè)東西需要是一個(gè)壓縮了的文件夾，文件夾里以 xxx 結(jié)構(gòu)放 xxx 文件；
2. 容器要需要能接收哪些指令，這些指令的行為是什么，即 RuntimeSpec。這里面的大致內(nèi)容就是“容器”要能夠執(zhí)行 create，start，stop，delete這些命令。

OCI 有一個(gè)參考實(shí)現(xiàn)，那就是 runc（Docker 被逼無(wú)耐將 libcontainer 捐獻(xiàn)出來(lái)然后改名為 runc ）。既然是標(biāo)準(zhǔn)肯定就有其他 OCI 實(shí)現(xiàn)，比如 Kata、gVisor 這些容器運(yùn)行時(shí)都是符合 OCI 標(biāo)準(zhǔn)的。

所以實(shí)際上  containerd-shim  通過(guò)調(diào)用 runc 來(lái)創(chuàng)建容器，runc 啟動(dòng)完容器后本身會(huì)直接退出，containerd-shim 則會(huì)成為容器進(jìn)程的父進(jìn)程, 負(fù)責(zé)收集容器進(jìn)程的狀態(tài), 上報(bào)給 containerd, 并在容器中 pid 為 1 的進(jìn)程退出后接管容器中的子進(jìn)程進(jìn)行清理, 確保不會(huì)出現(xiàn)僵尸進(jìn)程。

另一個(gè)容器運(yùn)行時(shí)：containerd

從上面的內(nèi)容我們可以看到，真正容器相關(guān)的操作其實(shí)在 containerd 那一塊，至于前面的 docker shim 和 docker daemon 的操作不但復(fù)雜，而且對(duì) K8S 來(lái)講大部分功能都是用不上的。

所以從 K8S 1.20 版本開(kāi)始，K8S 宣布棄用 Docker，推薦使用 containerd 作為容器運(yùn)行時(shí)。

至于為什么要用 containerd 作為容器運(yùn)行時(shí)，也有商業(yè)競(jìng)爭(zhēng)的原因。當(dāng)時(shí) docker 公司為了跟 K8S 競(jìng)爭(zhēng)，搞了個(gè) Docker Swarm，并且把架構(gòu)進(jìn)行了切分：把容器操作都移動(dòng)到一個(gè)單獨(dú)的 containerd 進(jìn)程中去，讓 Docker Daemon 專門負(fù)責(zé)上層的封裝編排。

可惜在 K8S 面前 swarm 就是弟弟，根本打不過(guò)，于是 Docker 公司只能后退一步，將 containerd項(xiàng)目捐獻(xiàn)給 CNCF 基金會(huì)，而 K8S 也見(jiàn)好就收，既然 Docker 已先退了一步，那就干脆優(yōu)先支持原生Docker 衍生的容器運(yùn)行時(shí)：containerd 。

圖片

使用 containerd 作為容器運(yùn)行時(shí)之后，就不能再使用 docker ps 或 docker inspect 命令來(lái)獲取容器信息。由于不能列出容器，因此也不能獲取日志、停止容器，甚至不能通過(guò) docker exec 在容器中執(zhí)行命令。

當(dāng)然我們?nèi)匀豢梢韵螺d鏡像，或者用 docker build 命令構(gòu)建鏡像，但用 Docker 構(gòu)建、下載的鏡像，對(duì)于容器運(yùn)行時(shí)和 K8S，均不可見(jiàn)。

而且為了適配 CRI 標(biāo)準(zhǔn)，專門起了一個(gè)單獨(dú)的進(jìn)程：CRI-containerd，這是因?yàn)檫€沒(méi)有捐給 K8S 的時(shí)候 containerd 會(huì)去適配其他的項(xiàng)目（Docker Swarm）

到了 containerd 1.1 版本，K8S 去掉了 CRI-Contained 這個(gè) shim，直接把適配邏輯作為插件的方式集成到了 containerd 主進(jìn)程中，現(xiàn)在這樣的調(diào)用就更加簡(jiǎn)潔了。

圖片

除此之外，K8S 社區(qū)也做了一個(gè)專門用于 K8S 的運(yùn)行時(shí) CRI-O，它直接兼容 CRI 和 OCI 規(guī)范。上圖中的 conmon 對(duì)于 containerd-shim

參考文章：

• 45 | 幕后英雄：SIG-Node與CRI-深入剖析 Kubernetes-極客時(shí)間 (geekbang.org)：https://time.geekbang.org/column/article/71056
• K8S Runtime CRI OCI contained dockershim 理解_cri contained-CSDN博客：https://blog.csdn.net/u011563903/article/details/90743853
• https://www.qikqiak.com/post/containerd-usage/