Kubernetes 要棄用docker了，我們該怎么辦？

對于開發(fā)人員

不用過度驚慌，Docker容器和映像仍然存在。不是說世界末日來了，實際上它不會改變一切。

但是值得一讀背后的原因：

https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/

https://kubernetes.io/blog/2020/12/02/dockershim-faq/

對于K8s管理員

仔細閱讀并開始考慮Docker替代方案

是標(biāo)題黨嗎

不，這是真的發(fā)生了。Docker現(xiàn)在在Kubernetes中已棄用。

參考

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ū)中看到了維護問題。我們鼓勵您評估在可用的容器運行時，它是CRI的完整實現(xiàn)（兼容v1alpha1或v1）。

簡而言之，這意味著Docker不支持稱為CRI（容器運行時接口）的Kubernetes運行時API，并且Kubernetes人們一直在使用名為“ dockershim”的橋接服務(wù)。它轉(zhuǎn)換了Docker API和CRI，但在一些次要版本中將不再從Kubernetes方面提供它。

當(dāng)然，本地Docker是一個非常強大的工具，可以用來創(chuàng)建開發(fā)環(huán)境，但是為了了解造成這種情況的原因，您需要了解Docker在當(dāng)前Kubernetes體系結(jié)構(gòu)中的作用。

Kubernetes是一種基礎(chǔ)架構(gòu)工具，可對許多不同的計算資源（例如虛擬/物理機）進行分組，使它看起來像是巨大的計算資源，可讓您的應(yīng)用程序運行并與他人共享。在這種架構(gòu)中，Docker（或容器運行時）僅用于通過Kubernetes控制平面進行調(diào)度，從而在實際主機中運行這些應(yīng)用程序。

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

但是為什么不再使用Docker？

同樣，Kubernetes僅使用CRI進行內(nèi)部通信，而與Docker通信則需要橋接服務(wù)。這就是原因一。

為了解釋下一個原因，我們必須稍微了解一下Docker架構(gòu)。這是Docker的架構(gòu)圖。

是的，Kubernetes實際上需要在紅色區(qū)域內(nèi)運行，但是Kubernetes不使用Docker Network和Volume。

如果一個東西擁有很多用戶不用的功能，這本身可能會帶來安全隱患。您擁有的功能越少，攻擊面就越小。

因此，這是后面社區(qū)提出來考慮替代方案的地方，稱為CRI運行時。

CRI運行時

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

containerd

如果您只想從Docker遷移，這是最好的選擇，因為容器實際上是在Docker內(nèi)部使用的，可以完成所有“運行時”工作，如上圖所示。他們提供了CRI，這也是Docker提供的100％。

containerd是100％開放源代碼，因此您可以在GitHub上查看文檔，甚至也可以為此做出貢獻。

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

CRI-O

CRI-O是主要由Red Hat員工開發(fā)的CRI運行時。實際上，此運行時現(xiàn)在已在Red Hat OpenShift中使用。是的，他們不再依賴Docker。

有趣的是，RHEL 7也開始不正式支持Docker。相反，它們?yōu)槿萜鳝h(huán)境提供Podman，Buildah和CRI-O。

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

我認為CRI-O的優(yōu)勢在于它的極簡風(fēng)格，因為它被創(chuàng)建為“ CRI”運行時。盡管容器化作為Docker的一部分試圖變得更加開源，但它們是純CRI運行時，因此CRI-O沒有CRI不需要的任何內(nèi)容。

從Docker遷移到CRI-O可能會更具挑戰(zhàn)性，因為它仍然可以提供在Kubernetes上運行應(yīng)用程序所需的功能。

還有一件事...

當(dāng)我們談?wù)撊萜鬟\行時時，我們需要注意您在談?wù)撃姆N類型的運行時。我們確實有兩種類型的運行時；CRI運行時和OCI運行時。

CRI運行時

正如我所描述的，CRI是Kubernetes提供的API，用于與容器運行時進行對話，以創(chuàng)建/刪除容器化的應(yīng)用程序。

它們通過IPC在gRPC中作為kubelet進行通信，并且運行時在同一主機上運行，并且CRI運行時負責(zé)從kubelet獲取請求并執(zhí)行OCI容器運行時以運行容器。等一下 也許我應(yīng)該用一張圖表來解釋。

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

• 從kubelet獲取gRPC請求

• 按照規(guī)范創(chuàng)建OCI json配置

OCI運行時

OCI運行時負責(zé)使用Linux內(nèi)核系統(tǒng)調(diào)用（例如cgroups和命名空間）生成容器。您可能聽說過runc或gVisor。

附錄1：runC如何工作

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

這也意味著，如果您發(fā)現(xiàn)runC的漏洞獲得了主機的root特權(quán)，那么容器化的應(yīng)用程序也可以這樣做。一個厲害的黑客可能會使您的主機徹底報廢！事情肯定會變糟。這就是為什么您也應(yīng)該不斷更新Docker（或任何其他容器運行時）的原因之一，而不僅僅是容器化的應(yīng)用程序。

附錄2：gVisor的工作方式

gVisor最初由Google員工創(chuàng)建的OCI運行時。它實際上在其基礎(chǔ)結(jié)構(gòu)上運行，以運行其云服務(wù)，例如Google Cloud Run，Google App Engine（第二代）和Google Cloud Functions（甚至更多?。?/p>

這里有趣的是gVisor具有“guest 內(nèi)核”層，這意味著容器化的應(yīng)用程序無法直接接觸主機內(nèi)核層。即使他們認為這樣做，也只能接觸gVisor的guest內(nèi)核。

gVisor的安全模型實際上非常有趣，值得閱讀官方文檔，與runC的顯著區(qū)別如下。

• 性能較差

• Linux內(nèi)核層不是100％兼容的

• 查看官方文檔的兼容性部分

• 默認不支持

總結(jié)

• Docker 確被棄用，大家應(yīng)該開始考慮使用 CRI 運行時，例如 containerd 與 CRI-O。

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

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

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

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

原文鏈接：

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