真正掌握docker原理的关键在于理解客户端与守护进程间“谁发指令、谁干活、怎么通信、问题在哪断”的逻辑链：客户端仅转发api请求，dockerd负责调度containerd/runc、管理网络与cgroups，通信通过unix套接字或tls加密tcp完成，全过程可观察、验证、调试。
要真正掌握 docker 客户端与守护进程原理，关键不是死记命令或配置项，而是理解它们之间“谁发指令、谁干活、怎么通信、出了问题在哪断”的逻辑链条。下面从四个实际角度切入，帮你把原理落到可观察、可验证、可调试的层面。
看清通信路径：客户端和守护进程到底怎么“对话”
客户端（如 docker run）本身不创建容器，它只是个“传话员”。真正干活的是后台的 dockerd 进程。两者靠一套明确的通信通道连接：
- 默认走 Unix 套接字：
/var/run/docker.sock—— 本地最常用，权限由文件属组（通常是docker组）控制； - 远程管理时可启用 TCP 端口：
2375（明文，不推荐）或2376（需 TLS 证书）； - 你可以用
curl --unix-socket /var/run/docker.sock http://localhost/version直接绕过 CLI 调用守护进程 API，验证通信是否通畅； - 执行
docker info时，CLI 实际发出的是 HTTP GET /info 请求，守护进程返回 JSON 响应 —— 这就是 REST API 的真实体现。
拆解守护进程启动流程：它开机后到底做了什么
dockerd 不是简单跑起来就完事，它有一套清晰的初始化顺序，每一步都影响后续行为：
- 读取配置：先加载
/etc/docker/daemon.json（如有），设定镜像仓库、日志驱动、默认网络等； - 绑定监听地址：根据配置决定监听
unix:///var/run/docker.sock还是tcp://0.0.0.0:2376； - 初始化后端组件：启动
containerd子进程，再由它调用runc创建真正的容器； - 加载已有资源：扫描
/var/lib/docker下的镜像层、容器元数据、网络配置，恢复上次运行状态； - 你执行
sudo systemctl restart docker后，可以立刻用journalctl -u docker -f看到上述步骤逐条打印，比文档更直观。
跟踪一条命令的完整生命周期：以 docker run nginx 为例
这行命令背后是一次跨多层组件的协作，理清它等于看懂整个架构：
- CLI 解析命令，构造 HTTP POST 请求到
/containers/create，附带镜像名、端口映射等参数； - 守护进程收到后，检查本地是否有
nginx镜像；没有就自动调用image pull流程，连接 registry 下载； - 镜像就绪后，守护进程向
containerd发送创建容器请求，containerd再调用runc在命名空间中启动进程； - 网络方面，守护进程按配置调用
libnetwork插件，为容器分配 IP、设置 iptables 规则、挂接网桥； - 最后把容器 ID 返回给 CLI，CLI 再执行
start请求让它真正运行 —— 整个过程没有一行 shell 脚本参与，全是 API 和插件协作。
动手验证核心隔离机制：客户端看不见，但守护进程全在管
所谓“容器隔离”，不是 CLI 决定的，而是守护进程在调用内核接口时主动启用的。你可以这样验证：
- 运行一个容器：
docker run -d --name test alpine sleep 3600； - 查它的 PID：
docker inspect test -f '{{.State.Pid}}'，比如得到12345； - 进宿主机看这个进程的命名空间：
ls -l /proc/12345/ns/，会发现pid、net、mnt等链接指向不同 inode —— 这正是守护进程启动时让runc设置的； - 再看 cgroups：
cat /proc/12345/cgroup，路径里含docker/...，说明守护进程已把它加入对应资源限制组。
掌握这些，你就不再把 docker 当成黑盒命令，而是清楚每一环谁在响应、谁在调度、谁在落地。不需要背源码，但能看懂日志、改对配置、定位到具体组件的问题。
