Kubelet 可通過配置項(xiàng) container-runtime，container-runtime-endpoint 和 image-service-endpoint 來選擇使用 docker，rkt（不推薦）或任何 CRI API 兼容的 container-runtime 。
Kubernetes 接口
Native
Docker
Docker 是迄今為止最常用的容器引擎，主要得益于其容器倉庫和社區(qū)。Docker 是 dockerd 、containerd、containerd-shim 和 runc 的組合，其中 runc 作為 container-runtime。 由于 kubernetes 移除對(duì)于 container-runtime 的直接和非 CRI 接口的支持，因此 Native 支持的方式的后續(xù)將會(huì)被移除。
Rktnetes
截至 kubernetes 1.10.0，直接集成 rkt（或 rktnetes）支持已被棄用。
CRI
容器運(yùn)行時(shí)接口（CRI）的出現(xiàn)是因?yàn)?CoreOS 想要為 kubernetes 添加 rkt 支持。Kubernetes 初期提供了對(duì)于 docker 的支持，但在后續(xù)添加 rkt 支持的補(bǔ)丁后，代碼變得丑陋?jiǎng)?wù)必，充斥著大量的 “if this do rkt else do docker”。為后續(xù)出現(xiàn)的 runtimes 添加支持將無法再繼續(xù)維護(hù)，基于此，CRI 誕生了。
CRI 是一個(gè)基于 protobuf 定義的 api，包括兩個(gè) gRPC 服務(wù)，ImageService 和 RuntimeService。 ImageService 提供 RPC 以從倉庫中提取鏡像，檢查和刪除鏡像。RuntimeService 包含用于管理 pod 和容器生命周期的 RPC，也提供與容器交互的調(diào)用（exec/attach/port-forward）。
cri-containerd
cri-containerd 是一種向 containerd 添加 CRI 支持的服務(wù)，containerd是由 Docker 創(chuàng)建并捐贈(zèng)給 CNCF ，提供 runtime 管理和鏡像服務(wù)。后續(xù) containerd 與 Docker 分離，將 runtime 管理器與 docker 其余的工具分離，以利于不斷增長(zhǎng)的容器管理工具生態(tài)系統(tǒng)在 docker api上實(shí)現(xiàn)標(biāo)準(zhǔn)化。這有助于 docker 社區(qū)的擴(kuò)展并幫助在 docker 倉庫中提供豐富的容器鏡像。
cri-containerd 在kubernetes 1.9 中處于 beta 階段。
rktlet
rktlet 是一個(gè)使用 rkt 作為容器 runtime 的 Kubernetes 接口實(shí)現(xiàn)。
當(dāng) kubelet 請(qǐng)求創(chuàng)建一個(gè) pod 時(shí)，rktlet 將啟動(dòng)一個(gè) systemd 服務(wù)，該服務(wù)將通過運(yùn)行 rkt 二進(jìn)制文件創(chuàng)建一個(gè)新的 rkt 沙盒（sandbox）。 創(chuàng)建 沙盒（sandbox） 后，kubelet 可以請(qǐng)求為 pod 添加/刪除容器等。然后 rktlet 將使用相應(yīng)的 rkt app 命令（app add，app rm，app start 或 app stop）運(yùn)行 rkt 二進(jìn)制文件。 其余的 CRI 方法也通過執(zhí)行 rkt 二進(jìn)制文件來處理。
rktlet 在 kubernetes 1.9 中為 alpha 狀態(tài)。
cri-o
cri-o 是一個(gè) CRI 實(shí)現(xiàn)，為 kubernetes 提供 CRI 接口支撐。 cri-o 提供了一組最小化的工具和接口來下載、提取和管理鏡像、維護(hù)容器生命周期、并提供滿足 CRI 所需的監(jiān)控和日志記錄。 它可以使用任何實(shí)現(xiàn) OCI 運(yùn)行時(shí)規(guī)范的 runtime，默認(rèn)使用 runc。
cri-o 使用配置的 runtime（默認(rèn)情況下為runc）創(chuàng)建容器 sandbox（pod），然后再次使用 runtime 在該 pod 中創(chuàng)建容器。
從kubernetes 1.9開始，cri-o 被認(rèn)為是 stable 的。
frakti
Frakti 允許 Kubernetes 通過 runV 直接在虛擬機(jī)管理程序中運(yùn)行 pod 和容器 。
OCI (Open Container Initiative) 兼容 Runtimes
Containers
bwrap-oci
bwrap-oci 是為容器工具 bubblewrap 提供 OCI 兼容的包裝器，bubblewrap 是一個(gè)無特權(quán)的容器工具。作者為：Per Giuseppe Scrivano，bwrap-oci 不滿足e2e Kubernetes測(cè)試所需的許多功能，例如：無法指定綁定裝載的選項(xiàng)，也無法通過 cgroup 限制資源。
crun
crun是用 C 編寫的 OCI 運(yùn)行時(shí)規(guī)范實(shí)現(xiàn)。配合 cri-o，作者 Giuseppe Scrivano 用它來通過了完整的 e2e 套件測(cè)試。它比同類型功能中的任何其他工具更小更輕。
railcar
railcar 是 OCI runtime-spec 規(guī)范的 rust 語言實(shí)現(xiàn)。參考并實(shí)現(xiàn)了 runc 的部分功能。一般來說，railcar 與 runc 非常相似，但不支持某些 runc 命令。截至目前不受支持的命令列表為：checkpoint，events，exec，init，list，pause，restore，resume，spec。 railcar 始終運(yùn)行與容器進(jìn)程分開的 init 進(jìn)程。 railcar 在其研發(fā)過程號(hào)稱發(fā)現(xiàn)了 OCI 運(yùn)行時(shí)規(guī)范中的一些缺陷。通過使用 rust 語言重寫 rust，作者能夠消除在 go 語言實(shí)現(xiàn)過程中對(duì)于 c 語言中介層的的需要。
我嘗試向編寫缺陷那篇文章的作者詢問了有關(guān)缺陷的具體內(nèi)容，但是未得到回復(fù)。
rkt
rkt 是一個(gè)在 LInux 上運(yùn)行容器而編寫的 CLI 工具。它采用多層設(shè)計(jì)，允許 runtime 可根據(jù)實(shí)現(xiàn)者的需求更改 。 默認(rèn)情況下，rkt 結(jié)合使用 systemd和 systemd-nspawn 來創(chuàng)建容器。 systemd-nspawn 用于管理執(zhí)行 systemd 以管理 cgroup 的命名空間。容器應(yīng)用程序作為 systemd 單元運(yùn)行。通過使用不同與 “1階段” 鏡像，該工具可將運(yùn)行應(yīng)用程序的工具可以從 systemd 工具更改為其他任何工具。
rkt 包含與 runc 相同的功能，但是并不使用 OCI runtime-spec。相反，rkt 提供了一個(gè)命令行接口來提供類似的功能集。
runc
runc 是一個(gè)主要用 go 編寫的 CLI 工具（需要 c 語言的中介層 shim 來完成某些 go 不能完成的功能）。runc 是最受歡迎的 OCI runtime，被 containerd 和 cri-o 使用。
在大多數(shù)情況下，所有 runc 都會(huì)在生成進(jìn)程時(shí)配置 namespace 和 cgroup。 這實(shí)際上就是是一個(gè)容器，包括 namespace 和 cgroups。
runc 依賴并跟蹤 OCI runtime-spec，以保證 runc 和 OCI 規(guī)范主要版本保持同步。這意味著 runc 1.0.0 實(shí)現(xiàn)了 OCI 1.0 版本的規(guī)范。
runlxc
runlxc 是阿里巴巴即將開源的 OCI 兼容 runtime。 runlxc 目前尚未對(duì)外發(fā)布，與 pouch 配合使用。
Virtual Machines
Clear Containers
cc-runtime 兼容 OCI runtime，其通過啟動(dòng)一個(gè) Intel VT-x 安全 [Clear Containers](https://github.com / clearcontainers / agent) 管理程序，而不是標(biāo)準(zhǔn)的Linux 容器。
runv
runv 是基于 hypervisor 的 OCI runtime，使用 KVM，Xen 或 QEMU 來運(yùn)行 OCI 鏡像。它不會(huì)創(chuàng)建容器。
分析
技術(shù)
containerd
containerd 是 CRI 實(shí)現(xiàn)中最復(fù)雜的，提供鏡像和 runtime 服務(wù)所需的 3 個(gè)組件，采用 Go 編寫。
這些組件包含兩個(gè)獨(dú)立的項(xiàng)目 cri，提供了 19,000 行 Go 代碼和 containerd 提供 runtime 的守護(hù)進(jìn)程，運(yùn)行程序和中介層代碼一共 112,000 行。 containerd 默認(rèn)使用它自己的 runc 分支，但是可以配置任何 OCI runtime 規(guī)范兼容的實(shí)現(xiàn)。
Docker/containerd 對(duì) CRI 支持處于 beta 階段。
我無法在 Arch Linux 中編譯。由于時(shí)間有限，我沒有花很多時(shí)間在這上面。依據(jù) README.md 中的構(gòu)建指令無法成功完成 make install.deps 階段。
rkt
rkt 需要兩個(gè)組件，rkt 和 rktlet。 盡管如此，它并沒有遵循標(biāo)準(zhǔn)，而是以自己的方式做事情，盡管它的 github 描述說：“它是可組合的，安全的，并且建立在標(biāo)準(zhǔn)之上”。 它也是用 Go 編寫的。
rkt 組件是 rkt，包含 71,000 行 Go 和 rktlet，包含 4,000 行。
rktlet 對(duì) CRI 支持是 alpha 版。
cri-o
坐在中間是 cri-o。cri-o 為容器編排工具 Kubernetes 定制而生。 憑借其聚焦的單一性，它很快就獲得了 “穩(wěn)定” 狀態(tài)，僅用了 14,000 行 Go。 它與任何 OCI 運(yùn)行時(shí)規(guī)范實(shí)現(xiàn)接口，默認(rèn)為 runc。
cri-o 對(duì) CRI 支持是穩(wěn)定。
可用性
選擇 CRI 實(shí)現(xiàn)的一個(gè)明顯因素是可用性。 您應(yīng)該能夠運(yùn)行完整的 e2e 測(cè)試并能夠運(yùn)行任何 OCI 容器。 如果出現(xiàn)問題，應(yīng)該能夠快速診斷問題。
cri-o
cri-o 可以作為包裝安裝在大多數(shù)發(fā)行版中。 使用 cri-o 非常簡(jiǎn)單。 只需更改 kubelet 標(biāo)志即可使用默認(rèn)值以使用cri-o 套接字。可以應(yīng)用其他配置來添加其他功能，例如 repo 限制，selinux，apparmor seccomp，鏡像簽名等。調(diào)試問題很簡(jiǎn)單，因?yàn)橹挥袃蓚€(gè)部分，cri-o 守護(hù)程序和 conmon 控制臺(tái)監(jiān)視器。
使用 runc 與kubernetes 1.9 我很容易通過完整的 e2e 測(cè)試。
cri-containerd
由于無法編譯，我無法測(cè)試其可用性。
rktlet
rktlet 可以在大多數(shù)發(fā)行版中作為包安裝。使用 rkt 可能需要一點(diǎn)學(xué)習(xí)曲線。有許多有效的方法來配置它，并且學(xué)習(xí)哪一個(gè)適合的用例并不是非常簡(jiǎn)單。 rkt 使用 “階段”，并且很少有關(guān)于階段1 鏡像像用于什么目的的文檔。你可以創(chuàng)建自己的階段1 鏡像，但似乎有適當(dāng)?shù)奈臋n可能會(huì)提供這種需要。
它只有三個(gè)部分，診斷問題通常非常簡(jiǎn)單，因?yàn)樗c systemd 集成，將所有輸出留在日志中。
在嘗試使用 rktlet 作為我的 CRI 提供程序時(shí)，某些容器不能夠正常工作。不幸的是，由于時(shí)間限制，所以我無法正確診斷。 我希望使用 rkt 就像更改 kubelet 標(biāo)志一樣簡(jiǎn)單。
社區(qū)
作為開源社區(qū)的成員，社區(qū)的健康也很重要。 一個(gè)好的社區(qū)應(yīng)該尋求積極參與，快速審查貢獻(xiàn)并有一個(gè)記錄良好的貢獻(xiàn)過程。 它應(yīng)該有一個(gè)積極和有效的用戶群，在其中提出問題并獲得答案。
cri-o
自 2016 年 9 月 10 日以來已有 1354 Pull Requests，其中 23 個(gè)是 Open 的，最早的是 2017 年 9 月 19 日創(chuàng)建的，最后一次 Commit 是在 9 天前。 共有 75 名貢獻(xiàn)者，其中 20 人在上個(gè)月活躍。 過去 30 天提交的 75％ 來自Red Hat 員工。 在過去的 30 天里，已經(jīng)添加了 5,141 行代碼和 刪除了 694 行。 5,141 行代表了 37％ 的代碼變化。 cri-o 有一個(gè)積極的貢獻(xiàn)者基礎(chǔ)，其中大部分是紅帽員工，但有紅帽以外的員工。 拉取請(qǐng)求需要合并 4 天的平均值。 問題大致相同。有一個(gè) IRC 頻道，開發(fā)人員在北美工作時(shí)間內(nèi)回答用戶問題，響應(yīng)時(shí)間約為 4 分鐘。
cri-containerd/containerd
自 2017 年 4 月 14 日以來，已有 484 次針對(duì) containerd/cri 的 Pull Requests，其中 6 次 是 Open 的。最早的Open PR 創(chuàng)建于 2017 年 12 月 8 日，最后一次 Comment 時(shí)間是 2018 年 1 月 18 日。共有 31 位貢獻(xiàn)者，其中 8 位活躍于上個(gè)月。在過去的 30 天里，IBM，Docker，中興通訊，谷歌和英特爾最終貢獻(xiàn)了很多。在過去的 30天里，已經(jīng)添加了 2,123 行代碼和 刪除了 1,217 行。 2,123 行代表了 11％ 的代碼變化。對(duì)于 containerd /cri，并沒有一個(gè)非常活躍的貢獻(xiàn)者基礎(chǔ)，但是這代表了社區(qū)的一個(gè)更健康的體現(xiàn)。
自 2015 年 12月 7 日起，共向 containerd/containerd 提交了1,662 個(gè) Pull Requests，其中 13 個(gè)是 Open 狀態(tài)。 最早的 Open PR 創(chuàng)建于 2017 年 8 月 24 日，最后一次 Commit 于 2017 年 9 月 19 日。共有 120 名貢獻(xiàn)者，其中 12人在上個(gè)月活躍。 過去 30 天中有 46％ 來自 Docker 員工，NTT 和 IBM 分別增加了31％。 在過去的 30 天里，已經(jīng)添加了 4,444 行代碼 和刪除了 1,724 行。 4,444 行代表 3％ 的代碼變化。 對(duì)于 containerd，有一個(gè)非常活躍的貢獻(xiàn)者基礎(chǔ)，但它仍然是多樣化的。
獲得對(duì)這兩者之一的支持需要注冊(cè)為 docker 社區(qū)成員。
rktlet/rkt
自 2014 年11月13 日起，共 2 ,406 次 Pull Requests，其中 49 份是開放的。 最舊的 Open PR 創(chuàng)建于 2015 年 8 月25 日，最后一次 Commente 記錄時(shí)間是 2016 年 8 月 9 日。我認(rèn)為 rkt 維護(hù)者可以做得更好。 接受的 PR 通常在一周內(nèi)進(jìn)行審核和合并。 共有 195 名貢獻(xiàn)者，上個(gè)月沒有任何活動(dòng)。 rkt 的活動(dòng)急劇下降。 我不確定這是不是一個(gè)活躍的項(xiàng)目。
在看了 rkt 的活躍狀況后，我選擇忽略了繼續(xù)查看 rktlet 社區(qū)的健康狀況。
總結(jié)
標(biāo)準(zhǔn)和其相關(guān)的 apis 定義提供了非常大的靈活性，并有助于防止鎖定在特定的累積技術(shù)債中。通過使用 OCI（Open Container Initiative） 容器和 rumtime 標(biāo)準(zhǔn)以及 Kubernetes 的 CRI（Container Runtime Interface ）API，可以選擇演進(jìn)任何任何特定選項(xiàng)而不用更整個(gè)堆技術(shù)棧。
為此，應(yīng)該棄用 kubernetes 原生支持的 docker 機(jī)制，并且只應(yīng)使用 CRI。
基于 hypervisor 的解決方案，我并沒有在選擇繼續(xù)分析，因?yàn)樵诒疚恼戮帉懙臅r(shí)候，runlxc 尚未開源。
對(duì)于 CRI 接口，rktlet/rkt 沒有長(zhǎng)期的社區(qū)支持，而且經(jīng)過了很長(zhǎng)的時(shí)間才演變成 beta 狀態(tài)；cri-containerd 并沒有提供一個(gè)良好的構(gòu)建過程，也沒有發(fā)行版的包裝，我無法測(cè)試。cri-containerd 仍然只是一個(gè) beta 版本，獲得支持有障礙。cri-o 相對(duì)穩(wěn)定，快速，輕松地構(gòu)建，而且更適合在生產(chǎn)環(huán)境穩(wěn)定運(yùn)行，并且具備非常好的社區(qū)支持。我的結(jié)論是，cri-o 是目前最好的選擇。
對(duì)于 runtime，雖然 railcar 和 crun在技術(shù)上可能更優(yōu)越，但我沒有時(shí)間測(cè)試它們。由于它們是可替代品，因此預(yù)先為此工具選擇最佳技術(shù)并不重要。我建議使用當(dāng)前默認(rèn)的 runc，直到可以徹底評(píng)估它們?yōu)橹埂?/p>
引用
