基本架构

核心架构图

Docker 采用了 C/S (客户端/服务端) 架构。Client 向 Daemon 发送请求，Daemon 负责构建、运行和分发容器。

┌───────────────┐     ┌────────────────────────────────────┐
│   客户端      │     │            Docker Host             │
│ (Docker CLI)  │     │                                    │
│               │     │  ┌──────────┐      ┌────────────┐  │
│  $ docker run ├────►│  │ dockerd  │      │ Containers │  │
│  $ docker pull│     │  │ (Daemon) │─────►│            │  │
│  $ docker ps  │     │  └────┬─────┘      │  □    □    │  │
└───────────────┘     │       │            └────────────┘  │
                      │       │            ┌────────────┐  │
                      │       └───────────►│   Images   │  │
                      │                    │            │  │
                      └────────────────────┴────────────┘  │

---

组件详解

Docker 的内部架构如同洋葱一样分层，每一层专注解决特定问题：

1. Docker CLI (客户端)

用户与 Docker 交互的主要方式。它将用户命令（如 docker run）转换为 API 请求发送给 dockerd。

2. Dockerd (守护进程)

Docker 的大脑。

• 监听 API 请求

• 管理 Docker 对象（镜像、容器、网络、卷）

• 编排下层组件完成工作

3. Containerd (高级运行时)

行业标准的容器运行时（CNCF 毕业项目）。

• 管理容器的完整生命周期（启动、停止）

• 镜像拉取与存储

• 不包含 复杂的与容器无关的功能（如构建、API）

• Kubernetes 也可以直接使用 containerd（跳过 Docker）

4. Runc (低级运行时)

用于创建和运行容器的 CLI 工具。

• 直接与内核交互（Namespaces, Cgroups）

• 遵循 OCI (Open Container Initiative) 规范

• 主要职责：根据配置启动一个容器，然后退出（将控制权交给容器进程）

5. Shim

每个容器都有一个 shim 进程。

• 解耦：允许 dockerd 重启而不影响容器运行

• 保持 IO：维持容器的标准输入输出

• 状态汇报：向 containerd 汇报容器退出状态

---

容器启动流程

当执行 docker run -d nginx 时，内部发生了什么？

User
 │
 ▼
Docker CLI  ──(REST API)──> Dockerd
                               │
                               ▼
                          Containerd ──(gRPC)──> Containerd-shim
                                                      │
                                                      ▼
                                                     Runc
                                                      │
                                                      ▼
                                                 Kernel (创建容器)
                                                (Start & Exit)

1. CLI 发送请求给 Dockerd

2. Dockerd 解析请求，调用 Containerd

3. Containerd 准备镜像，转换为 OCI Bundle

4. Containerd 创建 Shim 进程

5. Shim 调用 Runc

6. Runc 与系统内核交互，创建 Namespaces 和 Cgroups

7. Runc 启动 nginx 进程后退出

8. Shim 接管容器 IO 和生命周期监控

---

Docker Engine v29+ 变化

从 Docker Engine v29 (2025/2026) 开始，架构进一步简化和标准化：

• Containerd 镜像存储 (Image Store)：默认启用。Docker 直接使用 Containerd 的镜像管理能力，不再维护自己的一套 graphdriver。

  • 优势：多平台镜像支持更好、镜像拉取更快（lazy pulling）、与 K8s 共享镜像。

---

Docker Desktop 架构

在 macOS 和 Windows 上，因为内核差异，架构稍微复杂：

┌────────────── MacOS / Windows ──────────────┐
│  Docker CLI                                 │
│      │                                      │
├──────┼──────────────────────────────────────┤
│      ▼ (Socket 映射)                        │
│ ┌────────── Linux VM (虚拟机) ───────────┐  │
│ │                                        │  │
│ │  Dockerd <--> Containerd <--> Runc     │  │
│ │                                        │  │
│ └────────────────────────────────────────┘  │
└─────────────────────────────────────────────┘

• 使用轻量级虚拟机（Apple Virtualization / WSL 2）运行 Linux 内核

• 文件挂载（Bind Mount）需要跨越 VM 边界（这也是文件 I/O 慢的原因）

• 网络端口需要从宿主机转发到 VM

---

总结

组件	角色	关键职责
CLI	指挥官	发送指令，展示结果
Dockerd	大管家	API 接口，整体调度
Containerd	经理	容器生命周期，镜像管理
Shim	监工	保持 IO，允许无守护进程重启
Runc	工人	真正干活（创建容器），干完就走

延伸阅读

• 命名空间：Runc 如何隔离容器

• 控制组：Runc 如何限制资源

• 联合文件系统：镜像如何存储