必须使用container模式，即通过--network container:复用目标容器的网络命名空间，实现ip、端口、路由、iptables等完全共享，效果等同于nsenter -n进入同一netns。
要让多个 Docker 容器真正共享同一套网络协议栈（即同一个 network namespace），必须使用 Container 模式，而不是创建自定义 bridge 网络或依赖服务发现。这种模式下，容器不再拥有独立的 IP、端口空间和路由表，而是完全复用目标容器的网络上下文——效果等同于 Linux 中的 nsenter -n 进入另一个进程的 netns。
核心原理：复用而非连接
Container 模式不是“连到同一个网段”，而是直接绑定到已有容器的网络命名空间。这意味着：
- 所有复用者共用同一个
lo接口、IP 地址（如 127.0.0.1）、端口范围和 iptables 规则 - 彼此可通过
localhost直接通信，无需 DNS 或容器名解析 - 不能有端口冲突：若 A 容器占用了 6379，B 容器再尝试监听 6379 就会失败
- 文件系统、PID、IPC 等仍完全隔离，仅网络栈共享
实操步骤：启动主容器 + 复用网络
分两步完成，顺序不可颠倒：
- 先运行一个长期存活的“网络锚点”容器，例如：
docker run -d --name net-base alpine sleep 3600 - 再启动其他容器，显式指定复用其网络：
docker run -d --network container:net-base --name app nginxdocker run -d --network container:net-base --name sidecar curlimages/curl sh -c "while true; do curl -s http://localhost | head -1; sleep 2; done"
此时 app 和 sidecar 都在 net-base 的 netns 中，sidecar 用 curl http://localhost 即可访问 app 的 80 端口。
典型适用场景
该模式适合需要强耦合、低延迟、零配置网络通信的组合：
- 应用 + 辅助进程：主服务容器 + 日志采集器（如 fluent-bit）、健康检查器、指标导出器（如 prometheus exporter）
-
调试与诊断：临时启动一个调试容器（如
nicolaka/netshoot），复用业务容器网络，直接抓包或 telnet 测试 - 规避端口映射限制：当宿主机端口已占用，又需从外部访问某服务时，可用一个反向代理容器复用业务容器网络，再将代理端口映射出去
关键注意事项
Container 模式虽轻量，但有明确约束：
- 被复用的容器（如
net-base）退出不影响已启动的复用容器，但若被docker rm删除，则后续重启依赖它的容器会失败 - 不支持
docker-compose原生语法直接声明 Container 模式，需用docker run手动启动，或通过自定义 entrypoint 脚本间接实现 - 无法跨主机复用；若需多机协同，应转向 overlay 网络 + service mesh 方案
- 慎用于生产环境中的无状态横向扩展——它本质是“单点网络入口”，违背容器松耦合设计原则
