本文發表於一年多前。舊文章可能包含過時內容。請檢查頁面中的資訊自發布以來是否已變得不正確。
你的叢集為 v1.24 準備好了嗎?
早在 2020 年 12 月,Kubernetes 就宣佈了棄用 Dockershim。在 Kubernetes 中,dockershim 是一個軟體墊片,允許你將整個 Docker 引擎用作 Kubernetes 內的容器執行時。在即將釋出的 v1.24 版本中,我們將移除 Dockershim——從棄用到移除之間的延遲符合專案政策,即在棄用後至少支援一年。如果你是叢集運營者,本指南包含了你在此版本釋出前需要了解的實際情況。此外,你還需要做什麼來確保你的叢集不會崩潰!
首先,這會影響到你嗎?
如果你是自己部署叢集,或者不確定這次移除是否會影響到你,為了安全起見,請檢查你是否有任何對 Docker Engine 的依賴。請注意,使用 Docker Desktop 構建應用程式容器並不意味著你的叢集對 Docker 有依賴。由 Docker 建立的容器映象符合開放容器倡議 (OCI) 標準,這是一個定義了容器格式和執行時行業標準的 Linux 基金會治理結構。這些映象在 Kubernetes 支援的任何容器執行時上都能正常工作。
如果你正在使用雲提供商的託管 Kubernetes 服務,並且沒有明確更改容器執行時,那麼你可能什麼都不用做。Amazon EKS、Azure AKS 和 Google GKE 現在都預設使用 containerd,但如果你有任何節點自定義設定,應確保它們不需要更新。要檢查節點的執行時,請遵循找出節點上使用的容器執行時的步驟。
無論你是自己部署叢集還是使用雲提供商的託管 Kubernetes 服務,你都可能需要遷移依賴 Docker Engine 的遙測或安全代理。
我有 Docker 依賴,現在該怎麼辦?
如果你的 Kubernetes 叢集依賴 Docker Engine,並且你打算升級到 Kubernetes v1.24(出於安全和類似原因,你最終應該這樣做),你需要將你的容器執行時從 Docker Engine 更改為其他執行時,或者使用 cri-dockerd。由於 containerd 是一個已畢業的 CNCF 專案,並且是 Docker 內部的執行時,因此它是一個安全可靠的替代容器執行時。幸運的是,Kubernetes 專案已經記錄了更改節點容器執行時的過程,並以 containerd 為例。切換到其他支援的執行時的說明也類似。
我想升級 Kubernetes,並且需要保持與 Docker 作為執行時的相容性。我有哪些選擇?
別擔心,你不會被置之不理,也不必承擔停留在舊版 Kubernetes 的安全風險。Mirantis 和 Docker 聯合釋出並正在維護一個 dockershim 的替代品。這個替代品叫做 cri-dockerd。如果你確實需要保持與 Docker 作為執行時的相容性,請按照專案文件中的說明安裝 cri-dockerd。
就這樣嗎?
是的。只要你在面對這個版本時瞭解正在發生的變化以及你自己叢集的細節,並確保與你的開發團隊進行清晰的溝通,那麼這次變動的影響將是最小的。你可能需要對你的叢集、應用程式程式碼或指令碼進行一些更改,但所有這些要求都已在文件中說明。從使用 Docker Engine 作為執行時切換到使用其他支援的容器執行時之一,實際上是移除了中間人,因為 dockershim 的目的就是訪問 Docker 本身使用的容器執行時。從實踐角度來看,從長遠來看,這次移除對你和 Kubernetes 維護者都更有利。
如果你仍有疑問,請先檢視Dockershim 移除常見問題解答。