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

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

[[355749]]

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

對于Kubernetes最終用戶，此次調整同樣不會有太大影響。Docker不會就此消亡，你也仍然可以繼續將Docker作為開發工具使用。Docker會繼續構建起不計其數的容器，而運行docker build命令所生成的鏡像仍可在Kubernetes集群內正常運行。

如果你使用的是GKE或者EKS等托管Kubernetes服務，則需要確保在未來的Kubernetes版本徹底去除Docker支持之前，為你的工作節點引入受支持的容器運行時。如果節點中包含自定義項，你可能需要根據當前環境及運行時要求做出更新。請與服務供應商合作，確保正確完成升級測試及規劃。

如果你的集群一直在滾動擴展，則需要配合變量以避免服務中斷。在1.20版本中，你將收到Docker棄用警告。而在未來的Kubernets版本(計劃在2021年下半年發布的1.23版本)中，Docker運行時將被徹底移除、不再受到支持，屆時您必須切換至其他兼容的容器運行時，例如containerd或者CRI-O。只需要保證你所選定的運行時，能夠支持當前使用的Docker守護程序配置即可(例如日志記錄)。

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

這里我們需要探討兩種不同的環境，而這也是恐慌情緒的根源。首先，在Kubernetes集群內部存在一種叫作容器運行時的東西，負責提取并運行容器鏡像。Docker是目前最流行的運行時選項(其他常見選項還包括containerd與CRI-O)。但Docker在設計上并未考慮到被嵌入Kubernetes這種用法，所以可能引發問題。

很明顯，這里我們提到的“Docker”并不是同一種東西——它代表著一整套技術棧，而containerd高級容器運行時則是Docker中的一部分。Docker很酷、實用性極強，提供多種用戶體驗增強功能，讓我們能夠在開發過程中輕松完成協同交互。但是，用戶體驗增強功能對Kubernetes來說并非必需，因為Kubernetes并不是什么人類協作方。

結果就是，要想讓containerd這個人類友好型抽象層發揮作用，Kubernetes集群就必須引入另一款名為Dockershimi的工具。但這款工具的介入又引發了新的問題，因為我們必須額外加以維護，否則就可能引發安全問題。事實上，Dockershim早在Kubelet 1.23版本時就已經被移除，或者說Kubelet很早就取消了將Docker作為容器運行時的功能。這時候很多朋友可能要問，既然Docker棧中已經包含containerd，Kubernetes為什么還要畫蛇添足地搞出個Dockershim?

這是因為Docker與CRI(即容器運行時接口)并不相容。正是因為不相容，所以我們才需要Dockershim來緩沖一下。但這不是什么大問題，各位沒必要驚慌——這件事的本質，就是把容器運行時從Docker轉換為另一種受支持的選項。

這里需要注意的是：如果大家將底層Docker套接字(/var/run/docker.sock)設定為集群工作流中的一部分，那么轉換至其他運行時會破壞掉當前業務的正常運行。這種模式在Docker中就被稱為Docker，好在我們可以使用多種選項解決這個特定用例，包括Kaniko、Img以及Buildah等等。

但這種變化對開發者意味著什么?我們還需要編寫Dockerfiles嗎?未來還應不應該繼續使用Docker?

請注意，本次變更所影響到的環境，其實跟大多數人用于進行Docker交互的環境并不是一回事。你在開發中使用的Docker安裝，與Kubernetes集群中的Docker運行時毫無關系。我知道，這事聽起來讓人有點犯迷糊。總之，對于開發人員，Docker在公布此次更改之前提供的所有方案都仍然適用。Docker生成的鏡像實際上并不特定于Docker，更準確地說它應該屬于OCI(開放容器倡議)鏡像。任何與OCI相兼容的鏡像，無論使用哪種工具構建而成，對于Kubernetes來說都是一樣的。Containerd與CRI-O都能識別這些鏡像并正常運行，這也是我們建立一套統一容器標準的意義所在。

因此，雖然變化即將到來，雖然會給部分用戶帶來麻煩，但影響并不算大。而且從長遠角度看，這其實是件好事。總而言之，希望大家放下抵觸和恐慌情緒，坦然接受這個變化。