docker engine由cli/api、dockerd、containerd和runc四层组件协同构成：cli/api负责人机交互，dockerd为总指挥处理请求，containerd专注容器生命周期管理，runc则调用内核接口实现容器运行。
Docker Engine 不是单个程序，而是一套协同工作的组件集合，它的设计目标是把“构建镜像”和“运行容器”这两件事可靠、可复用、可移植地完成。理解它，关键不是背名词，而是看清每个部分在整条工作流里承担什么角色。
dockerd：后台干活的总指挥
dockerd 是 Docker Engine 的核心守护进程，常驻后台，真正执行所有重活——拉取镜像、解压分层、创建命名空间、配置 cgroups、挂载文件系统、启动 init 进程。你敲下的每一条 docker run、docker build 命令，最终都由它解析并落地为 Linux 内核操作。它通过本地 Unix socket 或远程 API 接收请求，不直接面向用户，但决定一切是否能跑起来。
containerd：专注容器生命周期的中间层
从 Docker 18.06 开始，dockerd 不再直接管理容器运行时，而是把这部分职责交给 containerd。它是一个更轻量、更专注的守护进程，负责： - 创建和销毁容器（调用 runc） - 管理容器的启停、状态监控、OOM 处理 - 处理镜像的拉取、存储与解包（配合 containerd-shim） 简单说，dockerd 负责“我要做什么”，containerd 负责“怎么安全、稳定地做完”。这种分层让 Docker 更易维护，也方便对接其他运行时（如 CRI-O）。
runc：真正运行容器的内核接口封装
runc 是一个符合 OCI（Open Container Initiative）标准的命令行工具，它直接调用 Linux 内核的 clone()、setns()、mount() 等系统调用，完成： - 创建新的 pid、net、mnt、uts 等 namespace - 将进程加入指定 cgroup 控制组 - 设置 rootfs、capabilities、seccomp 等安全策略 你可以把它看作是“Linux 容器能力”的最小可行封装——没有它，containerd 就无法真正跑起一个隔离进程。
CLI 和 REST API：人机交互的统一入口
docker 命令行工具（CLI）本身不执行任何容器逻辑，它只是个客户端，把你的指令格式化成 HTTP 请求，发给 dockerd 的 REST API。这意味着： - 你可以在本地写脚本调用 curl http://localhost:2375/containers/json 获取容器列表 - CI/CD 工具或 Web 控制台也可以绕过 CLI，直连 API 实现自动化 - 所有功能都有对应接口，没有“命令有、API 没有”这种割裂
这四层结构——CLI/API → dockerd → containerd → runc——层层下沉，各司其职。上层提供易用性，下层保证可靠性与标准化。搞懂这个链条，就抓住了 Docker Engine 的骨架。
