docker标准架构是围绕“可靠、一致、高效运行应用”构建的协作机制：cli为用户入口，daemon为指挥中心，containerd负责容器生命周期，runc调用内核实现隔离，镜像、容器、仓库构成数据闭环。
Docker 容器技术的标准架构，不是一堆名词堆砌，而是围绕“怎么把应用可靠、一致、高效地运行起来”这一目标组织起来的一套协作机制。学它，关键不是背组件名，而是理清每个部分“干什么、为什么需要它、它和别的部分怎么配合”。
Docker CLI：你和 Docker 世界的对话窗口
这是你每天敲 docker run、docker build 的命令行工具。它本身不干活，只负责把你的指令发给后台服务。就像遥控器——按哪个键，得有电视（daemon）响应才行。安装 Docker Desktop 或 Linux 上的 docker-ce 后，CLI 就自动有了。验证是否正常：docker version 能同时看到 client 和 server 版本，说明通信通了。
Docker Daemon（dockerd）：整个系统的指挥中心
它在后台默默运行（Linux 上是 dockerd 进程，Mac/Windows 是 Desktop 内嵌的服务），真正管理镜像加载、容器启停、网络配置、存储卷挂载。所有 CLI 命令最终都通过 REST API 找到它。你不需要手动启动它（开机自启），但要知道：如果 docker ps 报错 “Cannot connect to the Docker daemon”，八成是它没起来，或者权限不对（Linux 需要加 sudo 或把用户加入 docker 组）。
Containerd：专注容器生命周期的工业级运行时
Docker Daemon 不直接创建容器，而是把任务委托给 containerd。它更稳定、更轻量，是符合 OCI（开放容器倡议）标准的独立项目。你可以把它看作“专业外包团队”——Daemon 下单，containerd 接单、调度、监控容器状态。日常开发几乎不直接操作它，但理解它的存在，能帮你区分“Docker 特性”和“容器通用能力”。
runc：真正让容器跑起来的最后一环
它是 OCI 标准的参考实现，负责调用 Linux 内核的 namespace 和 cgroup 功能，实际创建隔离的进程环境。比如 runc run mycontainer 能绕过 Docker 直接起一个容器（需先用 runc spec 生成配置）。学架构时知道它在底层“干脏活”，就明白 Docker 的轻量本质来自内核原生支持，而不是自己造轮子。
镜像、容器、仓库：数据流的三个关键节点
- 镜像是静态模板，分层只读，靠
Dockerfile构建，docker build产出； - 容器是镜像的动态实例，可读写层叠加在镜像之上，
docker run启动； - 仓库（如 Docker Hub 或私有 Registry）是镜像的“云盘”，
docker push/pull实现共享与分发。
这三者构成闭环：写好 Dockerfile → 构建镜像 → 推送到仓库 → 在任意机器拉取并运行成容器。
基本上就这些。架构不复杂，但容易忽略各层之间的职责边界。动手跑一次 docker run hello-world，再查 ps aux | grep dockerd 和 ps aux | grep containerd，就能直观看到它们如何协同工作。
