近日，Kubernetes 官方發(fā)布公告，宣布自 v1.20 起放棄對 Docker 的支持，屆時用戶將收到 Docker 棄用警告，并需要改用其他容器運行時。 

[[355838]]

圖片來自 Pexels

但 Docker 作為容器鏡像構(gòu)建工具的作用將不受影響，用其構(gòu)建的容器鏡像將一如既往地在集群中與所有容器運行時正常運轉(zhuǎn)。

Kubernetes 將棄用 Docker

沒錯，這是真的，Kubernetes 現(xiàn)已棄用 Docker!

參考鏈接：

https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#deprecation 

目前，Kubelet 中的 Docker 支持功能現(xiàn)已棄用，并將在之后的版本中被刪除。

Kubelet 之前使用的是一個名為 dockershim 的模塊，用以實現(xiàn)對 Docker 的 CRI 支持。

但 Kubernetes 社區(qū)發(fā)現(xiàn)了與之相關(guān)的維護問題，因此建議大家考慮使用包含 CRI 完整實現(xiàn)(兼容 v1alpha1 或 v1)的可用容器運行時。 

[[355839]]

簡而言之，Docker 并不支持 CRI(容器運行時接口)這一 Kubernetes 運行時 API，而 Kubernetes 用戶一直以來所使用的其實是名為“dockershim”的橋接服務(wù)。

Dockershim 能夠轉(zhuǎn)換 Docker API 與 CRI，但在后續(xù)版本當中，Kubernetes 將不再提供這項橋接服務(wù)。

當然，Docker 本身也是一款非常強大的工具，可用于創(chuàng)建開發(fā)環(huán)境。但為了了解造成當前狀況的原因，我們需要全面分析 Docker 在現(xiàn)有 Kubernetes 架構(gòu)中的作用。

Kubernetes 是一款基礎(chǔ)設(shè)施工具，可對多種不同計算資源(例如虛擬/物理機)進行分組，使其呈現(xiàn)為統(tǒng)一的巨量計算資源，從而供應(yīng)用程序使用或與其他人共享。

在這樣的架構(gòu)中，Docker(或者容器運行時)僅用于通過 Kubernetes 控制平面進行調(diào)度，從而在實際主機內(nèi)運行應(yīng)用程序。 

通過以上架構(gòu)圖，可以看到每個 Kubernetes 節(jié)點都與控制平面彼此通信。各個節(jié)點上的 kubelet 獲取元數(shù)據(jù)，并執(zhí)行 CRI 以在該節(jié)點上運行容器的創(chuàng)建/刪除。

Docker 為什么會被棄用?

如前所述，Kubernetes 只能與 CRI 通信，因此要與 Docker 通信，就必須使用橋接服務(wù)。這就是第一點原因。

要解釋下一個原因，我們必須稍微解釋一下 Docker 架構(gòu)。首先參考以下示意圖： 

沒錯，Kubernetes 實際上需要保持在紅框之內(nèi)。Docker 網(wǎng)絡(luò)與存儲卷都被排除在外。

而這些用不到的功能本身就可能帶來安全隱患。事實上，你擁有的功能越少，攻擊面也就越小。因此，我們需要考慮使用替代方案，即 CRI 運行時。

CRI 運行時的實現(xiàn)方案主要有兩種：

①containerd

如果大家只是想從 Docker 遷移出來，那么 containerd 就是最好的選擇。因為它實際上就是在 Docker 之內(nèi)起效，可以完成所有“運行時”工作，如上圖所示。更重要的是，它提供的 CRI 其實 100% 就是由 Docker 所提供。

containerd 還屬于全開源軟件，因此你可以在 GitHub 上查看說明文檔甚至參與項目貢獻：

https://github.com/containerd/containerd/ 

②CRI-O

CRI-O 是主要由 Red Hat 員工開發(fā)的 CRI 運行時。它的最大區(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è)計本身就是作為“CRI”運行時存在。

不同于作為 Docker 組成部分的 containerd，CRI-O 在本質(zhì)上屬于純 CRI 運行時、因此不包含除 CRI 之外的任何其他內(nèi)容。

從 Docker 遷移至 CRI-O 往往更為困難，但無論如何，CRI-O 至少可以支持 Docker 容器在 Kubernetes 上的正常運行。

還有一點，當我們談?wù)撊萜鬟\行時時，請注意我們到底是在談?wù)撃姆N類型的運行時。

運行時分為兩種：

