已更新：Dockershim 移除常見問題

本文件取代了 2020 年底發布的原始Dockershim 棄用常見問題文章。本文包含 Kubernetes v1.24 版本的更新。

本文件涵蓋關於從 Kubernetes 移除 dockershim 的一些常見問題。移除最初在 Kubernetes v1.20 版本中宣布。Kubernetes v1.24 版本實際上已從 Kubernetes 中移除了 dockershim。

如需更多關於這代表什麼的資訊，請查看部落格文章別驚慌：Kubernetes 與 Docker。

若要判斷移除 dockershim 會對您或您的組織造成什麼影響，您可以閱讀檢查 dockershim 移除是否會影響您。

在 Kubernetes 1.24 版本發布之前的幾個月和幾天裡，Kubernetes 貢獻者努力使這次過渡盡可能順利。

為何從 Kubernetes 中移除 dockershim？

早期版本的 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 landscape 中的所有選項，以防另一個選項更適合您的環境。

我還可以使用 Docker Engine 作為我的容器執行期嗎？

首先，如果您在自己的 PC 上使用 Docker 來開發或測試容器：沒有任何變更。無論您為 Kubernetes 叢集使用哪個容器執行期，您仍然可以在本機使用 Docker。容器使這種互通性成為可能。

Mirantis 和 Docker 已承諾維護 Docker Engine 的替代配接器，並且即使在樹內 dockershim 從 Kubernetes 中移除後，也將繼續維護該配接器。替代配接器名為 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 image-spec) 和執行容器 (OCI runtime-spec) 的標準規範。他們還以 runc 的形式維護 runtime-spec 的實際實作，runc 是 containerd 和 CRI-O 的底層預設執行期。CRI 以這些低階規範為基礎，為管理容器提供端對端標準。

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

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

  • 記錄組態
  • 執行期資源限制
  • 呼叫 docker 或透過其控制 Socket 使用 Docker Engine 的節點佈建腳本
  • 需要 docker CLI 或 Docker Engine 控制 Socket 的 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，您可以從他們的文件開始，以查看在您遷移事物時有哪些組態選項可用。

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

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

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

您可以透過專用的 GitHub issue 討論移除 dockershim 的決定。

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

是否有任何工具可以幫助我找到正在使用的 dockershim？

有！Docker Socket 偵測器 (DDS) 是一個 kubectl 外掛程式，您可以安裝然後使用它來檢查您的叢集。DDS 可以偵測作用中的 Kubernetes 工作負載是否正在將 Docker Engine Socket (docker.sock) 掛載為磁碟區。在 DDS 專案的 README 中找到更多詳細資訊和使用模式。

我可以要一個擁抱嗎？

可以，我們仍然會根據要求提供擁抱。 🤗🤗🤗