Docker 采用C/S架构，执行docker run nginx时：CLI发HTTP请求→dockerd调度→containerd管理→runc调用内核接口创建隔离进程，全程依赖namespace、cgroups和OverlayFS实现隔离、资源控制与分层存储。
学 Docker 容器运行原理架构，关键不是背组件名字，而是理清“命令发出去后，系统里到底发生了什么”。从一条 docker run nginx 开始，顺着数据流一层层往下看，就能自然串起整个架构。
从命令出发，抓住主干流程
用户输入命令 → CLI 发 HTTP 请求 → dockerd 接收 → 转给 containerd → containerd 调用 runc → runc 调内核接口创建隔离进程。这条链就是核心脉络。建议先画一张简图，标出每个环节的输入输出（比如 containerd 收到的是容器配置 JSON，runc 执行的是 config.json + rootfs 路径），比死记术语更有效。
重点理解三个角色的分工
dockerd：不直接跑容器，只做调度和 API 网关。它管镜像拉取、网络插件加载、用户权限校验，但真正启停容器的事全交给 containerd。
containerd：真正的“容器管家”。它负责镜像解压、生成 OCI runtime spec、调用 runc、管理容器状态、处理日志和存储卷。它的设计目标是稳定、可嵌入、不绑定 Docker —— 所以 Kubernetes 也用它。
runc：最小、最薄的一层。它只做一件事：按 OCI 规范，用 clone()、mount()、setns() 等系统调用，把进程塞进 namespace 和 cgroups 里。它不联网、不存镜像、不处理日志，纯粹是内核能力的封装。
MiniMax 图片理解 + 网络搜索 MCP 工具。适配 Docker 环境（极空间等），支持图片 OCR 识别、图像内容理解、网络搜索。API Key 安全存储在本地 credentials 文件，不暴露在代码中。
结合 Linux 底层机制看隔离与资源控制
光知道组件不够，得明白它们靠什么干活：
- Namespace 提供“视图隔离”：pid、net、mnt、uts、ipc 各自独立，让容器以为自己独占一套系统
- Cgroups 提供“资源限制”：CPU shares、memory limit、blkio weight 等参数最终落到 /sys/fs/cgroup 下的文件
- OverlayFS 提供“分层写入”：镜像层只读，容器启动时叠加一个可写 upperdir，所有修改都在这层，不影响底层
动手试一试：ls /proc/<pid>/ns 查看某个容器进程的命名空间，cat /sys/fs/cgroup/memory/docker/<id>/memory.max 看内存限制值 —— 这些不是抽象概念，是真实存在的文件和路径。
用调试工具验证理解
别只读文档，用工具把流程“看见”：
- 加
-D启动 dockerd，观察日志中各组件通信细节 - 用
ctr --address /run/containerd/containerd.sock containers list直连 containerd，绕过 Docker CLI 查容器状态 - 进容器执行
cat /proc/1/cgroup和ls /proc/1/ns，确认隔离是否生效
遇到报错（比如 “OCI runtime create failed”），先查 containerd 日志，再看 runc 是否能手动运行 config.json —— 这样排查才不盲人摸象。
