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

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

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

正如 Mirantis 的 CTO Adam Parco 所說：

對于大多數(shù)人來說，棄用 dockershim 不是什么問題，因?yàn)樗麄兩踔量赡芏几杏X不到，他們實(shí)際上并沒有使用 Docker 本身，他們用的是符合 CRI 標(biāo)準(zhǔn)的 containerd。對于那些人來說，這跟之前沒什么兩樣。

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

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

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

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

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

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

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

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

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