不講武德，Kubernetes 棄用 Docker刷爆了網(wǎng)絡(luò)，我們公司也慌了！
作者 | Kohei Ota? ?譯者 | 核子可樂
策劃 | 萬佳? ?來源：架構(gòu)頭條
什么？Kubernetes 決定棄用 Docker？
這是真的。Kubernetes 現(xiàn)已棄用 Docker。
“https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md
”
目前，kubelet 中的 Docker 支持功能現(xiàn)已棄用，并將在之后的版本中被刪除。Kubelet 之前使用的是一個(gè)名為 dockershim 的模塊，用以實(shí)現(xiàn)對(duì) Docker 的 CRI 支持。但 Kubernetes 社區(qū)發(fā)現(xiàn)了與之相關(guān)的維護(hù)問題，因此建議大家考慮使用包含 CRI 完整實(shí)現(xiàn)（兼容 v1alpha1 或 v1）的可用容器運(yùn)行時(shí)。
簡(jiǎn)而言之，Docker 并不支持 CRI（容器運(yùn)行時(shí)接口）這一 Kubernetes 運(yùn)行時(shí) API，而 Kubernetes 用戶一直以來所使用的其實(shí)是名為“dockershim”的橋接服務(wù)。Dockershim 能夠轉(zhuǎn)換 Docker API 與 CRI，但在后續(xù)版本當(dāng)中，Kubernetes 將不再提供這項(xiàng)橋接服務(wù)。
當(dāng)然，Docker 本身也是一款非常強(qiáng)大的工具，可用于創(chuàng)建開發(fā)環(huán)境。但為了了解造成當(dāng)前狀況的原因，我們需要全面分析 Docker 在現(xiàn)有 Kubernetes 架構(gòu)中的作用。
Kubernetes 是一款基礎(chǔ)設(shè)施工具，可對(duì)多種不同計(jì)算資源（例如虛擬 / 物理機(jī)）進(jìn)行分組，使其呈現(xiàn)為統(tǒng)一的巨量計(jì)算資源，從而供應(yīng)用程序使用或與其他人共享。在這樣的架構(gòu)中，Docker（或者容器運(yùn)行時(shí)）僅用于通過 Kubernetes 控制平面進(jìn)行調(diào)度，從而在實(shí)際主機(jī)內(nèi)運(yùn)行應(yīng)用程序。
通過以上架構(gòu)圖，可以看到每個(gè) Kubernetes 節(jié)點(diǎn)都與控制平面彼此通信。各個(gè)節(jié)點(diǎn)上的 kubelet 獲取元數(shù)據(jù)，并執(zhí)行 CRI 以在該節(jié)點(diǎn)上創(chuàng)建 / 刪除容器。
1、但 Docker 為什么會(huì)被棄用？
如前所述，Kubernetes 只能與 CRI 通信，因此要與 Docker 通信，就必須使用橋接服務(wù)。這就是棄用 Docker 的第一點(diǎn)原因。
要解釋下一個(gè)原因，我們必須稍微聊聊 Docker 架構(gòu)。首先參考以下示意圖。
沒錯(cuò)，Kubernetes 實(shí)際上需要保持在紅框之內(nèi)。Docker 網(wǎng)絡(luò)與存儲(chǔ)卷都被排除在外。
而這些用不到的功能本身就可能帶來安全隱患。事實(shí)上，您擁有的功能越少，攻擊面也就越小。
因此，我們需要考慮使用替代方案，即 CRI 運(yùn)行時(shí)。
2、CRI 運(yùn)行時(shí)
CRI 運(yùn)行時(shí)的實(shí)現(xiàn)方案主要有兩種。
containerd
如果大家只是想從 Docker 遷移出來，那么 containerd 就是最好的選擇。因?yàn)樗鼘?shí)際上就是在 Docker 之內(nèi)起效，可以完成所有“運(yùn)行時(shí)”工作，如上圖所示。更重要的是，它提供的 CRI 其實(shí) 100% 就是由 Docker 所提供。
containerd 還屬于全開源軟件，因此您可以在 GitHub 上查看說明文檔甚至參與項(xiàng)目貢獻(xiàn)。
“https://github.com/containerd/containerd/
”
CRI-O
CRI-O 是主要由 Red Hat 員工開發(fā)的 CRI 運(yùn)行時(shí)。它的最大區(qū)別在于并不依賴于 Docker，而且目前已經(jīng)在 Red Hat OpenShift 中得到使用。
有趣的是，RHEL 7 同樣不官方支持 Docker。相反，其只為容器環(huán)境提供 Podman、Buildah 以及 CRI-O。
“https://github.com/cri-o/cri-o
”
CRI-O 的優(yōu)勢(shì)在于其采用極簡(jiǎn)風(fēng)格，或者說它的設(shè)計(jì)本身就是作為“純 CRI”運(yùn)行時(shí)存在。不同于作為 Docker 組成部分的 containerd，CRI-O 在本質(zhì)上屬于純 CRI 運(yùn)行時(shí)、因此不包含除 CRI 之外的任何其他內(nèi)容。
從 Docker 遷移至 CRI-O 往往更為困難，但無論如何，CRI-O 至少可以支持 Docker 容器在 Kubernetes 上的正常運(yùn)行。
3、還有一點(diǎn)……
當(dāng)我們談?wù)撊萜鬟\(yùn)行時(shí)時(shí)，請(qǐng)注意我們到底是在談?wù)撃姆N類型的運(yùn)行時(shí)。運(yùn)行時(shí)分為兩種：CRI 運(yùn)行時(shí)與 OCI 運(yùn)行時(shí)。
CRI 運(yùn)行時(shí)
正如之前所提到，CRI 是 Kubernetes 提供的 API，用于同容器運(yùn)行時(shí)進(jìn)行通信以創(chuàng)建 / 刪除容器化應(yīng)用程序。
各容器化應(yīng)用程序作為 kubelet 通過 IPC 在 gRPC 內(nèi)通信，而且運(yùn)行時(shí)也運(yùn)行在同一主機(jī)之上；CRI 運(yùn)行時(shí)負(fù)責(zé)從 kubelet 獲取請(qǐng)求并執(zhí)行 OCI 容器運(yùn)行時(shí)以運(yùn)行容器。稍微有點(diǎn)復(fù)雜，接下來我們會(huì)用圖表來解釋。
因此，CRI 運(yùn)行時(shí)將執(zhí)行以下操作：
從 kubelet 獲取 gRPC 請(qǐng)求。 根據(jù)規(guī)范創(chuàng)建 OCIjson 配置。
OCI 運(yùn)行時(shí)
OCI 運(yùn)行時(shí)負(fù)責(zé)使用 Linux 內(nèi)核系統(tǒng)調(diào)用（例如 cgroups 與命名空間）生成容器。您可能聽說過 runc 或者 gVisor，這就是了。
附錄 1：runC 的工作原理
CRI 會(huì)通過 Linux 系統(tǒng)調(diào)用以執(zhí)行二進(jìn)制文件，而后 runC 生成容器。這表明 runC 依賴于 Linux 計(jì)算機(jī)上運(yùn)行的內(nèi)核。
這也意味著，如果您發(fā)現(xiàn) runC 中的漏洞會(huì)使您獲得主機(jī) root 權(quán)限，那么容器化應(yīng)用程序同樣會(huì)造成 root 權(quán)限外泄。很明顯，惡意黑客會(huì)抓住機(jī)會(huì)入侵主機(jī)，引發(fā)災(zāi)難性的后果。正因?yàn)槿绱?，大家才需要不斷更?Docker（或者其他容器運(yùn)行時(shí)），而不僅僅是更新容器化應(yīng)用程序本身。
附錄 2：gVisor 工作原理
gVisor 是最初由谷歌員工創(chuàng)建的 OCI 運(yùn)行時(shí)。它實(shí)際上運(yùn)行在承載各類谷歌云服務(wù)（包括 Google Cloud Run、Google App Engine 以及 Google Cloud Functions）的同一套基礎(chǔ)設(shè)施之上。
有趣的是，gVisor 中包含一個(gè)“訪客內(nèi)核”層，意味著容器化應(yīng)用程序無法直接接觸到主機(jī)內(nèi)核層。即使是應(yīng)用程序“認(rèn)為”自己接觸到了，實(shí)際接觸到的也只是 gVisor 的訪客內(nèi)核。
gVisor 的安全模式非常有趣，這里建議大家參閱官方說明文檔。
“https://gvisor.dev/docs/
”
gVisor 與 runC 的顯著差別如下：
性能更差 Linux 內(nèi)核層并非 100% 兼容：參見官方文檔中的兼容性部分 不受默認(rèn)支持
“https://gvisor.dev/docs/user_guide/compatibility/
”
4、總結(jié)
1.Docker 確被棄用，大家應(yīng)該開始考慮使用 CRI 運(yùn)行時(shí)，例如 containerd 與 CRI-O。
a.containerd 與 Docker 相兼容，二者共享相同的核心組件。
b. 如果您主要使用 Kubernetes 的最低功能選項(xiàng)，CRI-O 可能更為適合。
2.明確理解 CRI 運(yùn)行時(shí)與 OCI 運(yùn)行時(shí)之間的功能與作用范圍差異。
根據(jù)您的實(shí)際工作負(fù)載與業(yè)務(wù)需求，runC 可能并不總是最好的選擇，請(qǐng)酌情做出考量！
譯文原文鏈接：
“https://dev.to/inductor/wait-docker-is-deprecated-in-kubernetes-now-what-do-i-do-e4m
”
獲得原創(chuàng)整理：《第2版：互聯(lián)網(wǎng)大廠面試題》
什么？Kubernetes 決定棄用 Docker？
這是真的。Kubernetes 現(xiàn)已棄用 Docker。
“https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md
”
目前，kubelet 中的 Docker 支持功能現(xiàn)已棄用，并將在之后的版本中被刪除。Kubelet 之前使用的是一個(gè)名為 dockershim 的模塊，用以實(shí)現(xiàn)對(duì) Docker 的 CRI 支持。但 Kubernetes 社區(qū)發(fā)現(xiàn)了與之相關(guān)的維護(hù)問題，因此建議大家考慮使用包含 CRI 完整實(shí)現(xiàn)（兼容 v1alpha1 或 v1）的可用容器運(yùn)行時(shí)。
簡(jiǎn)而言之，Docker 并不支持 CRI（容器運(yùn)行時(shí)接口）這一 Kubernetes 運(yùn)行時(shí) API，而 Kubernetes 用戶一直以來所使用的其實(shí)是名為“dockershim”的橋接服務(wù)。Dockershim 能夠轉(zhuǎn)換 Docker API 與 CRI，但在后續(xù)版本當(dāng)中，Kubernetes 將不再提供這項(xiàng)橋接服務(wù)。
當(dāng)然，Docker 本身也是一款非常強(qiáng)大的工具，可用于創(chuàng)建開發(fā)環(huán)境。但為了了解造成當(dāng)前狀況的原因，我們需要全面分析 Docker 在現(xiàn)有 Kubernetes 架構(gòu)中的作用。
Kubernetes 是一款基礎(chǔ)設(shè)施工具，可對(duì)多種不同計(jì)算資源（例如虛擬 / 物理機(jī)）進(jìn)行分組，使其呈現(xiàn)為統(tǒng)一的巨量計(jì)算資源，從而供應(yīng)用程序使用或與其他人共享。在這樣的架構(gòu)中，Docker（或者容器運(yùn)行時(shí)）僅用于通過 Kubernetes 控制平面進(jìn)行調(diào)度，從而在實(shí)際主機(jī)內(nèi)運(yùn)行應(yīng)用程序。
通過以上架構(gòu)圖，可以看到每個(gè) Kubernetes 節(jié)點(diǎn)都與控制平面彼此通信。各個(gè)節(jié)點(diǎn)上的 kubelet 獲取元數(shù)據(jù)，并執(zhí)行 CRI 以在該節(jié)點(diǎn)上創(chuàng)建 / 刪除容器。
1、但 Docker 為什么會(huì)被棄用？
如前所述，Kubernetes 只能與 CRI 通信，因此要與 Docker 通信，就必須使用橋接服務(wù)。這就是棄用 Docker 的第一點(diǎn)原因。
要解釋下一個(gè)原因，我們必須稍微聊聊 Docker 架構(gòu)。首先參考以下示意圖。
沒錯(cuò)，Kubernetes 實(shí)際上需要保持在紅框之內(nèi)。Docker 網(wǎng)絡(luò)與存儲(chǔ)卷都被排除在外。
而這些用不到的功能本身就可能帶來安全隱患。事實(shí)上，您擁有的功能越少，攻擊面也就越小。
因此，我們需要考慮使用替代方案，即 CRI 運(yùn)行時(shí)。
2、CRI 運(yùn)行時(shí)
CRI 運(yùn)行時(shí)的實(shí)現(xiàn)方案主要有兩種。
containerd
如果大家只是想從 Docker 遷移出來，那么 containerd 就是最好的選擇。因?yàn)樗鼘?shí)際上就是在 Docker 之內(nèi)起效，可以完成所有“運(yùn)行時(shí)”工作，如上圖所示。更重要的是，它提供的 CRI 其實(shí) 100% 就是由 Docker 所提供。
containerd 還屬于全開源軟件，因此您可以在 GitHub 上查看說明文檔甚至參與項(xiàng)目貢獻(xiàn)。
“https://github.com/containerd/containerd/
”
CRI-O
CRI-O 是主要由 Red Hat 員工開發(fā)的 CRI 運(yùn)行時(shí)。它的最大區(qū)別在于并不依賴于 Docker，而且目前已經(jīng)在 Red Hat OpenShift 中得到使用。
有趣的是，RHEL 7 同樣不官方支持 Docker。相反，其只為容器環(huán)境提供 Podman、Buildah 以及 CRI-O。
“https://github.com/cri-o/cri-o
”
CRI-O 的優(yōu)勢(shì)在于其采用極簡(jiǎn)風(fēng)格，或者說它的設(shè)計(jì)本身就是作為“純 CRI”運(yùn)行時(shí)存在。不同于作為 Docker 組成部分的 containerd，CRI-O 在本質(zhì)上屬于純 CRI 運(yùn)行時(shí)、因此不包含除 CRI 之外的任何其他內(nèi)容。
從 Docker 遷移至 CRI-O 往往更為困難，但無論如何，CRI-O 至少可以支持 Docker 容器在 Kubernetes 上的正常運(yùn)行。
3、還有一點(diǎn)……
當(dāng)我們談?wù)撊萜鬟\(yùn)行時(shí)時(shí)，請(qǐng)注意我們到底是在談?wù)撃姆N類型的運(yùn)行時(shí)。運(yùn)行時(shí)分為兩種：CRI 運(yùn)行時(shí)與 OCI 運(yùn)行時(shí)。
CRI 運(yùn)行時(shí)
正如之前所提到，CRI 是 Kubernetes 提供的 API，用于同容器運(yùn)行時(shí)進(jìn)行通信以創(chuàng)建 / 刪除容器化應(yīng)用程序。
各容器化應(yīng)用程序作為 kubelet 通過 IPC 在 gRPC 內(nèi)通信，而且運(yùn)行時(shí)也運(yùn)行在同一主機(jī)之上；CRI 運(yùn)行時(shí)負(fù)責(zé)從 kubelet 獲取請(qǐng)求并執(zhí)行 OCI 容器運(yùn)行時(shí)以運(yùn)行容器。稍微有點(diǎn)復(fù)雜，接下來我們會(huì)用圖表來解釋。
因此，CRI 運(yùn)行時(shí)將執(zhí)行以下操作：
從 kubelet 獲取 gRPC 請(qǐng)求。 根據(jù)規(guī)范創(chuàng)建 OCIjson 配置。
OCI 運(yùn)行時(shí)
OCI 運(yùn)行時(shí)負(fù)責(zé)使用 Linux 內(nèi)核系統(tǒng)調(diào)用（例如 cgroups 與命名空間）生成容器。您可能聽說過 runc 或者 gVisor，這就是了。
附錄 1：runC 的工作原理
CRI 會(huì)通過 Linux 系統(tǒng)調(diào)用以執(zhí)行二進(jìn)制文件，而后 runC 生成容器。這表明 runC 依賴于 Linux 計(jì)算機(jī)上運(yùn)行的內(nèi)核。
這也意味著，如果您發(fā)現(xiàn) runC 中的漏洞會(huì)使您獲得主機(jī) root 權(quán)限，那么容器化應(yīng)用程序同樣會(huì)造成 root 權(quán)限外泄。很明顯，惡意黑客會(huì)抓住機(jī)會(huì)入侵主機(jī)，引發(fā)災(zāi)難性的后果。正因?yàn)槿绱?，大家才需要不斷更?Docker（或者其他容器運(yùn)行時(shí)），而不僅僅是更新容器化應(yīng)用程序本身。
附錄 2：gVisor 工作原理
gVisor 是最初由谷歌員工創(chuàng)建的 OCI 運(yùn)行時(shí)。它實(shí)際上運(yùn)行在承載各類谷歌云服務(wù)（包括 Google Cloud Run、Google App Engine 以及 Google Cloud Functions）的同一套基礎(chǔ)設(shè)施之上。
有趣的是，gVisor 中包含一個(gè)“訪客內(nèi)核”層，意味著容器化應(yīng)用程序無法直接接觸到主機(jī)內(nèi)核層。即使是應(yīng)用程序“認(rèn)為”自己接觸到了，實(shí)際接觸到的也只是 gVisor 的訪客內(nèi)核。
gVisor 的安全模式非常有趣，這里建議大家參閱官方說明文檔。
“https://gvisor.dev/docs/
”
gVisor 與 runC 的顯著差別如下：
性能更差 Linux 內(nèi)核層并非 100% 兼容：參見官方文檔中的兼容性部分 不受默認(rèn)支持
“https://gvisor.dev/docs/user_guide/compatibility/
”
4、總結(jié)
1.Docker 確被棄用，大家應(yīng)該開始考慮使用 CRI 運(yùn)行時(shí)，例如 containerd 與 CRI-O。
a.containerd 與 Docker 相兼容，二者共享相同的核心組件。
b. 如果您主要使用 Kubernetes 的最低功能選項(xiàng)，CRI-O 可能更為適合。
2.明確理解 CRI 運(yùn)行時(shí)與 OCI 運(yùn)行時(shí)之間的功能與作用范圍差異。
根據(jù)您的實(shí)際工作負(fù)載與業(yè)務(wù)需求，runC 可能并不總是最好的選擇，請(qǐng)酌情做出考量！
譯文原文鏈接：
“https://dev.to/inductor/wait-docker-is-deprecated-in-kubernetes-now-what-do-i-do-e4m
”