【編者的話】Kubernetes 計劃在即將發布的 1.24 版本里棄用并移除 dockershim。

Kubernetes 計劃在即將發布的 1.24 版本里棄用并移除 dockershim。使用 Docker 引擎作為其 Kubernetes 集群的容器運行時的工作流或系統需要在升級到 1.24 版本之前進行遷移。1.23 版本將會保留 dockershim，對該版本的支持則會再延長一年。

Docker 是 Kubernetes 使用的第一個容器運行時。最開始對于 Docker 的支持部分被硬編碼在 Kubernetes 的代碼里，但是隨著項目的發展，Kubernetes 開始添加更多的運行時支持。Kubernetes 社區決定轉向更加結構化和標準化的接口，而不是直接把第三方的解決方案集成到核心代碼里。這就有了容器運行時接口(CRI)，容器網絡接口(CNI)以及容器存儲接口(CSI)這些標準。

正如 Mirantis 的 CTO Adam Parco 所說：

對于大多數人來說，棄用 dockershim 不是什么問題，因為他們甚至可能都感覺不到，他們實際上并沒有使用 Docker 本身，他們用的是符合 CRI 標準的 containerd。對于那些人來說，這跟之前沒什么兩樣。

由于 Docker 不符合 CRI 標準，dockershim 更多充當的是 kubelet 和 Docker 之間的一個翻譯層。然后 Docker 再通過接口形式調用 containerd 來執行容器。containerd 之前是作為一個自包含的容器運行時從 Docker 項目里提取出來，隨后它便成為第一個符合 CRI 標準的運行時。可以看到，棄用 dockershim 以后 kubelet 便可以和 containerd 這樣的容器運行時直接通信。

分別采用 containerd 和 dockershim 的 Kubernetes 工作流對比(來源: Kubernetes)

正如 Kubernetes 博客上最近的一篇文章所提到的，從 dockershim 遷移出去是為了讓 Kubernetes 的代碼庫能夠更好地和新的接口模型保持一致。一些新開發的功能，比如 cgroups v2 還有用戶命名空間，它們和 dockershim 在很大程度上是不兼容的。正如最近這篇博客文章的作者所說：“對 Docker 和 dockershim 的依賴已經滲透到 CNCF 生態系統的各種工具和項目里，這會導致我們的代碼變得更加脆弱。”

如果你當前使用的是 Docker 來構建應用容器的話，那這些容器仍然可以在其他的容器運行時上運行。但是一旦使用替代的容器運行時，Docker 的一些命令可能就不起作用了或者會產生不同的結果。舉個例子，docker ps 或者 docker inspect 無法再獲取容器的信息了，docker exec 也不工作了。

在梳理對 dockershim 的依賴的時候還有一些額外的注意事項，這包括需要確保沒有用到特權 Pod 來執行一些 Docker 命令，比如 docker ps，重啟 Docker service，或者是修改 Docker 的一些特定文件。我們還需要留意一下 Docker 配置文件里有沒有私有鏡像倉庫或者鏡像同步源的設置。如果有的話，其他運行時也需要重新配置一下這些設置。

我們還應該檢查跑在 Kubernetes 基礎設施之外的一些腳本，識別出用到 Docker 命令的部分。這也許包括 SSH 到機器上排障，節點的啟動腳本，又或者是直接裝在節點上的一些監控和安全客戶端。

Mirantis 和 Docker 已經達成一致，他們將會共同維護 dockershim 的代碼，后續它將作為一個相對于 Kubernetes 而言更加獨立、開源并且符合 CRI 接口的項目存在。這意味著 Mirantis 容器運行時(MCR)將會是符合 CRI 標準的運行時。如果遇到不希望或者不能接受 dockershim 下線的情況，他們的 cri-dockerd 將可以用作 dockershim 的一個外部替代品。

Kubernetes 1.24 版本的發布團隊和 CNCF 已經承諾了將會及時提供此次發布相關的文檔，目前計劃是在 4 月份。這里面包含了博客文章，更新代碼示例，教程，以及一份遷移指南。

該團隊認為，繼續進行遷移已經不存在任何主要障礙。他們確實有注意到，最近的 11 月 11 日 SIG Node 興趣小組以及 12 月 6 日 Kubernetes 指導委員會會議上有關推遲棄用 dockershim 的討論。然而，此時他們已經同意繼續推進在即將發布的 1.24 版本里移除 dockershim 的工作。