本文發表於一年多前。舊文章可能包含過時內容。請檢查頁面中的資訊自發布以來是否已變得不正確。

Dockershim 棄用常見問題解答

更新：此文章有新版本可用。

本文件回答了關於作為 Kubernetes v1.20 版本釋出的一部分而宣佈的 Dockershim 棄用的一些常見問題。有關將 Docker 作為 Kubernetes kubelet 容器執行時棄用及其含義的更多詳細資訊，請檢視部落格文章不要驚慌：Kubernetes 和 Docker。

此外，您可以閱讀檢查 Dockershim 移除是否影響您，以檢視其是否影響您。

為什麼 Dockershim 被棄用？

維護 Dockershim 已成為 Kubernetes 維護者的沉重負擔。CRI 標準的建立是為了減輕這一負擔，並允許不同容器執行時之間的平滑互操作性。Docker 本身目前不實現 CRI，因此出現了問題。

Dockershim 一直被設計為一種臨時解決方案（因此得名：shim）。您可以在Dockershim 移除 Kubernetes 增強提案中閱讀更多關於社群討論和規劃的內容。

此外，與 Dockershim 大致不相容的功能，例如 cgroups v2 和使用者名稱空間，正在這些較新的 CRI 執行時中實現。移除對 Dockershim 的支援將允許在這些領域進一步發展。

我還能在 Kubernetes 1.20 中使用 Docker 嗎？

是的，1.20 中唯一的變化是，如果使用 Docker 作為執行時，在 kubelet 啟動時會列印一條警告日誌。

Dockershim 何時將被移除？

考慮到此更改的影響，我們正在使用延長的棄用時間表。它不會在 Kubernetes 1.22 之前被移除，這意味著沒有 Dockershim 的最早版本將是 2021 年底的 1.23。更新：Dockershim 的移除計劃在 Kubernetes v1.24 中進行，請參閱Dockershim 移除 Kubernetes 增強提案。我們將與供應商和其他生態系統團體緊密合作，以確保平穩過渡，並將根據情況的變化進行評估。

Dockershim 從 Kubernetes 中移除後，我還能繼續使用它嗎？

更新：Mirantis 和 Docker 已承諾在 Dockershim 從 Kubernetes 中移除後繼續維護它。

我現有的 Docker 映象還能用嗎？

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

私有映象怎麼辦？

是的。所有 CRI 執行時都支援 Kubernetes 中使用的相同拉取 Secret 配置，可以透過 PodSpec 或 ServiceAccount。

Docker 和容器是同一回事嗎？

Docker 推廣了 Linux 容器模式，並在開發底層技術方面發揮了重要作用，但 Linux 中的容器已經存在了很長時間。容器生態系統已經發展得遠不止 Docker。OCI 和 CRI 等標準幫助許多工具在我們的生態系統中發展壯大，一些取代了 Docker 的某些方面，而另一些則增強了現有功能。

目前生產中有使用其他執行時的例子嗎？

所有 Kubernetes 專案生成的產品（Kubernetes 二進位制檔案）在每次釋出時都會經過驗證。

此外，kind 專案使用 containerd 已有一段時間，並且在其實用場景中看到了穩定性的提高。Kind 和 containerd 每天都會多次用於驗證 Kubernetes 程式碼庫的任何更改。其他相關專案也遵循類似的模式，展示了其他容器執行時的穩定性和可用性。例如，OpenShift 4.x 自 2019 年 6 月起就在生產中使用 CRI-O 執行時。

有關其他示例和參考資料，您可以檢視 containerd 和 CRI-O 的採用者，它們是雲原生計算基金會 (CNCF) 下的兩個容器執行時。

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

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

我應該使用哪個 CRI 實現？

這是一個複雜的問題，取決於許多因素。如果 Docker 對您有效，那麼切換到 containerd 應該是一個相對容易的互換，並且會帶來更好的效能和更低的開銷。但是，我們鼓勵您探索 CNCF 生態系統中的所有選項，以防有更適合您環境的選項。

更改 CRI 實現時我應該注意什麼？

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

  • 日誌配置
  • 執行時資源限制
  • 呼叫 Docker 或透過其控制套接字使用 Docker 的節點供應指令碼
  • 需要 Docker CLI 或控制套接字的 Kubectl 外掛
  • 需要直接訪問 Docker 的 Kubernetes 工具（例如 kube-imagepuller）
  • registry-mirrors 和不安全登錄檔等功能的配置
  • 其他期望 Docker 可用並在 Kubernetes 之外執行的支援指令碼或守護程式（例如監控或安全代理）
  • GPU 或特殊硬體及其與執行時和 Kubernetes 的整合方式

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

另一件需要注意的事情是，任何期望為系統維護執行或在構建映象時巢狀在容器中執行的東西將不再起作用。對於前者，您可以使用 crictl 工具作為替代品（請參閱 從 dockercli 到 crictl 的對映），對於後者，您可以使用較新的容器構建選項，例如 img、buildah、kaniko 或 buildkit-cli-for-kubectl，它們不需要 Docker。

對於 containerd，您可以從其文件開始，檢視遷移時可用的配置選項。

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

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

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

您還可以檢視這篇優秀的部落格文章等等，Docker 在 Kubernetes 中被棄用了？現在我該怎麼辦？，其中對這些更改進行了更深入的技術討論。

我能得到一個擁抱嗎？

隨時隨地都可以！🤗🤗