K8s的“断舍离”：Dockershim年底移除，你的集群还好吗？

《AI视界——从资讯看技术》专栏 · 第十六期

当Kubernetes社区宣布彻底移除一个兼容层时，这不仅仅是技术迭代。对运维来说，这是一次集群健康状况的强制体检。

关联知识点：

Ubuntu 24.04 系统管理与 Containerd 容器运行时部署实战

kubernetes从入门到进阶

本系列专栏其他文章欢迎访问：AI视界——从资讯看技术

我的主页：AOwhisky，这里有更多运维系统性知识整理和其他有趣内容，欢迎与我一起探讨学习~

一、一个兼容层的倒计时

2026年7月，Kubernetes 社区发布了一条被很多人忽略的公告。

大意是：计划于2026年12月的版本中，正式移除最后一个与 Dockershim 兼容的废弃API。还在使用旧版容器运行时的集群，必须在今年完成迁移。

如果你对这个时间线感到突然，可能是因为你错过了之前的铺垫。早在2020年底，K8s社区就宣布了弃用Dockershim的计划。2022年4月，K8s 1.24版本正式移除了kubelet中的Dockershim代码。从那以后，使用Docker作为容器运行时的集群，依赖的是一个独立的适配项目来维持运转。

现在，社区要把这最后一个适配层也拿掉。

第三期我们聊过K8s十周年，当时说了它的核心能力——声明式API、自愈、统一编排。今天这期是十周年话题的延伸：当K8s决定“断舍离”一个历史包袱时，运维需要做什么？

二、先搞清楚：这对我有什么影响？

很多人听到“移除Dockershim”的第一反应是：Docker不能用了？

不是这个意思。Docker作为开发工具、作为构建镜像的工具，不受任何影响。受到影响的是在生产环境中用Docker作为Kubernetes容器运行时的集群。

容器运行时，你可以理解为K8s用来真正启动和管理容器的底层工具。Docker曾经是默认选项，但K8s后来定义了一个标准接口叫CRI。只要容器运行时支持CRI接口，K8s就能用它。

Docker的问题是，它不完全符合CRI标准。Dockershim就是一个“翻译层”，把K8s的CRI指令翻译成Docker能理解的API。这个翻译层现在要被移除了。

受影响的情况：

• 你的K8s节点上还在用docker命令管理容器
• kubectl describe node输出中容器运行时显示为docker
• 你的集群版本较老，从未做过运行时迁移

不受影响的情况：

• 你的集群已经在用containerd或CRI-O
• 你是云上托管的K8s服务——云厂商早就帮你处理了这件事

大部分云上托管集群已经完成了迁移。如果你是自己搭建的集群，或者接手的是比较老的集群，这期就是为你写的。

三、实操：检查你的集群，制定迁移计划

运维的第一反应不是恐慌，是摸清家底。

第一步：检查当前使用的容器运行时

# 查看节点上kubelet使用的容器运行时kubectl get nodes-owide# 查看具体节点的运行时信息kubectl describenode<node-name>|grep"Container Runtime Version"

如果输出里是docker://开头，说明这个节点还在用Docker作为运行时，需要进行迁移。如果是containerd://或cri-o://，那就高枕无忧了。

第二步：确认所有节点的运行时状态

# 统计集群中运行时的分布情况kubectl get nodes-ojsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.nodeInfo.containerRuntimeVersion}{"\n"}{end}'

这个命令会把集群中每个节点的运行时版本列出来。如果有节点还在用Docker，你会在这里看到。如果所有节点都是containerd://，你就可以关掉这篇文章了。

第三步：制定逐节点迁移方案

如果你发现还有Docker节点，迁移的基本思路是：逐节点切换到containerd，确保业务不受影响。

关键操作步骤：

# 1. 先驱逐节点上的Pod，让它们迁移到其他节点kubectl drain<node-name>--ignore-daemonsets --delete-emptydir-data# 2. 在节点上安装containerd（以Ubuntu为例）apt-getupdate&&apt-getinstall-ycontainerd# 3. 配置containerdmkdir-p/etc/containerd containerd config default>/etc/containerd/config.toml# 4. 修改kubelet配置，将运行时从docker切换到containerd# 编辑 /var/lib/kubelet/kubeadm-flags.env# 将 --container-runtime=docker 改为 --container-runtime=remote# 添加 --container-runtime-endpoint=unix:///run/containerd/containerd.sock# 5. 重启kubeletsystemctl restart kubelet# 6. 恢复节点调度kubectl uncordon<node-name>

每一步之间要留足够的观察时间，确认Pod在新的运行时下正常工作，再进行下一个节点。不要贪快一次性迁移所有节点，除非你能承受整个集群同时出问题的代价。

四、迁移不只是技术操作，更是一次“运维健康度”体检

聊到这里，你可能会觉得这只是一个常规的版本升级。但做运维久了你会发现：每一次被迫的技术变更，都是系统隐藏问题的曝光机会。

在迁移Dockershim的过程中，你可能会发现：

• 某个服务对Docker特有功能的依赖：比如某些Pod配置中使用了Docker特有的存储驱动选项，换成containerd后可能不兼容。
• 监控工具的适配问题：一些老旧的容器监控Agent可能只支持Docker的API，换运行时后监控数据会中断。
• CI/CD中的镜像构建流程：虽然Docker本身还能用于构建镜像，但如果你的CI/CD和运行时环境耦合太紧，可能需要一起调整。

这些问题平时不会暴露，因为Docker一直能用。当你不得不迁移时，它们就会一个接一个冒出来。

这恰好是运维核心价值的体现：不是执行迁移命令本身，而是提前发现这些潜在问题、制定回滚预案、确保业务连续性。

一期一会 · 本期核心笔记

1. K8s将于2026年12月移除最后一个Dockershim兼容API。还在用Docker作为容器运行时的集群，必须在此之前完成向containerd或CRI-O的迁移。
2. 迁移前先用kubectl describe node检查每个节点的运行时状态，确认是否需要迁移。迁移步骤应逐节点进行，留足观察时间。
3. 迁移不只是技术升级，更是一次集群健康度检查——长期隐藏的兼容性问题会在迁移中暴露，这正是运维需要提前预判和兜底的地方。

这一期回归了运维的本行。容器运行时是K8s集群的地基，地基换了，上面的业务稳不稳，全看你的迁移计划和回滚方案。下一期，我们回到AI编程安全的话题线——你之前留言说到的GitLab AI代码审查，正好可以接在我们第十四、十五期的AI攻防讨论之后。

这是《AI视界——从资讯看技术》的第十六期。专栏继续，我们下周见。

如果这篇文章让你有所思考，欢迎在评论区聊聊：你维护的集群在用哪种容器运行时？迁移过吗？