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

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

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

正如 Mirantis 的 CTO Adam Parco 所說：

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

由于 Docker 不符合 CRI 標準，dockershim 更多充當?shù)氖?kubelet 和 Docker 之間的一個翻譯層。然后 Docker 再通過接口形式調(diào)用 containerd 來執(zhí)行容器。containerd 之前是作為一個自包含的容器運行時從 Docker 項目里提取出來，隨后它便成為第一個符合 CRI 標準的運行時?？梢钥吹剑瑮売?dockershim 以后 kubelet 便可以和 containerd 這樣的容器運行時直接通信。

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

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

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

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

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

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

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

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