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

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

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

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

圖片

前半部分

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

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

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

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

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

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

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

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

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

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

圖片

可以簡單把 CRI 分為兩組：

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

CRI shim

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

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

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

圖片

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

圖片

后半部分

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

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

圖片

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

圖片

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

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

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

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

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

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

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

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

另一個容器運(yùn)行時：containerd

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

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

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

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

圖片

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

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

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

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

圖片

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

參考文章：

• 45 | 幕后英雄：SIG-Node與CRI-深入剖析 Kubernetes-極客時間 (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/