這一刻已經(jīng)來了很久。Kubernetes在1.20版本之后棄用Docker作為容器運(yùn)行時，轉(zhuǎn)而使用使用為Kubernetes創(chuàng)建的Container Runtime Interface(CRI)的運(yùn)行時。但是，這并不意味著Docker的死亡，也不意味著您也應(yīng)該放棄自己喜歡的容器化工具。

[[355903]]

事實上，作為Kubernetes的最終用戶，對您來說并沒有很多改變。您仍然可以使用Docker來構(gòu)建容器，并且通過運(yùn)行docker build生成的映像仍將在您的Kubernetes集群中運(yùn)行。

那么，為什么要這么大驚小怪呢?發(fā)生了什么變化，為什么Docker突然看起來像是黑羊呢?我們應(yīng)該繼續(xù)編寫Dockerfiles嗎?

不要驚慌

這里引起混亂的原因是我們在談?wù)搩煞N不同的事情。在Kubernetes集群節(jié)點內(nèi)部，容器運(yùn)行時守護(hù)程序管理著完整的容器生命周期：映像拉取和存儲，容器執(zhí)行和監(jiān)督，網(wǎng)絡(luò)附件等等。

Docker無疑是最受歡迎的選擇。但是，Docker并非旨在嵌入Kubernetes中。這是所有問題的根源。Docker不僅僅是容器運(yùn)行時;它是整個技術(shù)堆棧，具有許多UX增強(qiáng)功能，使我們可以輕松地與其進(jìn)行交互。實際上，Docker本身包含一個高級容器運(yùn)行時：contined。并且containerd將是您前進(jìn)的容器運(yùn)行時選項。

而且，這些UX增強(qiáng)功能對于Kubernetes來說不是必需的。如果有的話，它們是Kubernetes必須變通以獲取其真正需求的障礙。這意味著Kubernetes集群必須使用另一個名為Dockershim的工具，該工具是容器化的。這增加了一定程度的復(fù)雜性以及團(tuán)隊?wèi)?yīng)維護(hù)的另一種工具。另一個可能產(chǎn)生錯誤和問題的來源。

因此，這里真正發(fā)生的是Kubernetes將刪除1.23版中的Dockershim，這將中斷Docker支持。

你應(yīng)該在乎嗎?

那么，作為開發(fā)人員，您正在改變什么?沒有那么多。如果在開發(fā)過程中使用Docker，則將繼續(xù)這樣做，并且不會發(fā)現(xiàn)任何差異。當(dāng)您使用Docker構(gòu)建映像時，結(jié)果并不是特定于Docker的。這是一個OCI(開放容器倡議)圖片。Kubernetes及其兼容的容器運(yùn)行時(例如容器化或CRI-O)知道如何提取和使用這些映像。這就是為什么我們首先要制定容器外觀標(biāo)準(zhǔn)的原因。

另一方面，如果您使用的是托管的Kubernetes服務(wù)(例如GKE或EKS)，則需要確保節(jié)點在運(yùn)行受支持的容器運(yùn)行時之前重新應(yīng)用Docker支持或更新自定義配置(如果使用)任何。如果您是在本地運(yùn)行Kubernetes，則還應(yīng)該進(jìn)行更改以避免不必要的問題和意外情況。

結(jié)論

在1.20版中，您將收到Docker的棄用警告。這種變化即將到來，并且像其他任何變化一樣，它一開始可能會引起一些問題。但這不是災(zāi)難性的，從長遠(yuǎn)來看，它將使事情變得更容易。

我希望本文能使事情變得更清楚，并減輕一些焦慮。歸根結(jié)底，這些更改對于您作為開發(fā)人員而言可能毫無意義。