更新：移除 Dockershim 的常見問題解答

本文件取代了 2020 年底釋出的原始文章棄用 Dockershim：常見問題解答。本文件包含 Kubernetes v1.24 版本的更新內容。

本文件解答了一些關於從 Kubernetes 中移除 dockershim 的常見問題。移除計劃最初是在 Kubernetes v1.20 釋出時宣佈的。Kubernetes v1.24 版本實際上已將 dockershim 從 Kubernetes 中移除。

欲瞭解更多資訊，請檢視博文別慌：Kubernetes 和 Docker。

要確定移除 dockershim 對您或您的組織會產生何種影響，您可以閱讀檢查 dockershim 移除是否對你有影響。

在 Kubernetes 1.24 釋出前的幾個月和幾天裡，Kubernetes 的貢獻者們努力工作，以確保這是一個平穩的過渡。

為什麼 Dockershim 會從 Kubernetes 中被移除？

Kubernetes 的早期版本只支援特定的容器執行時：Docker Engine。後來，Kubernetes 增加了對其他容器執行時的支援。CRI 標準的建立是為了實現編排器（如 Kubernetes）和多種不同容器執行時之間的互操作性。Docker Engine 並沒有實現這個介面（CRI），所以 Kubernetes 專案建立了特殊的程式碼來幫助過渡，並將這個 dockershim 程式碼作為 Kubernetes 本身的一部分。

dockershim 程式碼一直被認為是一個臨時的解決方案（正如其名：shim）。您可以在移除 Dockershim 的 Kubernetes 增強提案中閱讀更多關於社群討論和規劃的內容。事實上，維護 dockershim 已經成為 Kubernetes 維護者的沉重負擔。

此外，一些與 dockershim 不相容的特性，如 cgroups v2 和使用者名稱空間，正在這些新的 CRI 執行時中實現。從 Kubernetes 中移除 dockershim 有助於在這些領域取得進一步發展。

Docker 和容器是一回事嗎？

Docker 普及了 Linux 容器模式，並在底層技術的開發中發揮了重要作用，然而 Linux 中的容器早已存在。容器生態系統已經發展到遠不止 Docker 的範疇。像 OCI 和 CRI 這樣的標準幫助了許多工具在我們的生態系統中成長和繁榮，其中一些工具取代了 Docker 的某些方面，而另一些則增強了現有的功能。

我現有的容器映象還能用嗎？

是的，透過 docker build 生成的映象將與所有 CRI 實現相容。您現有的所有映象將和以前完全一樣地工作。

私有映象呢？

是的。所有 CRI 執行時都支援 Kubernetes 中使用的相同的拉取憑證配置，無論是透過 PodSpec 還是 ServiceAccount。

我還能在 Kubernetes 1.23 中使用 Docker Engine 嗎？

是的，1.20 版本中唯一的變化是，如果使用 Docker Engine 作為執行時，kubelet 啟動時會列印一條警告日誌。在 1.23 及之前的所有版本中，你都會看到這個警告。dockershim 的移除發生在 Kubernetes 1.24 中。

如果您正在執行 Kubernetes v1.24 或更高版本，請參閱我還能使用 Docker Engine 作為我的容器執行時嗎？。（請記住，如果您使用的是任何受支援的 Kubernetes 版本，都可以從 dockershim 遷移出來；從 v1.24 版本開始，您必須遷移，因為 Kubernetes 不再包含 dockershim）。

我應該使用哪個 CRI 實現？

這是一個複雜的問題，取決於很多因素。如果 Docker Engine 對你來說工作得很好，那麼遷移到 containerd 應該是一個相對容易的替換，並且效能會更好，開銷也更小。然而，我們鼓勵你探索 CNCF 全景圖中的所有選項，以防有其他選項更適合你的環境。

我還能使用 Docker Engine 作為我的容器執行時嗎？

首先，如果你在自己的電腦上使用 Docker 開發或測試容器：什麼都不會改變。無論你的 Kubernetes 叢集使用什麼容器執行時，你仍然可以在本地使用 Docker。容器使這種互操作性成為可能。

Mirantis 和 Docker 已經承諾維護一個 Docker Engine 的替代介面卡，並且即使在 Kubernetes 移除內建的 dockershim 之後，也會繼續維護該介面卡。這個替代介面卡名為 cri-dockerd。

