docker守护进程不直接操作内核，而是通过containerd调用runc，由runc执行clone()、mount()、cgroup设置等系统调用；镜像依赖overlayfs内核模块，网络依赖netlink和nf_nat，安全机制靠prctl/capset由内核强制实施。
Docker 守护进程（dockerd）本身不直接操作 Linux 内核，而是通过分层调用容器运行时组件，最终借助内核原语完成隔离与资源控制。理解这个交互过程，关键在于看清“谁在调用内核、调什么、怎么调”。
守护进程不碰内核，只调度运行时
dockerd 是一个高层协调者，它不创建命名空间、不设置 cgroup、不挂载 overlayfs。它收到 docker run 等命令后，会把具体执行任务委托给底层运行时：
- 先将请求转给
containerd（Docker 官方维护的工业级容器运行时守护进程）； -
containerd再调用runc（符合 OCI 规范的轻量级命令行工具）； -
runc才真正调用clone()、unshare()、mount()、setns()等系统调用，直接与内核交互。
比如启动一个容器时：
-
runc用clone(CLONE_NEWPID | CLONE_NEWNS | CLONE_NEWNET ...)创建新命名空间； - 用
pivot_root()或mount(..., MS_MOVE)搭建 rootfs； - 用
cgroups v2的io.max、memory.max等接口限制资源； - 最终
execve()启动用户指定的进程（如/bin/sh），该进程成为新 PID 命名空间里的 init 进程（PID 1）。
镜像层与存储驱动依赖内核特性
守护进程管理镜像时，也不直接读写磁盘，而是通过 graphdriver（如 overlay2）驱动调用内核功能：
-
overlay2依赖内核 4.0+ 的 overlayfs 文件系统支持； - 它在
upperdir/workdir/merged三层结构上做联合挂载，所有mkdir、open等文件操作都经由内核 overlayfs 模块处理； - 若内核未启用
CONFIG_OVERLAY_FS=y，dockerd启动会失败或降级使用vfs（性能极差）。
网络配置靠 netns + 内核网络栈
当 docker run -p 8080:80 时：
-
dockerd→containerd→runc创建带CLONE_NEWNET的网络命名空间； -
dockerd调用netdriver（如bridge插件），执行ip link add vethXXX type veth、brctl addif docker0 vethXXX等命令； - 所有这些命令最终触发内核的
netlink接口和dev_ioctl()，配置网桥、ARP 表、iptables/NFTables 规则； - 端口映射实际由内核
nf_nat模块在PREROUTING链完成 DNAT。
安全机制本质是内核能力管控
docker run --cap-drop=NET_RAW --security-opt no-new-privileges 这类选项：
-
dockerd解析后传给runc； -
runc在execve前调用prctl(PR_SET_NO_NEW_PRIVS, 1)和capset()系统调用； - 内核据此拒绝后续
setuid、raw socket创建等特权操作，不是 Docker 自己拦截，而是内核强制 enforce。
不复杂但容易忽略