• CRI 運行時
• OCI 運行時

CRI 運行時

正如之前所提到，CRI 是 Kubernetes 提供的 API，用于同容器運行時進行通信以創(chuàng)建/刪除容器化應(yīng)用程序。

各容器化應(yīng)用程序作為 kubelet 通過 IPC 在 gRPC 內(nèi)通信，而且運行時也運行在同一主機之上;CRI 運行時負責從 kubelet 獲取請求并執(zhí)行 OCI 容器運行時以運行容器。

稍微有點復雜，接下來我們會用圖表來解釋： 

因此，CRI 運行時將執(zhí)行以下操作：

• 從 kubelet 獲取 gRPC 請求。
• 根據(jù)規(guī)范創(chuàng)建 OCI json 配置。

OCI 運行時

OCI 運行時負責使用 Linux 內(nèi)核系統(tǒng)調(diào)用(例如 cgroups 與命名空間)生成容器。你可能聽說過 runC 或者 gVisor，這就是了。 

CRI 會通過 Linux 系統(tǒng)調(diào)用以執(zhí)行二進制文件，而后 runC 生成容器。這表明 runC 依賴于 Linux 計算機上運行的內(nèi)核。

這也意味著，如果你發(fā)現(xiàn) runC 中的漏洞會使你獲得主機 root 權(quán)限，那么容器化應(yīng)用程序同樣會造成 root 權(quán)限外泄。

很明顯，惡意黑客會抓住機會入侵主機，引發(fā)災(zāi)難性的后果。正因為如此，大家才需要不斷更新 Docker(或者其他容器運行時)，而不僅僅是更新容器化應(yīng)用程序本身。 

gVisor 是最初由谷歌員工創(chuàng)建的 OCI 運行時。它實際上運行在承載各類谷歌云服務(wù)(包括 Google Cloud Run、Google App Engine 以及 Google Cloud Functions)的同一套基礎(chǔ)設(shè)施之上。

有趣的是，gVisor 中包含一個“訪客內(nèi)核”層，意味著容器化應(yīng)用程序無法直接接觸到主機內(nèi)核層。

即使是應(yīng)用程序“認為”自己接觸到了，實際接觸到的也只是 gVisor 的訪客內(nèi)核。

gVisor的安全模式非常有趣，這里建議大家參閱官方說明文檔：

https://gvisor.dev/docs/ 

gVisor 與 runC 的顯著差別如下：

• 性能更差
• Linux內(nèi)核層并非 100% 兼容，參見官方文檔中的兼容性部分：

https://gvisor.dev/docs/user_guide/compatibility/ 

• 不受默認支持

總結(jié)：

• Docker 確被棄用，大家應(yīng)該開始考慮使用 CRI 運行時，例如 containerd 與 CRI-O。containerd 與 Docker 相兼容，二者共享相同的核心組件。如果你主要使用 Kubernetes 的最低功能選項，CRI-O 可能更為適合。
• 明確理解 CRI 運行時與 OCI 運行時之間的功能與作用范圍差異。

根據(jù)你的實際工作負載與業(yè)務(wù)需求，runC可能并不總是最好的選擇，請酌情做出考量!

廢棄 Docker，但別慌! 

[[355840]]

在 1.20 版本之后，Kubernetes 將不再支持把 Docker 作為容器運行時使用。

不必驚慌，實際上沒多大影響。

PS：這里只是不建議將 Docker 作為底層運行時，你仍然可以使用專為Kubernetes創(chuàng)建的容器運行時接口(CRI)一如既往地在集群中運行 Docker 鏡像。

對于 Kubernetes 最終用戶，此次調(diào)整同樣不會有太大影響。Docker 不會就此消亡，你也仍然可以繼續(xù)將 Docker 作為開發(fā)工具使用。

Docker 會繼續(xù)構(gòu)建起不計其數(shù)的容器，而運行 docker build 命令所生成的鏡像仍可在 Kubernetes 集群內(nèi)正常運行。

如果你使用的是 GKE 或者 EKS 等托管 Kubernetes 服務(wù)，則需要確保在未來的 Kubernetes 版本徹底去除 Docker 支持之前，為你的工作節(jié)點引入受支持的容器運行時。

如果節(jié)點中包含自定義項，你可能需要根據(jù)當前環(huán)境及運行時要求做出更新。請與服務(wù)供應(yīng)商合作，確保正確完成升級測試及規(guī)劃。

