重磅，Kubernetes 決定棄用 Docker！

作者 | Kohei Ota   譯者 | 核子可樂

策劃 | 萬佳   來源：架構頭條

什麼？Kubernetes 決定棄用 Docker？

這是真的。Kubernetes 現已棄用 Docker。

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

目前，kubelet 中的 Docker 支持功能現已棄用，並將在之後的版本中被刪除。Kubelet 之前使用的是一個名為 dockershim 的模塊，用以實現對 Docker 的 CRI 支持。但 Kubernetes 社區發現了與之相關的維護問題，因此建議大家考慮使用包含 CRI 完整實現（兼容 v1alpha1 或 v1）的可用容器運行時。

簡而言之，Docker 並不支持 CRI（容器運行時接口）這一 Kubernetes 運行時 API，而 Kubernetes 用户一直以來所使用的其實是名為“dockershim”的橋接服務。Dockershim 能夠轉換 Docker API 與 CRI，但在後續版本當中，Kubernetes 將不再提供這項橋接服務。

當然，Docker 本身也是一款非常強大的工具，可用於創建開發環境。但為了瞭解造成當前狀況的原因，我們需要全面分析 Docker 在現有 Kubernetes 架構中的作用。

Kubernetes 是一款基礎設施工具，可對多種不同計算資源（例如虛擬 / 物理機）進行分組，使其呈現為統一的巨量計算資源，從而供應用程序使用或與其他人共享。在這樣的架構中，Docker（或者容器運行時）僅用於通過 Kubernetes 控制平面進行調度，從而在實際主機內運行應用程序。

通過以上架構圖，可以看到每個 Kubernetes 節點都與控制平面彼此通信。各個節點上的 kubelet 獲取元數據，並執行 CRI 以在該節點上創建 / 刪除容器。

1、但 Docker 為什麼會被棄用？

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

要解釋下一個原因，我們必須稍微聊聊 Docker 架構。首先參考以下示意圖。

沒錯，Kubernetes 實際上需要保持在紅框之內。Docker 網絡與存儲卷都被排除在外。

而這些用不到的功能本身就可能帶來安全隱患。事實上，您擁有的功能越少，攻擊面也就越小。

因此，我們需要考慮使用替代方案，即 CRI 運行時。

2、CRI 運行時

CRI 運行時的實現方案主要有兩種。

containerd

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

containerd 還屬於全開源軟件，因此您可以在 GitHub 上查看説明文檔甚至參與項目貢獻。

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

CRI-O

CRI-O 是主要由 Red Hat 員工開發的 CRI 運行時。它的最大區別在於並不依賴於 Docker，而且目前已經在 Red Hat OpenShift 中得到使用。

有趣的是，RHEL 7 同樣不官方支持 Docker。相反，其只為容器環境提供 Podman、Buildah 以及 CRI-O。

https://github.com/cri-o/cri-o

CRI-O 的優勢在於其採用極簡風格，或者説它的設計本身就是作為“純 CRI”運行時存在。不同於作為 Docker 組成部分的 containerd，CRI-O 在本質上屬於純 CRI 運行時、因此不包含除 CRI 之外的任何其他內容。

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

3、還有一點……

當我們談論容器運行時時，請注意我們到底是在談論哪種類型的運行時。運行時分為兩種：CRI 運行時與 OCI 運行時。

CRI 運行時

正如之前所提到，CRI 是 Kubernetes 提供的 API，用於同容器運行時進行通信以創建 / 刪除容器化應用程序。

各容器化應用程序作為 kubelet 通過 IPC 在 gRPC 內通信，而且運行時也運行在同一主機之上；CRI 運行時負責從 kubelet 獲取請求並執行 OCI 容器運行時以運行容器。稍微有點複雜，接下來我們會用圖表來解釋。

因此，CRI 運行時將執行以下操作：

從 kubelet 獲取 gRPC 請求。

根據規範創建 OCIjson 配置。

OCI 運行時

OCI 運行時負責使用 Linux 內核系統調用（例如 cgroups 與命名空間）生成容器。您可能聽説過 runc 或者 gVisor，這就是了。

附錄 1：runC 的工作原理

CRI 會通過 Linux 系統調用以執行二進制文件，而後 runC 生成容器。這表明 runC 依賴於 Linux 計算機上運行的內核。

這也意味着，如果您發現 runC 中的漏洞會使您獲得主機 root 權限，那麼容器化應用程序同樣會造成 root 權限外泄。很明顯，惡意黑客會抓住機會入侵主機，引發災難性的後果。正因為如此，大家才需要不斷更新 Docker（或者其他容器運行時），而不僅僅是更新容器化應用程序本身。

附錄 2：gVisor 工作原理

gVisor 是最初由谷歌員工創建的 OCI 運行時。它實際上運行在承載各類谷歌雲服務（包括 Google Cloud Run、Google App Engine 以及 Google Cloud Functions）的同一套基礎設施之上。

有趣的是，gVisor 中包含一個“訪客內核”層，意味着容器化應用程序無法直接接觸到主機內核層。即使是應用程序“認為”自己接觸到了，實際接觸到的也只是 gVisor 的訪客內核。

gVisor 的安全模式非常有趣，這裏建議大家參閲官方説明文檔。

https://gvisor.dev/docs/

gVisor 與 runC 的顯著差別如下：

性能更差

Linux 內核層並非 100% 兼容：參見官方文檔中的兼容性部分

不受默認支持

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

4、總結

1.Docker 確被棄用，大家應該開始考慮使用 CRI 運行時，例如 containerd 與 CRI-O。

a.containerd 與 Docker 相兼容，二者共享相同的核心組件。

b. 如果您主要使用 Kubernetes 的最低功能選項，CRI-O 可能更為適合。

2.明確理解 CRI 運行時與 OCI 運行時之間的功能與作用範圍差異。

根據您的實際工作負載與業務需求，runC 可能並不總是最好的選擇，請酌情做出考量！

譯文鏈接：

https://dev.to/inductor/wait-docker-is-deprecated-in-kubernetes-now-what-do-i-do-e4m

介紹一本非常經典的入門PDF，它講解的是程序員必知的硬核基礎知識，看完能讓你對計算機有一個基礎的瞭解和入門，是培養你  的基礎，我們看下目錄大綱