這篇文章已超過一年。較舊的文章可能包含過時的內容。請確認頁面中的資訊自發布以來是否已變得不正確。

Dockershim 淘汰常見問題

更新：此文章有新版本。

本文件說明關於 Dockershim 棄用的一些常見問題，Dockershim 棄用是在 Kubernetes v1.20 版本中宣布的。關於棄用 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 增強提案。我們將與供應商和其他生態系統群體密切合作，以確保順利過渡，並將隨著情況發展評估情況。

在從 Kubernetes 中移除 dockershim 後，我還可以繼續使用它嗎？

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

我現有的 Docker 映像檔還能繼續運作嗎？

是的，從 docker build 產生的映像檔將適用於所有 CRI 實作。您所有現有的映像檔仍將以完全相同的方式運作。

那私有映像檔呢？

是的。所有 CRI 運行時都支援 Kubernetes 中使用的相同提取密鑰配置，無論是透過 PodSpec 還是 ServiceAccount。

Docker 和容器是同一件事嗎？

Docker 普及了 Linux 容器模式，並且在開發底層技術方面發揮了重要作用，但 Linux 中的容器已經存在很長時間了。容器生態系統的發展已經遠遠超出 Docker 的範圍。像 OCI 和 CRI 這樣的標準幫助許多工具在我們的生態系統中成長和蓬勃發展，其中一些取代了 Docker 的某些方面，而另一些則增強了現有的功能。

今天是否有人們在生產環境中使用其他運行時的例子？

所有 Kubernetes 專案產生的artifacts（Kubernetes 二進制檔案）都會在每個版本發布時進行驗證。

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

如需其他範例和參考，您可以查看 containerd 和 CRI-O 的採用者，這兩個容器運行時都屬於雲原生計算基金會 (CNCF)。

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

OCI 代表 開放容器倡議組織，該組織標準化了容器工具和技術之間的許多介面。他們維護用於封裝容器映像檔（OCI 映像檔規範）和運行容器（OCI 運行時規範）的標準規範。他們還以 runc 的形式維護運行時規範的實際實作，runc 是 containerd 和 CRI-O 的底層預設運行時。CRI 基於這些底層規範，為管理容器提供端到端標準。

我應該使用哪個 CRI 實作？

這是一個複雜的問題，它取決於許多因素。如果 Docker 對您來說運作良好，那麼遷移到 containerd 應該是一個相對容易的轉換，並且將具有更好的效能和更少的 overhead。但是，我們鼓勵您探索 CNCF landscape 中的所有選項，以防另一個選項更適合您的環境。

在變更 CRI 實作時，我應該注意什麼？

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

  • 日誌記錄配置
  • 運行時資源限制
  • 呼叫 docker 或透過其控制 socket 使用 docker 的節點配置腳本
  • 需要 docker CLI 或控制 socket 的 Kubectl 外掛程式
  • 需要直接存取 Docker 的 Kubernetes 工具（例如 kube-imagepuller）
  • 諸如 registry-mirrors 和不安全 registry 之類的功能配置
  • 其他期望 Docker 可用並在 Kubernetes 外部運行的支援腳本或 daemons（例如監控或安全代理程式）
  • GPU 或特殊硬體以及它們如何與您的運行時和 Kubernetes 整合

如果您使用 Kubernetes 資源請求/限制或基於檔案的日誌收集 DaemonSets，那麼它們將繼續以相同方式運作，但是如果您自訂了 dockerd 配置，則需要在新容器運行時中盡可能地調整它。

另一個需要注意的是，任何期望在系統維護或建構映像檔時巢狀在容器內運行的東西都將不再運作。對於前者，您可以使用 crictl 工具作為直接替換（請參閱 從 dockercli 到 crictl 的映射），對於後者，您可以使用較新的容器建構選項，例如 img、buildah、kaniko 或 buildkit-cli-for-kubectl，這些選項不需要 Docker。

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

有關如何在 Kubernetes 中使用 containerd 和 CRI-O 的說明，請參閱 Kubernetes 文件中的 容器運行時

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

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

您還可以查看這篇優秀的部落格文章 等等，Docker 在 Kubernetes 中已被棄用？，其中更深入地技術性地討論了這些變更。

我可以要一個擁抱嗎？

隨時隨地都可以！ 🤗🤗