如果你的集群一直在滾動擴展，則需要配合變量以避免服務(wù)中斷。在 1.20 版本中，你將收到 Docker 棄用警告。

而在未來的 Kubernets 版本(計劃在 2021 年下半年發(fā)布的 1.23 版本)中，Docker 運行時將被徹底移除、不再受到支持，屆時您必須切換至其他兼容的容器運行時，例如 containerd 或者 CRI-O。

只需要保證你所選定的運行時，能夠支持當前使用的 Docker 守護程序配置即可(例如日志記錄)。

既然問題不大，大家在慌什么?在怕什么?

這里我們需要探討兩種不同的環(huán)境，而這也是恐慌情緒的根源。首先，在 Kubernetes 集群內(nèi)部存在一種叫作容器運行時的東西，負責提取并運行容器鏡像。

Docker 是目前最流行的運行時選項(其他常見選項還包括 containerd 與 CRI-O)。

但 Docker 在設(shè)計上并未考慮到被嵌入 Kubernetes 這種用法，所以可能引發(fā)問題。

很明顯，這里我們提到的“Docker”并不是同一種東西——它代表著一整套技術(shù)棧，而 containerd 高級容器運行時則是 Docker 中的一部分。

Docker 很酷、實用性極強，提供多種用戶體驗增強功能，讓我們能夠在開發(fā)過程中輕松完成協(xié)同交互。

但是，用戶體驗增強功能對 Kubernetes 來說并非必需，因為 Kubernetes 并不是什么人類協(xié)作方。

結(jié)果就是，要想讓 containerd 這個人類友好型抽象層發(fā)揮作用，Kubernetes 集群就必須引入另一款名為 Dockershimi 的工具。

但這款工具的介入又引發(fā)了新的問題，因為我們必須額外加以維護，否則就可能引發(fā)安全問題。

事實上，Dockershim 早在 Kubelet 1.23 版本時就已經(jīng)被移除，或者說 Kubelet 很早就取消了將 Docker 作為容器運行時的功能。

這時候很多朋友可能要問，既然 Docker 棧中已經(jīng)包含 containerd，Kubernetes 為什么還要畫蛇添足地搞出個 Dockershim?

這是因為 Docker 與 CRI(即容器運行時接口)并不相容。正是因為不相容，所以我們才需要 Dockershim 來緩沖一下。

但這不是什么大問題，各位沒必要驚慌!這件事的本質(zhì)，就是把容器運行時從 Docker 轉(zhuǎn)換為另一種受支持的選項。

這里需要注意的是：如果大家將底層 Docker 套接字(/var/run/docker.sock)設(shè)定為集群工作流中的一部分，那么轉(zhuǎn)換至其他運行時會破壞掉當前業(yè)務(wù)的正常運行。

這種模式稱為 Docker in Docker，好在我們可以使用多種選項解決這個特定用例，包括 Kaniko、Img 以及 Buildah 等等。

對開發(fā)者來說意味著什么?

但這種變化對開發(fā)者意味著什么?我們還需要編寫 Dockerfiles 嗎?未來還應(yīng)不應(yīng)該繼續(xù)使用 Docker?

請注意，本次變更所影響到的環(huán)境，其實跟大多數(shù)人用于進行 Docker 交互的環(huán)境并不是一回事。

你在開發(fā)中使用的 Docker 安裝，與 Kubernetes 集群中的 Docker 運行時毫無關(guān)系。我知道，這事聽起來讓人有點犯迷糊。

總之，對于開發(fā)人員，Docker 在公布此次更改之前提供的所有方案都仍然適用。

Docker 生成的鏡像實際上并不特定于 Docker，更準確地說它應(yīng)該屬于 OCI(開放容器倡議)鏡像。

任何與 OCI 相兼容的鏡像，無論使用哪種工具構(gòu)建而成，對于 Kubernetes 來說都是一樣的。

Containerd 與 CRI-O 都能識別這些鏡像并正常運行，這也是我們建立一套統(tǒng)一容器標準的意義所在。

因此，雖然變化即將到來，雖然會給部分用戶帶來麻煩，但影響并不算大。而且從長遠角度看，這其實是件好事。

總而言之，希望大家放下抵觸和恐慌情緒，坦然接受這個變化。

參考鏈接：

• https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/
• https://dev.to/inductor/wait-docker-is-deprecated-in-kubernetes-now-what-do-i-do-e4m

出處：內(nèi)容來源公眾號分布式實驗室(ID：dockerone)