Docker容器默认通过Linux PID namespace实现进程隔离，容器内PID=1的进程在宿主机上具有不同PID（如12847），彼此不可见、不可控；执行ps或kill仅作用于本namespace内进程，隔离可通过docker inspect和/proc/PID/ns/pid验证。
Docker 容器默认就与宿主机进程完全隔离，靠的是 Linux 内核的 PID 命名空间（PID namespace）机制。每个容器启动时，Docker 会为它创建一个全新的 PID namespace，容器内看到的 PID=1 是自己的主进程（比如 nginx 或 bash），而宿主机上这个进程的真实 PID 是另一个数字（比如 12847），两者互不可见、互不可控。
PID 命名空间如何实现宿主机进程隔离
- 容器内执行
ps aux只能看到本容器及其子进程，看不到 systemd、sshd、其他容器或任何宿主机服务 - 宿主机执行
ps aux能看到所有进程，但容器内进程在宿主机视角下只是普通子进程（如 docker-containerd 的子进程），其内部层级（如容器里 fork 出的 5 级子进程）在宿主机/proc下不可见 - 容器内尝试
kill -9 1只会终止自己，对宿主机 PID=1（通常是 systemd）毫无影响 - 宿主机无法直接
kill容器内某个逻辑 PID（比如容器里显示的 PID=7），因为该 PID 在宿主机 PID namespace 中不存在
验证是否真正隔离
- 查容器主进程真实 PID：
docker inspect -f '{{.State.Pid}}' <容器名> - 查它的 PID namespace ID：
ls -l /proc/<上面查到的PID>/ns/pid→ 输出形如pid:[4026532518] - 对比宿主机的 PID namespace：
ls -l /proc/1/ns/pid→ 输出是另一个数字（如pid:[4026531836]） - 两个数字不同，说明隔离生效；相同则说明被
--pid=host等配置破坏了
哪些操作会破坏这种隔离
- 启动时加
--pid=host：容器直接复用宿主机 PID namespace，ps aux看到全部宿主机进程 - 挂载宿主机
/proc（如-v /proc:/proc）：容器可通过/proc/[pid]/stat等路径读取其他 namespace 进程信息 - 使用
--privileged或--cap-add=SYS_ADMIN：可能绕过命名空间限制，配合nsenter进入其他 PID namespace - 用
--network=host却没配--pid=host：网络共享不影响 PID 隔离，两者独立控制
Docker 默认不做任何共享，PID 隔离是开箱即用的安全基线。需要打破隔离（比如调试宿主机服务），才需显式添加 --pid=host 并承担对应风险。
