docker compose默认使每个服务运行在独立容器中，天然具备独立网络、pid、ipc和uts命名空间；无需显式配置开关，只需避免使用host模式或共享选项即可保障隔离。
docker compose 本身不提供“为每个服务配置独立命名空间”的显式开关，但默认行为就是每个服务运行在独立的容器中，而每个容器天然拥有独立的网络、pid、ipc 和 uts 命名空间。你无需额外配置，只要用标准方式定义服务，隔离性就已生效。
关键在于理解：命名空间隔离由 Docker 引擎保障，Compose 负责组织和连接这些容器。真正需要你主动配置的是 如何控制它们之间的可见性与通信边界，而不是“开启”命名空间。
下面从实操角度讲清楚怎么做：
每个服务自动获得独立命名空间
- 容器启动时，Docker 默认启用
--network=bridge、--pid=private、--ipc=private等选项 - 这意味着：
- 各服务进程彼此不可见（PID namespace 隔离）
-
/proc、/sys视图互不重叠 -
hostname、domainname独立（UTS namespace） - IPC 对象（如信号量、共享内存）不互通（IPC namespace）
✅ 不用写任何特殊字段，只要 service 下没加
network_mode: "host"或pid: "host"，就已是隔离状态。
用自定义网络强化网络命名空间边界
默认 Compose 会创建一个共用桥接网络，所有服务可互相访问 —— 这不等于命名空间不独立，只是网络策略宽松。要体现“逻辑隔离”，应：
- 显式定义多个自定义网络
- 让服务只接入必要网络，不暴露给无关组件
services:
frontend:
image: nginx
networks: [public]
api:
image: my-api
networks: [public, internal]
db:
image: postgres
networks: [internal]
networks:
public:
driver: bridge
internal:
driver: bridge
这样，db 的网络命名空间虽仍独立，但仅 api 能通过 internal 网络访问它，frontend 根本解析不到 db 这个主机名。
避免破坏命名空间隔离的常见操作
- ❌ 不要用
network_mode: "host"：会让容器直接共享宿主机网络命名空间 - ❌ 不要用
pid: "host"：导致所有服务看到同一套进程树 - ❌ 不要挂载
/proc或/sys到多个容器：可能绕过 PID/UTS 隔离 - ❌ 不要在
docker-compose.yml中设置ipc: "shareable"并跨服务复用：会弱化 IPC 隔离
验证命名空间是否真正独立
进任意容器执行：
ls -l /proc/1/ns/
你会看到类似：
net -> net:[4026532304] pid -> pid:[4026532305] mnt -> mnt:[4026532303] ...
不同服务的数字 ID（如 4026532305）完全不同，说明 PID namespace 已分离。其他类型同理。
不复杂但容易忽略
