Kubernetes弃用Docker运行时的技术演进与Containerd迁移实战

1. 从“黄金搭档”到“分道扬镳”一个必然的技术演进如果你在2020年底到2021年初关注过Kubernetes社区可能会被一条新闻刷屏Kubernetes宣布将在后续版本中弃用对Docker作为容器运行时的直接支持。当时这个消息在开发者圈子里激起了不小的波澜很多人第一反应是困惑和担忧“我用了这么多年的docker run和docker build难道以后在K8s里都不能用了吗”“是不是K8s要和Docker彻底决裂了”一时间各种猜测和误解四起。事实上这个决定并非一时兴起更不是两个明星开源项目之间的“宫斗”。它背后是一个清晰的技术演进逻辑是Kubernetes为了追求更高效、更稳定、更符合云原生标准的架构所做出的必然选择。要理解这一点我们不能只看“弃用”这个结果而必须回到容器技术栈的底层看看Docker在K8s集群中究竟扮演了什么角色以及为什么这个角色会变得不再合适。简单来说你可以把早期的K8s和Docker的关系想象成一家餐厅K8s和一位全能大厨Docker。餐厅需要出餐这位大厨不仅会炒菜运行容器还自带全套厨房设备镜像构建、存储、网络甚至包揽了采购和洗碗日志、监控。一开始餐厅规模小有这么一位全能大厨确实省心。但随着餐厅发展成为连锁集团管理成千上万家分店问题就来了每家分店的后厨都被这位大厨的“全家桶”塞得满满当当架构臃肿升级维护困难而且大厨的很多独家手艺比如Docker特有的守护进程通信方式和集团标准的中央厨房流程K8s定义的CRI接口对接不畅效率低下。K8s放弃的并不是“容器”这个概念也不是我们熟悉的Docker镜像OCI标准镜像依然完全兼容它放弃的仅仅是Docker这个“全能大厨”作为在K8s节点上直接管理容器生命周期的那个组件。餐厅K8s决定以后所有分店节点的后厨只聘用符合集团标准接口CRI的、职责单一的“炒菜师傅”如containerd或CRI-O至于镜像构建、仓库管理这些工作交给更专业的中央厨房CI/CD流水线和供应链镜像仓库去完成。这个转变是为了让整个系统更专注、更高效、也更易于维护。所以当你再看到“K8s弃用Docker”时不必恐慌。你的Dockerfile依然有效你的docker build出来的镜像在K8s里照样跑得欢。变的只是K8s集群内部容器被创建和运行的那最后一环的实现方式。接下来我们就深入后厨拆解这个转变背后的每一个技术细节和考量。2. 拆解Docker它远不止是“运行容器”在深入讨论K8s的抉择之前我们必须先彻底搞清楚Docker到底是什么。很多人的误解源于将“Docker”等同于“容器运行时”但实际上Docker是一个包含了大量组件的完整平台。当你在一个K8s节点上安装Docker时你安装的是一整套东西而K8s真正用到的只是其中很小一部分。2.1 Docker的“全家桶”架构一个完整的Docker引擎Docker Engine安装后主要包含以下核心组件Docker Daemon (dockerd): 这是一个常驻后台的守护进程它是Docker的核心大脑。所有Docker命令如docker run,docker ps实际上都是通过REST API与这个守护进程通信由它来执行具体的操作。dockerd本身非常庞大它要处理镜像管理、容器生命周期管理、网络、存储卷、日志等几乎所有事情。containerd: 这是一个专注于容器生命周期管理的守护进程。事实上从Docker 1.11版本开始Docker引擎的架构进行了重大调整将实际的容器运行时功能剥离到了containerd这个独立的项目中。dockerd作为上层管理者将大多数容器操作如创建、启动、停止容器委托给containerd去执行。containerd再通过一个名为runc的工具来真正创建容器。runc: 这是一个符合OCIOpen Container Initiative运行时标准的轻量级命令行工具。它的功能非常单一根据一个容器运行时规范bundle里面包含了config.json和根文件系统来启动一个容器。containerd会调用runc来完成容器的创建。Docker CLI (docker): 我们最熟悉的命令行工具它是用户与dockerd交互的客户端。其他组件: 如用于构建镜像的docker build系统、管理镜像层的overlay2存储驱动、网络驱动如bridge等。所以一个简单的docker run nginx命令背后的调用链大致是docker cli-dockerd-containerd-runc- 启动容器。2.2 K8s真正需要的是什么CRI与容器运行时Kubernetes的设计哲学是“控制平面”与“数据平面”分离。控制平面如kube-apiserver, kube-scheduler负责决策数据平面即各个节点负责执行。在节点上负责与容器打交道的组件是kubelet。kubelet的核心任务之一就是管理Pod和其中的容器。但它不应该、也不可能去直接操作Docker Daemon这样复杂的“全家桶”。为了定义一个标准的交互方式Kubernetes提出了容器运行时接口。CRI是一个gRPC协议它定义了一组标准API。kubelet通过这些API来发出指令例如“请在这个Pod里创建一个容器使用这个镜像设置这些环境变量...” 而实现这些API的服务端就是容器运行时。在早期Kubernetes社区维护了一个名为dockershim的适配器代码。这个代码直接内置在kubelet中。它的作用就是将kubelet通过CRI发出的请求翻译成Docker Daemon能理解的APIDocker Engine API。所以在“K8s使用Docker”的时代实际的架构是kubelet- (dockershim适配器) -dockerd-containerd-runc发现问题了吗K8s并没有直接使用Docker来运行容器它使用的是Docker引擎中的containerd组件。但为了用到containerd它不得不先经过dockershim和整个dockerd。dockerd提供了大量K8s根本不需要的功能比如独立的镜像构建、Docker Swarm集群管理等却引入了额外的复杂性和性能开销。这就好比你想用一把锋利的菜刀containerd但菜刀被装在一个功能繁多、体积庞大的多功能工具箱Docker Engine里。K8s每次用刀都得先打开这个工具箱拿出刀用完再放回去。而这个工具箱本身还有自己的一套开锁方式Docker Engine API需要专门的翻译dockershim才能听懂K8s的指令。3. “弃用”的导火索Dockershim的维护之痛理解了上述架构就能明白“弃用”的直接原因维护dockershim这块“翻译层”代码成了Kubernetes社区一个越来越沉重的负担。3.1 一个不被祝福的“适配层”dockershim从一开始就是一个妥协的产物。在Kubernetes项目早期Docker是市场上唯一成熟且被广泛接受的容器解决方案。为了降低用户的使用门槛快速推广K8s集成Docker是最务实的选择。但Docker的API并非为K8s而生两者在模型和特性上并不完全匹配因此需要dockershim这个适配层来弥合差异。随着时间推移这个适配层的问题日益凸显测试与维护成本高昂Docker Engine的每一个新版本发布Kubernetes社区都需要测试dockershim是否还能正常工作。Docker API的任何变动即使是细微的都可能导致dockershim出问题。这意味着K8s核心团队需要投入大量精力去维护一个并非核心功能的、针对第三方项目的适配代码。问题排查链路冗长当用户在K8s集群中遇到容器相关的问题时排查链路变得异常复杂。问题可能出在kubelet、dockershim、dockerd、containerd或runc的任何一个环节。社区支持人员需要精通整个调用栈这极大地增加了故障诊断的难度。阻碍创新与优化dockershim的存在使得K8s无法直接利用更底层的容器运行时如containerd的新特性。任何优化都需要经过Docker Engine API和dockershim这两层转换效率低下且可能无法实现。3.2 一个关键的认知转变Docker ! 容器标准在容器生态发展的早期Docker几乎成了容器的代名词。但社区逐渐意识到这种绑定对生态的健康不利。为了推动容器技术的标准化和互操作性Linux基金会牵头成立了OCI。OCI制定了两个核心规范镜像规范定义了容器镜像的格式如层、配置清单。Docker镜像格式后来捐赠并演化成了OCI镜像标准。运行时规范定义了容器运行时的标准runc是其参考实现。这意味着只要符合OCI标准任何容器运行时都可以运行任何OCI镜像。Docker只是第一个成功实现了这套标准的平台但它并不是标准本身。Kubernetes通过CRI接口希望能够与任何符合OCI标准的容器运行时对接而不是绑定在Docker这一家实现上。dockershim的存在使得K8s在事实上与Docker引擎强耦合这与K8s追求开放、可插拔的架构目标背道而驰。3.3 更优的替代方案已经成熟当dockershim的维护成本越来越高时它的替代品已经变得非常成熟和稳定。containerd这原本就是Docker引擎内部使用的容器运行时。它本身就是一个实现了CRI接口的、功能完备的容器运行时。相比于完整的Docker引擎containerd更加轻量、专注只管理容器生命周期和镜像并且由CNCF托管与Kubernetes同属一个基金会目标和路线图更容易对齐。CRI-O这是Red Hat主导的、专门为Kubernetes设计的容器运行时。它的设计目标非常纯粹以最少的代码、最高的效率实现CRI接口。它直接使用runc运行容器使用buildah构建镜像整个栈都非常精简。使用containerd或CRI-Okubelet与容器运行时的交互链路变得非常简洁kubelet- (通过CRI gRPC接口) -containerd/CRI-O-runc移除了dockershim和dockerd这两个中间层架构更清晰依赖更少性能更优稳定性也更好。对于Kubernetes项目来说放弃一个沉重的历史包袱拥抱更简洁、更标准的架构是一个再自然不过的技术决策。4. 迁移实战从Docker到Containerd的平滑过渡理论讲清楚了我们落到实操上。如果你正在管理一个使用Docker作为运行时的K8s集群该如何安全、平滑地迁移到containerd呢这个过程需要谨慎操作但步骤是清晰的。下面我以一个典型的、使用kubeadm搭建的集群为例拆解迁移的全过程。重要提示生产环境迁移前务必在测试环境充分验证并制定详细的回滚方案。确保你对整个集群有完整的备份包括etcd数据。4.1 迁移前的准备工作与检查迁移不是简单地卸载Docker安装containerd首先要确保集群和节点处于一个可迁移的状态。检查Kubernetes版本确保你的Kubernetes版本在1.20以上1.20版本开始默认不再内置dockershim1.24版本正式移除。使用kubectl version确认。检查节点状态确保所有节点状态都是Ready并且没有异常的Pod。使用kubectl get nodes和kubectl get pods -A查看。识别有状态工作负载特别关注使用hostPath卷、DaemonSet或者对节点文件系统有特殊依赖的Pod例如某些监控Agent、日志收集器如Fluentd、存储插件如Ceph RBD。这些Pod在容器运行时变更时最容易出问题可能需要特殊的处理或重启顺序。备份关键配置备份每个节点上的Kubelet服务配置文件通常是/var/lib/kubelet/kubeadm-flags.env或/etc/systemd/system/kubelet.service.d/10-kubeadm.conf以及/etc/containerd/config.toml如果存在。4.2 关键一步配置Containerd在安装containerd之前我们先准备好它的配置文件。这是迁移成功的关键很多坑都出在这里。安装containerd通过系统包管理器安装。例如在Ubuntu上sudo apt-get update sudo apt-get install -y containerd生成默认配置containerd安装后默认没有配置文件我们需要生成一个。sudo mkdir -p /etc/containerd sudo containerd config default | sudo tee /etc/containerd/config.toml修改关键配置编辑/etc/containerd/config.toml有几个地方必须调整。配置Systemd Cgroup驱动Kubernetes推荐使用systemd作为cgroup驱动与kubelet保持一致。找到[plugins.io.containerd.grpc.v1.cri.containerd.runtimes.runc.options]部分确保SystemdCgroup true。[plugins.io.containerd.grpc.v1.cri.containerd.runtimes.runc.options] SystemdCgroup true配置私有镜像仓库如果你的集群使用私有镜像仓库如Harbor, Quay需要在这里配置auth。找到[plugins.io.containerd.grpc.v1.cri.registry]部分进行配置。[plugins.io.containerd.grpc.v1.cri.registry] [plugins.io.containerd.grpc.v1.cri.registry.mirrors] [plugins.io.containerd.grpc.v1.cri.registry.mirrors.docker.io] endpoint [https://registry-1.docker.io] [plugins.io.containerd.grpc.v1.cri.registry.mirrors.harbor.mycompany.com] endpoint [https://harbor.mycompany.com] [plugins.io.containerd.grpc.v1.cri.registry.configs] [plugins.io.containerd.grpc.v1.cri.registry.configs.harbor.mycompany.com.auth] username your-username password your-password配置Sandbox镜像Pod的基础设施容器Pause容器镜像需要指定。通常kubelet会配置但这里也可以设置。确保镜像地址可拉取。重启containerd应用配置。sudo systemctl daemon-reload sudo systemctl restart containerd sudo systemctl enable containerd4.3 切换Kubelet的容器运行时现在告诉kubelet不要再通过dockershim找Docker了直接使用containerd的CRI接口。修改kubelet配置编辑kubelet的启动参数文件。对于kubeadm管理的集群通常是/var/lib/kubelet/kubeadm-flags.env。sudo vi /var/lib/kubelet/kubeadm-flags.env找到KUBELET_KUBEADM_ARGS这一行修改--container-runtime和--container-runtime-endpoint参数。注意不同K8s版本参数可能不同。对于1.23及以下版本可能需要移除--container-runtimedocker并添加--container-runtimeremote和--container-runtime-endpointunix:///run/containerd/containerd.sock。对于1.24及以上版本--container-runtime参数已被移除只需确保--container-runtime-endpointunix:///run/containerd/containerd.sock存在。一个修改后的示例可能看起来像这样KUBELET_KUBEADM_ARGS--container-runtime-endpointunix:///run/containerd/containerd.sock ...其他原有参数...重启kubeletsudo systemctl daemon-reload sudo systemctl restart kubelet验证切换在节点上执行sudo crictl ps如果能看到当前运行的容器列表主要是pause容器和你的业务容器说明crictlCRI兼容的CLI工具已经能通过CRI接口与containerd通信了。同时在Master节点上该节点的状态应很快恢复为Ready。4.4 处理Docker与镜像迁移现在容器运行时已经切换但节点上还装着Docker之前用Docker拉取的镜像也在Docker的存储目录里。镜像导出与导入可选但推荐containerd和Docker默认使用不同的存储目录。为了不让Pod因镜像不存在而重新拉取尤其对于大镜像或私有仓库可以手动迁移镜像。使用docker save导出镜像为tar包然后用ctrcontainerd的CLI或crictl导入。但更通用的做法是让Pod自己触发拉取或者使用ctr images pull直接从仓库拉取。卸载Docker谨慎确认所有业务Pod运行正常且新创建的Pod也能成功调度到该节点后可以考虑卸载Docker。但建议观察一段时间如24小时后再操作。sudo apt-get purge -y docker-ce docker-ce-cli注意卸载Docker不会删除/var/lib/docker下的镜像和容器数据这些数据已经没用了可以手动清理以释放空间。4.5 迁移后的验证与常见问题排查迁移完成后必须进行全面的验证。基础功能验证kubectl get nodes节点状态应为Ready。kubectl get pods -A所有Pod应处于Running或Completed状态无异常重启。部署一个简单的测试Pod如kubectl run test --imagenginx:alpine确认能正常创建和运行。网络与存储验证测试那些依赖网络和存储的Pod确保Service发现、Ingress、PVC挂载等功能正常。常见问题与排查命令Pod卡在ContainerCreating使用kubectl describe pod pod-name查看事件。常见原因是镜像拉取失败检查containerd的registry配置或containerd的CRI插件未正确加载检查/etc/containerd/config.toml和containerd日志sudo journalctl -u containerd。节点状态为NotReady检查kubelet日志sudo journalctl -u kubelet -f常见错误是--container-runtime-endpoint路径不正确或containerd.sock权限问题。使用crictl调试crictl是你的新朋友。常用命令sudo crictl ps # 查看容器 sudo crictl images # 查看镜像 sudo crictl logs 容器ID # 查看容器日志 sudo crictl inspect 容器ID或Pod沙箱ID # 查看详情5. 深入对比Containerd vs Docker在K8s下的真实差异迁移之后作为集群管理员你会感受到哪些具体的变化下面我们从运维和开发的不同视角来对比一下使用containerd和之前使用Docker的差异。5.1 运维视角更轻量、更稳定、更“K8s原生”资源占用显著降低这是最直观的感受。containerd的二进制文件更小内存占用更少因为它剥离了Docker Daemon的众多非核心功能如API Server、构建引擎、Swarm模式等。这意味着节点可以将更多资源留给业务Pod。进程树更简洁在节点上运行ps aux | grep -E \(docker|containerd)\你会看到dockerd这个庞然大物消失了只剩下containerd进程。少了一个守护进程就意味着少了一个潜在的故障点和攻击面。启动速度更快containerd的启动速度比dockerd快这对于节点重启或故障恢复的场景有益。日志与监控的变更这是需要适应的地方。之前我们习惯用docker logs命令查看容器日志现在则需要通过kubectl logs或者到节点上使用crictl logs。容器日志的存储位置也从/var/lib/docker/containers/...变为了containerd管理的区域通常可通过crictl inspect找到路径。监控方面之前针对Docker Daemon的监控指标如engine_daemon_container_actions_seconds_sum不再可用需要转向监控CRI接口暴露的指标或使用cAdvisor它现在直接通过CRI收集容器数据。调试命令的变化运维人员需要熟悉一套新的CLI工具链crictl替代大部分docker命令用于调试容器和Pod。但它不是完全一一对应功能更聚焦于CRI。ctrcontainerd的底层管理工具功能强大但更偏底层一般用于管理命名空间、镜像等日常运维较少直接使用。nerdctl一个兼容Docker CLI语法的containerd客户端对于从Docker迁移过来的用户非常友好几乎可以无缝切换命令习惯如nerdctl ps,nerdctl images。5.2 开发者视角几乎无感但需了解底层变化对于大多数应用开发者而言这次迁移几乎是透明的这恰恰证明了K8s和CRI设计的成功。Dockerfile与镜像完全兼容你之前写的所有Dockerfile构建出来的镜像在containerd运行时上完全无需修改即可运行。因为两者都遵循OCI标准。你的CI/CD流水线中docker build和docker push的步骤可以原封不动。docker命令的替代在开发环境中你当然可以继续使用Docker Desktop或Docker Engine来构建和测试镜像。只是在连接到K8s集群进行一些底层调试时需要从docker命令切换到kubectl或crictl。例如以前在节点上排查问题可能会用docker exec进入容器现在更标准的做法是kubectl exec。镜像构建的分离K8s的这次变更进一步明确了“构建”和“运行”的边界。Kubernetes是一个容器编排和运行平台它不关心镜像如何构建。镜像构建是CI/CD工具如Jenkins、GitLab CI、Tekton等和镜像构建工具如Docker、Buildah、Kaniko等的职责。这种分离让系统架构更清晰。5.3 性能与稳定性提升理论上的优势如何体现理论上移除dockershim层可以减少一次网络序列化/反序列化gRPC - Docker API和进程间通信的开销从而降低延迟。但在大多数常规负载下这种性能提升可能微乎其微不易被直接感知。真正的稳定性提升体现在依赖简化链路更短组件更少出错的概率自然降低。问题隔离当出现容器运行时问题时排查范围更聚焦于containerd和CRI无需再考虑Docker Daemon的复杂状态。社区支持containerd是CNCF毕业项目与Kubernetes由同一个社区紧密协作问题修复和特性迭代的协同性更好。6. 不止于ContainerdCRI生态与未来展望K8s放弃Docker运行时不仅仅是换了一个默认选项更是拥抱了一个基于CRI的、充满活力的容器运行时生态。6.1 CRI的“参考实现”CRI-O如果说containerd是出身于Docker世家、功能全面的“优等生”那么CRI-O就是专为Kubernetes而生的“特长生”。它的设计哲学是“仅实现CRI别无其他”。因此它比containerd更加轻量组件更少直接使用runc和conmon安全边界可能更清晰遵循最小权限原则。Red Hat的OpenShift容器平台就默认使用CRI-O。对于追求极致精简和与K8s版本严格锁定的环境CRI-O是一个非常好的选择。6.2 安全容器的崛起Kata Containers与gVisorCRI标准化的另一个巨大好处是为安全容器这类特殊的运行时打开了大门。传统容器如runc创建与宿主机共享内核存在潜在的安全风险。安全容器通过不同的技术路径如轻量级虚拟机、系统调用拦截来提供更强的隔离。Kata Containers通过轻量级虚拟机MicroVM来隔离每个Pod每个Pod拥有独立的内核。它通过containerd的shimv2接口与K8s集成对用户而言只需在Pod的runtimeClassName中指定kata即可使用。gVisorGoogle推出的容器沙箱它通过一个用Go语言实现的、模拟Linux内核的“哨兵”Sentry来拦截容器的系统调用提供一种折中的安全与性能方案。它同样实现了CRI。这些运行时可以无缝接入Kubernetes为不同安全等级的工作负载提供灵活的选择。如果没有标准的CRI接口这种集成将异常困难。6.3 对云原生生态的深远影响这次变革巩固了Kubernetes作为容器编排领域事实标准的地位。它向生态传递了一个明确信号K8s定义接口CRI社区提供实现。这鼓励了更多创新在运行时层面发生而不会威胁到上层编排的稳定性。对于开发者而言这意味着我们应该更多地关注开放标准如OCI镜像、CRI而不是某个特定的厂商实现。你的技能投资应该放在如何编写高效的Dockerfile、如何设计云原生应用、如何用好Kubernetes API上而不是深究某个容器运行时CLI工具的冷门参数。最后回顾整个历程K8s放弃Docker运行时不是一个时代的结束而是一个更成熟、更开放时代的开始。它剥离了历史的包袱让架构回归简洁和专注。作为从业者理解其背后的技术逻辑掌握迁移和运维的新工具我们就能更好地驾驭这片云原生的浪潮而不是被它所困扰。当你下次再遇到类似“K8s为什么用containerd而不用Docker”的疑问时你可以从容地从CRI接口、架构解耦和生态演进的角度给出一个清晰的解答。