Docker容器隔离依赖Linux内核的namespace和cgroups机制：namespace实现六类资源逻辑隔离（PID、NET、UTS、IPC、MNT、USER），cgroups实现CPU、内存等资源用量限制，二者协同构成轻量级隔离环境。
直接从 Linux 内核机制入手最有效。Docker 的隔离不是 Docker 自己发明的，而是调用内核已有的 namespace 和 cgroups 接口实现的。学清楚底层原理，才能真正理解容器为什么“轻量”、为什么“隔离”，而不是只记命令。
先搞懂六类核心命名空间的作用
每个 namespace 负责隔离一类资源，Docker 默认启用其中五种（user namespace 需手动开启）：
-
PID namespace：让容器内进程 PID 从 1 开始编号，看不到宿主机和其他容器的进程；
docker run --pid=host可关闭隔离，用于调试 - NET namespace：给容器配独立网卡、IP、路由表和端口空间；bridge 模式下通过 veth pair 连到 docker0 网桥
-
UTS namespace：隔离主机名和域名；
docker run -h myapp就是改这个命名空间里的 hostname - IPC namespace：阻止容器间用共享内存、信号量等 System V IPC 通信，默认开启，增强安全性
-
MNT namespace：隔离挂载点；容器里
mount不会影响宿主机，镜像层和 volume 也依赖它 - User namespace：把容器内 root 映射成宿主机普通用户（如 UID 0 → 1000），大幅降低逃逸风险，需在 daemon.json 中配置并重启 dockerd 才生效
动手验证比看文档更管用
别只读概念，用几条命令就能亲眼看到隔离效果：
minimax-mcp-docker版（适配极空间）
下载
MiniMax 图片理解 + 网络搜索 MCP 工具。适配 Docker 环境（极空间等），支持图片 OCR 识别、图像内容理解、网络搜索。API Key 安全存储在本地 credentials 文件，不暴露在代码中。
- 启动两个容器：
docker run -d --name a alpine sleep 3600和docker run -d --name b alpine sleep 3600 - 查它们在宿主机上的真实 PID：
docker inspect -f '{{.State.Pid}}' a和b - 进容器看进程：
docker exec a ps aux—— 只能看到自己命名空间里的进程，PID 1 是 sleep - 对比宿主机：
ps -ef | grep sleep—— 能看到两个 sleep 进程，PID 完全不同 - 检查网络命名空间：
ls -l /proc/$(docker inspect -f '{{.State.Pid}}' a)/ns/net，再对比 b，链接目标 inode 不同，说明隔离生效
结合 cgroups 理解“限制”与“隔离”的区别
namespace 负责“看不见”，cgroups 负责“用不了那么多”：
- 命名空间决定你 能看见什么资源（比如自己的网卡、自己的进程列表）
- cgroups 决定你 能用多少资源（比如最多用 512MB 内存：
docker run --memory=512m） - 两者配合才构成完整的容器运行环境——既逻辑隔离，又资源可控
- 可查看容器 cgroup 设置：
cat /sys/fs/cgroup/memory/docker/$(docker inspect -f '{{.Id}}' a)/memory.max
避开常见学习误区
很多初学者卡在似懂非懂的阶段，关键是要分清层次：
- 不要一上来就啃 Docker 源码或写 OCI runtime；先掌握
clone()系统调用怎么传CLONE_NEWPID、CLONE_NEWNET等标志 - 别混淆“Docker network”和“Linux network namespace”——前者是 Docker 封装的网络驱动（bridge/host/overlay），后者才是内核原生机制
- 注意 user namespace 的启用是全局性的，不是 per-container 参数；一旦开启，所有容器默认启用 UID 映射
- 容器不是虚拟机：没有独立内核，所有隔离都建立在宿主机 kernel 之上，这也是它轻量但隔离强度略低于 VM 的根本原因
