最新版本的 Kubernetes 容器編排平臺將不再原生支持 Docker 容器運行時，這對用戶來說是一個重大變化。

原計劃 4 月 19 號，延遲到 5 月 3 日發(fā)布的 Kubernetes 1.24 版本標(biāo)志著流行的開源容器編排系統(tǒng)的重大轉(zhuǎn)變，因為對內(nèi)置的 dockershim 支持將一勞永逸地刪除。

Docker是Kubernetes使用的第一個容器運行時。但隨著 Kubernetes 項目向自己的開放容器倡議 (OCI) 過渡，它需要一個權(quán)宜之計，以實現(xiàn)與其他各種容器運行時的可移植性。這個權(quán)宜之計就是 dockershim。

從本質(zhì)上講，dockershim 最初的目的是作為一種臨時解決方案，允許流行的 Docker Engine 容器運行時將 OCI 調(diào)用轉(zhuǎn)換為 Kubernetes 自己的容器運行時接口 (CRI) 中的 Docker 調(diào)用。隨著時間的推移，dockershim 在 Kubernetes 部署中變得根深蒂固，但會減慢部署速度并給維護者帶來負擔(dān)，所以它不得不被移除。

如何為 dockershim 棄用做準(zhǔn)備

現(xiàn)在預(yù)計在 5 月 3 日發(fā)布的 Kubernetes v1.24 版本將要求想要使用最新版本軟件的用戶從 dockershim 遷移到與 Kubernetes 自己兼容的另一個運行時，或者使用由 Mirantis 開發(fā)的 dockershim 的外部替代品，稱為cri-dockerd。

雖然 Kubernetes 節(jié)點將不再默認使用 Docker 運行時，但許多開發(fā)人員和管理員已經(jīng)切換到其他符合 CRI 的運行時，例如 Docker 本身在 2017 年捐贈給 CNCF 的 containerd 和 CRI-O。這通常涉及確保在集群中的每個節(jié)點上運行的 kubelet 代理配置為調(diào)用 containerd 或 CRI-O 套接字。

各種托管 Kubernetes 供應(yīng)商，例如 Red Hat OpenShift，它在 2019 年采用了 CRI-O。Amazon 的 Elastic Kubernetes Service (EKS)、Microsoft 的 Azure Kubernetes Service (AKS) 和 Google 的 Kubernetes Engine (GKE) 已經(jīng)默認使用 containerd。Microsoft 還為使用 Kubernetes 1.19 或更高版本創(chuàng)建的 Azure Kubernetes[9] Linux 節(jié)點池采用了 containerd。

切換到符合 CRI 的運行時

不使用符合 CRI 的運行時替換 dockershim 的開發(fā)人員可能會使他們的集群落后于安全補丁，同時也會錯過新功能。

Kubernetes 維護人員在一月份的一篇博客文章中寫道。“在這一點上，我們相信您(和 Kubernetes)從 dockershim 移除中獲得的價值彌補了您將要進行的遷移工作”。

開發(fā)人員仍然可以在本地使用 Docker 來開發(fā)或測試容器，無論為 Kubernetes 集群使用哪個容器運行時。Docker 生成的鏡像將繼續(xù)在具有所有符合 CRI 的運行時的集群中工作，但不會繼續(xù)受支持。