你可以安裝 cri-dockerd 並用它來連線 kubelet 和 Docker Engine。請閱讀將 Docker Engine 節點從 dockershim 遷移到 cri-dockerd 以瞭解更多資訊。

目前在生產環境中使用其他執行時的例子多嗎？

所有 Kubernetes 專案產生的工件（Kubernetes 二進位制檔案）在每個版本釋出時都經過了驗證。

此外，kind 專案使用 containerd 已經有一段時間了，並且在其用例中看到了穩定性的提升。Kind 和 containerd 每天都被多次利用來驗證對 Kubernetes 程式碼庫的任何更改。其他相關專案也遵循類似的模式，證明了其他容器執行時的穩定性和可用性。例如，OpenShift 4.x 自 2019 年 6 月以來一直在生產環境中使用 CRI-O 執行時。

有關其他示例和參考，你可以檢視 containerd 和 CRI-O 的採用者，這兩個容器執行時都隸屬於雲原生計算基金會（CNCF）。

人們一直在提 OCI，那是什麼？

OCI 代表開放容器倡議，它標準化了容器工具和技術之間的許多介面。他們維護著一個用於打包容器映象（OCI 映象規範）和執行容器（OCI 執行時規範）的標準規範。他們還以 runc 的形式維護了一個執行時規範的實際實現，runc 是 containerd 和 CRI-O 的底層預設執行時。CRI 在這些低階規範的基礎上構建，為管理容器提供了一個端到端的標準。

在更換 CRI 實現時，我應該注意什麼？

雖然 Docker 和大多數 CRI（包括 containerd）之間的底層容器化程式碼是相同的，但在一些邊緣方面存在一些差異。遷移時需要考慮的一些常見事項是：

  • 日誌記錄配置
  • 執行時資源限制
  • 呼叫 docker 或透過其控制套接字使用 Docker Engine 的節點配置指令碼
  • 需要 docker CLI 或 Docker Engine 控制套接字的 kubectl 外掛
  • 需要直接訪問 Docker Engine 的 Kubernetes 專案工具（例如：已棄用的 kube-imagepuller 工具）
  • 諸如 registry-mirrors 和不安全映象倉庫等功能的配置
  • 期望 Docker Engine 可用且在 Kubernetes 之外執行的其他支援指令碼或守護程序（例如，監控或安全代理）
  • GPU 或特殊硬體及其與你的執行時和 Kubernetes 的整合方式

如果你使用 Kubernetes 的資源請求/限制或基於檔案的日誌收集 DaemonSet，它們將繼續以相同的方式工作，但如果你自定義了 dockerd 配置，你需要儘可能地為你的新容器執行時進行調整。

另一個需要注意的事情是，任何期望在構建映象時為系統維護或巢狀在容器內執行的東西都將不再工作。對於前者，你可以使用 crictl 工具作為直接替代品（參見從 docker cli 到 crictl 的對映）；對於後者，你可以使用更新的容器構建選項，如 img、buildah、kaniko 或 buildkit-cli-for-kubectl，這些都不需要 Docker。

對於 containerd，你可以從他們的文件開始，看看在遷移過程中有哪些配置選項可用。

有關如何將 containerd 和 CRI-O 與 Kubernetes 一起使用的說明，請參閱 Kubernetes 關於容器執行時的文件。

如果我有更多問題怎麼辦？

如果你使用的是供應商支援的 Kubernetes 發行版，可以向他們諮詢其產品的升級計劃。對於終端使用者的問題，請釋出到我們的終端使用者社群論壇：https://discuss.kubernetes.io/。

你可以透過一個專門的 GitHub issue 來討論移除 dockershim 的決定。

你也可以檢視這篇優秀的博文等等，Docker 在 Kubernetes 中被棄用了？現在我該怎麼辦？，其中對這些變化進行了更深入的技術討論。

有什麼工具可以幫助我發現正在使用的 dockershim 嗎？

有！Docker Socket 檢測器（DDS）是一個 kubectl 外掛，你可以安裝它然後用它來檢查你的叢集。DDS 可以檢測到活動的 Kubernetes 工作負載是否將 Docker Engine 套接字（docker.sock）作為卷掛載。更多細節和使用模式請參見 DDS 專案的 README。

可以給我一個擁抱嗎？

當然，我們仍然應要求提供擁抱。🤗🤗🤗