moby 与 containerd 区别
它是什么Moby 是 Docker 发起的上游开源项目,提供一套可拼装的容器工具箱组件;
Moby 是 Docker 发起的上游开源项目,提供一套可拼装的容器工具箱组件;containerd 是被设计为 Docker、Kubernetes 等项目核心的容器运行时。本文从定位、接口、镜像缓存、配置路径与适用场景逐项对照,帮助你在节点运行时选型时做出判断。
详细介绍
简介
Moby 与 containerd 都是容器领域的开源项目,但定位并不相同:Moby 是 Docker 发起的上游开源项目,提供一套可自由拼装的容器工具箱组件;containerd 则被设计为 Docker、Kubernetes 以及许多其他项目的核心容器运行时。两者经常被放在一起比较,实际上更接近上下游与被集成的关系,而非同类竞品。这篇内容面向需要做容器运行时选型的运维工程师、平台工程与云原生开发者,从项目定位、接口标准、镜像缓存、配置文件与适用场景几个维度给出可核对的对照,核心优势是把「该直接用 containerd,还是保留 Docker/Moby 这一层」讲清楚,避免凭印象选型。
核心功能
- Moby 由 Docker 创建,用于推动和加速软件容器化,是 Docker 的上游项目,社区讨论中被描述为 upstream project。
- Moby 提供一套「Lego set」式的工具箱组件,组件可按需挑选与组合,用来搭建自己的容器引擎或集成进自有平台。
- containerd 被设计为 Docker、Kubernetes 以及许多其他项目的未来版本所使用的核心容器运行时,定位是被上层系统调用的底层能力。
- containerd 是从 Docker 项目中分离出来的高级容器运行时,之后被捐赠给云原生计算基金会,与 Docker 主干解耦演进。
- containerd 支持 OCI 标准,镜像与容器遵循开放容器规范,便于在不同运行时之间迁移镜像与配置。
- containerd 不支持 Docker API,依赖 docker 命令或 Docker HTTP 接口的工具无法直接对接它,需要改走 containerd 自身的接口。
- containerd 的配置文件位于 /etc/containerd/config.toml,服务单元为 containerd.service,配置项与生效方式在官方文档中有明确说明。
- Docker 与 containerd 不共享容器镜像缓存,切换运行时后镜像需要重新拉取,这一点在 containerd 社区讨论中被明确指出。
使用场景
- Kubernetes 生产集群的节点:Kubernetes 生产环境容器运行时文档要求在系统上安装 containerd,并按说明创建有效的 config.toml。
- 边缘计算节点:KubeEdge 的前置条件文档要求先安装 containerd,并在 /etc/containerd/ 下准备好配置文件,缺失时执行相应命令生成。
- 需要 Docker CLI 与 Docker API 生态的团队:保留 Docker 这一层,因为 containerd 不支持 Docker API,且 Docker 相比 containerd 多一层调用。
- 希望自组容器引擎或做深度定制的团队:使用 Moby 提供的工具箱组件按需拼装,而不是直接使用固定形态的运行时。
- 对延迟敏感的服务:社区讨论中提到 containerd 在延迟上应表现更好,可在目标负载下做压测对比后再定方案。
- 从 Docker 迁移到 containerd 的场景:需要重新规划镜像预热与磁盘占用,因为两者不共享容器镜像缓存。
安装与获取步骤
- 获取源码与文档:Moby 仓库位于 github.com/moby/moby,containerd 仓库位于 github.com/containerd/containerd,两者的 README 与官方站点给出当前可用的获取方式,具体版本以官方页面为准。
- 部署 containerd:按照 containerd 官方「Getting Started with containerd」的说明在目标系统上完成部署,并生成服务单元 containerd.service。
- 生成配置文件:检查 /etc/containerd/ 目录下是否已存在配置文件;若不存在,按 KubeEdge 前置条件文档给出的命令生成 config.toml。
- 核对配置内容:参照 Kubernetes 生产环境容器运行时文档确认 config.toml 中的运行时与 systemd 相关配置,保存后让 containerd.service 重新加载配置。
- 验证运行时可用:在 Kubernetes 节点上按 kubelet 所需的 CRI 接口进行连通性验证,确认节点状态正常后再接入业务负载。
- 获取 Moby 组件:从 github.com/moby/moby 获取「Lego set」工具箱组件清单,按目标平台挑选组件并自行组合,组合方式以官方仓库文档为准。
与 containerd 的区别对照
| 对照项 | Moby | containerd |
|---|---|---|
| 项目定位 | Docker 创建的上游开源项目,推动软件容器化 | 被设计为 Docker、Kubernetes 等项目的核心容器运行时 |
| 交付形态 | 一套可拼装的「Lego set」工具箱组件 | 从 Docker 项目分离出来的高层容器运行时 |
| 标准与接口 | 面向自组与定制容器引擎 | 支持 OCI 标准,不支持 Docker API |
| 在 Kubernetes 中的角色 | 非官方文档指定的节点运行时 | Kubernetes 与 KubeEdge 文档要求的节点运行时 |
| 镜像缓存 | 与 Docker 的关系以上游项目为主 | 与 Docker 不共享容器镜像缓存 |
| 调用层级 | 处于上游,组件被下游项目复用 | 被上层系统调用,Docker 相比它多一层调用 |
注意事项
- 不要把两者当作二选一的同类竞品:containerd 是被 Docker、Kubernetes 等项目复用的运行时,Moby 是提供组件的上游项目,判断依据是你要「用一个运行时」还是「组一套引擎」。
- 切换运行时后镜像不会自动带过去:Docker 与 containerd 不共享容器镜像缓存,需要重新拉取,容量规划与首次调度时间要重新估算。
- 依赖 docker 命令或 Docker HTTP API 的脚本、CI 插件在 containerd 环境下会直接失败,因为 containerd 不支持 Docker API,需提前改造调用方式。
- 配置文件路径为 /etc/containerd/config.toml,改动后要让 containerd.service 重新加载;若目录下没有该文件,先按文档生成再修改,避免手写缺失字段。
- 性能结论不要照抄社区说法:讨论中提到 containerd 在延迟上应表现更好,但结果依赖负载与硬件,应在自己的环境压测后再下结论。
- 本文未列出任何具体版本号、镜像大小与哈希,涉及版本与参数时一律以官方页面为准。
更新记录
最近更新:2026-10-04
软件参数速览
下载
常见问题
Moby 和 containerd 是二选一的关系吗?
不是。containerd 被设计为 Docker、Kubernetes 等项目的核心容器运行时,Moby 则是提供「Lego set」工具箱组件的上游项目,两者处于不同层次,选型依据是你需要一个现成运行时还是一套可拼装组件。
从 Docker 切到 containerd 后,之前拉取的镜像还在吗?
不在。containerd 社区讨论明确指出 Docker 和 containerd 不共享容器镜像缓存,切换后镜像需要重新拉取,要重新评估磁盘占用、预热时间与首次调度延迟。
依赖 docker 命令或 Docker API 的脚本能直接在 containerd 上跑吗?
不能。containerd 支持 OCI 标准但不支持 Docker API,相关脚本需改为调用 containerd 自身接口,或在节点上保留 Docker 这一层,因为 Docker 相比 containerd 多一层调用。
containerd 的配置文件放在哪里,缺失时怎么办?
配置文件位于 /etc/containerd/config.toml。KubeEdge 文档指出若 /etc/containerd/ 目录下没有配置文件,可执行文档给出的命令生成,再按 Kubernetes 生产环境文档调整其中的运行时与 systemd 配置。
Kubernetes 节点上应该选 Moby 还是 containerd?
Kubernetes 生产环境容器运行时文档与 KubeEdge 前置条件文档要求的都是 containerd,Moby 并未被列为节点运行时;具体版本与参数以官方页面为准。
containerd 和 Docker 谁的延迟表现更好?
containerd 社区讨论中提到 containerd 在延迟上应表现更好,且 Docker 相比 containerd 多一层调用;但结论依赖负载与硬件,应在自己的环境压测后再决定。
想自己拼一个容器引擎,应该看哪个项目?
看 Moby。它由 Docker 创建,提供一套「Lego set」工具箱组件供按需组合,是 Docker 的上游项目,适合做定制化容器引擎或把容器能力集成进自有平台。
containerd 是从哪来的,和 Docker 什么关系?
containerd 是从 Docker 项目中分离出来的高级容器运行时,之后被捐赠给云原生计算基金会;它被设计为 Docker、Kubernetes 及许多其他项目的核心容器运行时,与 Docker 主干解耦演进。