container模式通过复用指定容器的network namespace实现网络协议栈共享，即多个容器共用同一ip、端口空间、lo接口及路由表，彼此可通过localhost直连，无需端口映射或dns解析，典型用于sidecar架构与pod内通信。
要用 container 网络模式让多个容器共享同一个网络协议栈，核心是让它们复用同一个容器的 network namespace，而不是各自拥有独立的网络环境。这不同于普通桥接网络或自定义网络——那些只是让容器连通，但仍是隔离的网络栈；而 container 模式是真正“共用一套网络设施”。
明确目标：什么是“共享网络协议栈”
共享网络协议栈意味着多个容器使用相同的 IP 地址、端口空间、lo 接口、路由表和 iptables 规则。它们像同一台主机上的不同进程一样通信，彼此之间通过 localhost 即可直连，无需 DNS 解析或端口映射。
- 所有容器看到的
ip addr输出完全一致 - 一个容器启动了 Redis 监听
0.0.0.0:6379，另一个容器只需redis-cli -h localhost就能连上 - 不能有两个容器同时监听
:80，否则会端口冲突（因为共享端口空间）
操作方式：用 --network container:
这是最直接、最轻量的方法，不需要改配置、不依赖 Docker Compose，命令级即可生效。
- 先起一个“基础容器”作为网络锚点，保持运行状态：
docker run -d --name net-base alpine sleep infinity - 后续容器全部复用它的网络：
docker run -d --name app1 --network container:net-base nginxdocker run -it --network container:net-base alpine sh - 进入任一复用容器执行
ip a，结果与net-base完全相同
注意事项与限制
这种模式虽高效，但有几处关键约束必须清楚：
-
主容器退出不影响已运行的复用容器，但若被
docker rm删除，下次重启依赖它的容器会失败（报错 “No such container”） - 所有复用容器共享
127.0.0.1，所以服务间调用统一走localhost，不用容器名或 IP - 无法在复用容器中绑定新端口（比如
-p 8080:80无效），端口暴露只能由锚点容器或外部代理承担 - 它不提供跨主机能力，仅适用于单机部署场景
替代方案对比：Host 模式不是等价替代
有人误以为 --network host 也能实现“共享”，但它共享的是宿主机网络栈，而非容器间的协议栈。这意味着：
- 所有容器都直接使用宿主机的
eth0和真实 IP，失去容器网络隔离性 - 端口冲突风险更高（可能和宿主机已有服务撞车）
- 无法做到“仅容器间共享、对外仍隔离”的精细控制
真正需要容器级协议栈复用时，--network container: 是唯一符合语义的原生方案。
