Docker客户端与服务端天然分离，客户端仅解析命令、封装REST API请求并格式化响应，不执行任何容器操作；服务端（dockerd）作为守护进程，负责调用内核能力管理容器全生命周期。
Docker 客户端与服务端是天然分离的两个角色，不是为了桌面版“加出来的”，而是整个 Docker 生态从第一天就定下的设计原则。
客户端只管“说话”，不管“做事”
你敲的 docker run、docker build、docker ps 都是在调用客户端程序。它只做三件事：
- 解析命令和参数，比如检查 -p 80:80 格式是否合法
- 把请求打包成标准 REST API（例如 POST /containers/create），通过 Unix socket 或 TCP 发出去
- 收回来的 JSON 响应，格式化成表格或文字输出给你看
它不拉镜像、不启容器、不操作内核——连 docker info 返回的 Server 字段，都在告诉你：这信息来自服务端，不是客户端自己算的。
服务端才是真干活的“后台”
Docker Daemon（也就是 dockerd）是常驻后台的守护进程，职责非常明确：
- 监听客户端请求（默认走 /var/run/docker.sock 这个本地 socket）
- 调用 Linux 内核能力：创建 namespace 隔离环境、用 cgroups 限资源、加载 overlay2 文件系统
- 管理镜像层、容器状态、网络配置、卷数据等所有运行时对象
哪怕你在一台机器上装 Docker Desktop 或原生 Docker Engine，客户端和服务端也仍是独立进程——只是恰好部署在同一台宿主机上。
分离架构带来的实际好处
这种 C/S 拆分不是为了炫技，而是解决真实问题：
- 远程控制：改一个 DOCKER_HOST 环境变量，本地 docker 命令就能操作远端服务器上的容器
- 权限隔离：客户端进程无需 root 权限，但服务端必须以 root 运行才能操作内核；普通用户可通过 group 加入 docker 组获得有限访问权
- 多语言接入：Python、Go、Java 都能直接发 HTTP 请求调用 Docker API，不依赖命令行工具
- 桌面版兼容性：Windows/macOS 没有原生 Linux 容器支持，Docker Desktop 就靠内置轻量 Linux 虚拟机跑 dockerd，客户端仍保持一致行为
怎么验证它们确实是分开的？
几个简单命令就能看到端倪：
- ps aux | grep dockerd —— 找到服务端进程（通常叫 dockerd）
- ps aux | grep docker —— 客户端命令执行完就退出，不会长期驻留
- docker context ls —— 显示当前连接的是本地还是远程服务端
- curl --unix-socket /var/run/docker.sock http://localhost/info —— 绕过客户端，直接和服务端 API 对话
不复杂但容易忽略。
