Docker 网络模式与容器间通信机制：从 bridge 到 overlay，容器网络的底层逻辑
一、容器网络的工程痛点：从"能跑"到"跑好"的网络治理
Docker 的默认网络模式（bridge）在单机开发中开箱即用，但在生产环境中暴露出多个治理痛点：容器重启后 IP 地址变化导致服务发现失效、跨主机容器无法直接通信、网络性能受限于 NAT 转发、容器间网络隔离策略难以精细化。理解 Docker 网络模式的底层机制，是从"容器能跑"到"容器跑好"的关键一步。
Docker 提供了五种网络模式：bridge（默认桥接）、host（主机网络）、none（无网络）、container（共享另一容器网络）、overlay（跨主机覆盖网络）。每种模式在隔离性、性能、跨主机通信能力上各有取舍，选择合适的网络模式是容器网络治理的基础。
二、Docker 网络模式的数据流与隔离模型
flowchart TD A[Docker 网络模式] --> B[bridge: 桥接网络] A --> C[host: 主机网络] A --> D[overlay: 覆盖网络] A --> E[none: 无网络] B --> B1[容器独立网络命名空间] B --> B2[veth pair 连接 docker0 网桥] B --> B3[iptables NAT 端口映射] B --> B4[同网络容器可直接通信] C --> C1[共享主机网络命名空间] C --> C2[无 NAT 性能损耗] C --> C3[端口冲突风险] D --> D1[VXLAN 隧道跨主机通信] D --> D2[分布式键值存储同步] D --> D3[服务发现内置] subgraph bridge 数据流 F[容器 eth0] --> G[veth pair] G --> H[docker0 网桥] H --> I[主机 eth0] I --> J[外部网络] end subgraph overlay 数据流 K[容器 eth0] --> L[br-overlay 网桥] L --> M[VXLAN 隧道] M --> N[对端主机 br-overlay] N --> O[对端容器 eth0] endbridge 模式的核心组件：veth pair（虚拟以太网对，一端在容器命名空间，一端在主机命名空间）、docker0 网桥（Linux bridge，连接同一网络的所有 veth）、iptables NAT（容器访问外部网络的地址转换）。理解这些组件的协作方式，是排查容器网络问题的基础。
三、工程实践：生产级容器网络配置
# docker-compose.yml — 多网络微服务配置 version: '3.8' services: # 前端服务：bridge 网络 + 端口映射 frontend: image: nginx:alpine networks: - frontend-net ports: - "80:80" - "443:443" deploy: resources: limits: cpus: '0.5' memory: 256M # 后端 API：bridge 网络 + 内部端口 api: image: myapp/api:latest networks: - frontend-net - backend-net environment: - DB_HOST=database - REDIS_HOST=cache depends_on: - database - cache # 数据库：仅后端网络，不暴露端口 database: image: mysql:8.0 networks: - backend-net volumes: - db-data:/var/lib/mysql environment: - MYSQL_ROOT_PASSWORD_FILE=/run/secrets/db_password secrets: - db_password # 不映射端口，仅后端网络可达 # 缓存：仅后端网络 cache: image: redis:7-alpine networks: - backend-net command: redis-server --maxmemory 256mb --maxmemory-policy allkeys-lru networks: # 前端网络：允许外部访问 frontend-net: driver: bridge ipam: config: - subnet: 172.20.0.0/16 # 后端网络：内部通信，默认不暴露 backend-net: driver: bridge internal: true # 禁止外部访问 ipam: config: - subnet: 172.21.0.0/16 secrets: db_password: file: ./secrets/db_password.txt volumes: db-data:# 自定义 bridge 网络：容器名 DNS 解析 # Docker 默认 bridge 网络不支持容器名 DNS，需创建自定义网络 docker network create \ --driver bridge \ --subnet 172.22.0.0/16 \ --opt com.docker.network.bridge.name=br-custom \ custom-net # 在自定义网络中，容器可通过名称互访 docker run -d --name api --network custom-net myapp/api docker run -d --name web --network custom-net nginx # web 容器内可通过 http://api:8080 访问 API# overlay 网络配置：跨主机容器通信 # 前提：初始化 Docker Swarm docker swarm init # 创建 overlay 网络 docker network create \ --driver overlay \ --subnet 10.0.0.0/24 \ --attachable \ my-overlay-net # 在不同主机上启动容器，加入同一 overlay 网络 # 主机 A docker run -d --name app-a --network my-overlay-net myapp/api # 主机 B docker run -d --name app-b --network my-overlay-net myapp/api # app-a 可通过 http://app-b:8080 直接访问 app-b# 网络故障排查命令 # 1. 查看容器网络配置 docker inspect <container> --format '{{.NetworkSettings.Networks}}' # 2. 进入容器网络命名空间排查 docker exec <container> ip addr docker exec <container> ip route docker exec <container> iptables -L -n # 3. 从主机视角查看网桥 brctl show docker0 bridge fdb show br docker0 # 4. 抓包分析容器间通信 tcpdump -i docker0 -nn port 8080 # 5. 检查 NAT 规则 iptables -t nat -L -n | grep DNAT四、容器网络的边界与权衡
bridge 模式的 NAT 性能损耗：容器通过 NAT 访问外部网络，每次请求需要经过 iptables 地址转换，在高并发场景下可能成为瓶颈。host 模式消除了 NAT 损耗，但牺牲了网络隔离性。建议对性能敏感的服务（如 API 网关）使用 host 模式，对隔离性要求高的服务（如数据库）使用 bridge 模式。
overlay 网络的 VXLAN 开销：VXLAN 封装增加了约 50 字节的头部开销，且封解包消耗 CPU。在万兆网络中，overlay 的性能损耗约 5-10%。对网络性能要求极高的场景（如高性能计算），建议使用 Macvlan 或 Host 网络。
容器 IP 的动态性：bridge 网络中容器重启后 IP 可能变化，依赖 IP 的服务发现机制不可靠。建议使用 Docker 内置的 DNS（自定义 bridge 网络支持容器名解析）或外部服务发现（Consul、etcd）。
网络策略的局限：Docker 原生不支持细粒度的网络策略（如"仅允许 API 容器访问数据库的 3306 端口"）。Kubernetes 的 NetworkPolicy 提供了这一能力，建议在生产环境中使用 Kubernetes 替代纯 Docker 管理容器网络。
五、总结
Docker 网络模式的选择直接影响容器的隔离性、性能与跨主机通信能力。bridge 适合单机多容器隔离，host 适合性能敏感场景，overlay 适合跨主机集群通信。工程落地的关键在于：自定义 bridge 网络启用容器名 DNS、internal 网络隔离敏感服务、overlay 网络实现跨主机通信、网络故障排查掌握 veth/bridge/NAT 三层工具链。容器网络不是"配好就行"的基础设施，而是需要根据服务特性选择合适模式、持续监控与优化的治理对象。
