這一刻已經來了很久。Kubernetes在1.20版本之后棄用Docker作為容器運行時，轉而使用使用為Kubernetes創建的Container Runtime Interface(CRI)的運行時。但是，這并不意味著Docker的死亡，也不意味著您也應該放棄自己喜歡的容器化工具。
事實上，作為Kubernetes的最終用戶，對您來說并沒有很多改變。您仍然可以使用Docker來構建容器，并且通過運行docker build生成的映像仍將在您的Kubernetes集群中運行。
那么，為什么要這么大驚小怪呢?發生了什么變化，為什么Docker突然看起來像是黑羊呢?我們應該繼續編寫Dockerfiles嗎?
不要驚慌
這里引起混亂的原因是我們在談論兩種不同的事情。在Kubernetes集群節點內部，容器運行時守護程序管理著完整的容器生命周期：映像拉取和存儲，容器執行和監督，網絡附件等等。
Docker無疑是最受歡迎的選擇。但是，Docker并非旨在嵌入Kubernetes中。這是所有問題的根源。Docker不僅僅是容器運行時;它是整個技術堆棧，具有許多UX增強功能，使我們可以輕松地與其進行交互。實際上，Docker本身包含一個高級容器運行時：contined。并且containerd將是您前進的容器運行時選項。
而且，這些UX增強功能對于Kubernetes來說不是必需的。如果有的話，它們是Kubernetes必須變通以獲取其真正需求的障礙。這意味著Kubernetes集群必須使用另一個名為Dockershim的工具，該工具是容器化的。這增加了一定程度的復雜性以及團隊應維護的另一種工具。另一個可能產生錯誤和問題的來源。
因此，這里真正發生的是Kubernetes將刪除1.23版中的Dockershim，這將中斷Docker支持。
你應該在乎嗎?
那么，作為開發人員，您正在改變什么?沒有那么多。如果在開發過程中使用Docker，則將繼續這樣做，并且不會發現任何差異。當您使用Docker構建映像時，結果并不是特定于Docker的。這是一個OCI(開放容器倡議)圖片。Kubernetes及其兼容的容器運行時(例如容器化或CRI-O)知道如何提取和使用這些映像。這就是為什么我們首先要制定容器外觀標準的原因。
另一方面，如果您使用的是托管的Kubernetes服務(例如GKE或EKS)，則需要確保節點在運行受支持的容器運行時之前重新應用Docker支持或更新自定義配置(如果使用)任何。如果您是在本地運行Kubernetes，則還應該進行更改以避免不必要的問題和意外情況。
結論
在1.20版中，您將收到Docker的棄用警告。這種變化即將到來，并且像其他任何變化一樣，它一開始可能會引起一些問題。但這不是災難性的，從長遠來看，它將使事情變得更容易。
我希望本文能使事情變得更清楚，并減輕一些焦慮。歸根結底，這些更改對于您作為開發人員而言可能毫無意義。
