Docker 网络模型深度解析：从 Bridge 到 Overlay 的生产级配置
一、引言痛点：容器网络的认知盲区
Docker 网络是容器化落地中最容易踩坑的环节。很多人对 Docker 网络的理解停留在docker run --network的层面，对 Bridge 的 NAT 转发机制、Overlay 的 VXLAN 封装、容器 DNS 解析的优先级、网络策略的流量控制都缺乏系统认知。生产环境中的网络问题往往是最难排查的：容器间 DNS 解析偶发失败、跨主机容器通信延迟抖动、网络策略把合法流量挡了、容器重启后 IP 变化导致服务发现异常。
容器网络不是黑盒，搞清楚底层机制才能快速定位问题。本文直接上干货，从 Bridge 单机网络、Overlay 跨主机网络、网络策略三个维度，把 Docker 网络模型讲透。
二、Bridge 网络：单机容器的网络基础
2.1 Bridge 网络的数据路径
flowchart TD A[容器 eth0<br/>172.17.0.2] --> B[veth pair] B --> C[docker0 网桥<br/>172.17.0.1] C --> D[iptables NAT] D --> E[宿主机 eth0<br/>192.168.1.10] E --> F[外部网络] subgraph 容器网络命名空间 A end subgraph 宿主机网络命名空间 C D E end C --> G[同网桥容器<br/>172.17.0.3] C --> G2.2 自定义 Bridge 网络配置
#!/bin/bash # 生产级 Docker Bridge 网络配置 # 1. 创建自定义 Bridge 网络 # 为什么不用默认 bridge？因为默认 bridge 不支持 DNS 自动解析 docker network create \ --driver bridge \ --subnet 172.20.0.0/16 \ --gateway 172.20.0.1 \ --ip-range 172.20.1.0/24 \ --opt com.docker.network.bridge.name=br-production \ --opt com.docker.network.bridge.enable_icc=true \ --opt com.docker.network.bridge.enable_ip_masquerade=true \ --opt com.docker.network.driver.mtu=1500 \ production-net # 2. 查看网络详情 docker network inspect production-net # 3. 容器接入自定义网络 docker run -d \ --name api-server \ --network production-net \ --network-alias api \ -e DATABASE_HOST=db \ api-server:latest docker run -d \ --name db \ --network production-net \ --network-alias db \ -v db-data:/var/lib/postgresql/data \ postgres:15 # 4. 验证 DNS 解析 docker exec api-server ping -c 3 db # 输出：PING db (172.20.1.2) # 5. 多网络接入（一个容器接入多个网络） docker network create --driver bridge monitoring-net docker network connect monitoring-net api-server # 6. 网络流量控制 # 限制容器出站带宽 docker run -d \ --name limited-container \ --network production-net \ --device-write-bps /dev/sda:10mb \ nginx:latest2.3 iptables 规则解析
#!/bin/bash # Docker 网络 iptables 规则解析 # 查看 Docker 生成的 NAT 规则 iptables -t nat -L DOCKER -n --line-numbers # 典型输出： # Chain DOCKER (2 references) # num target prot opt source destination # 1 DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:8080 to:172.20.1.2:80 # 查看容器端口映射的完整链路 iptables -t nat -L -n -v | grep "8080" # 容器出站的 MASQUERADE 规则 iptables -t nat -L POSTROUTING -n -v | grep "172.20" # 限制容器间通信（安全加固） # 禁止容器访问宿主机的元数据服务 iptables -I DOCKER-USER -d 169.254.169.254/32 -j DROP # 只允许特定容器访问数据库 iptables -I DOCKER-USER -s 172.20.1.2 -d 172.20.1.3 -p tcp --dport 5432 -j ACCEPT iptables -I DOCKER-USER -d 172.20.1.3 -p tcp --dport 5432 -j DROP三、Overlay 网络：跨主机容器通信
3.1 Overlay 网络架构
flowchart LR subgraph 主机A A1[容器A<br/>10.0.1.2] --> A2[veth] A2 --> A3[br-overlay] A3 --> A4[VXLAN 封装] end subgraph 主机B B1[容器B<br/>10.0.1.3] --> B2[veth] B2 --> B3[br-overlay] B3 --> B4[VXLAN 解封装] end A4 -->|UDP 4789| B4 subgraph 控制面 C1[Consul/etcd<br/>网络元数据] end C1 -.-> A3 C1 -.-> B33.2 Swarm 模式 Overlay 网络配置
#!/bin/bash # Docker Swarm Overlay 网络配置 # 1. 初始化 Swarm docker swarm init --advertise-addr 192.168.1.10 # 2. 创建 Overlay 网络 docker network create \ --driver overlay \ --subnet 10.0.0.0/16 \ --ip-range 10.0.1.0/24 \ --opt encrypted \ --attachable \ overlay-production # --attachable：允许独立容器接入（不只是 Service） # --opt encrypted：启用 IPsec 加密（性能损失约 10%） # 3. 创建跨主机服务 docker service create \ --name api \ --network overlay-production \ --replicas 3 \ --constraint 'node.role==worker' \ -e DB_HOST=db \ api-server:latest docker service create \ --name db \ --network overlay-production \ --replicas 1 \ --constraint 'node.labels.db==primary' \ --mount type=volume,source=db-data,target=/var/lib/postgresql/data \ postgres:15 # 4. 验证跨主机通信 docker exec -it $(docker ps -q --filter name=api) ping -c 3 db # 5. Overlay 网络排障 # 查看 VXLAN 隧道 ip -d link show | grep vxlan # 查看路由表 ip route show | grep 10.0 # 抓包分析 VXLAN 封装 tcpdump -i eth0 -n udp port 4789 -vv3.3 Overlay 网络性能优化
#!/bin/bash # Overlay 网络性能优化 # 1. 调整 MTU（VXLAN 头部 50 字节） # 宿主机 MTU 1500 → 容器 MTU 1450 docker network create \ --driver overlay \ --opt com.docker.network.driver.mtu=1450 \ overlay-optimized # 2. 关闭加密（内网安全可信时） docker network create \ --driver overlay \ overlay-no-encrypt # 性能提升约 10-15% # 3. 使用 host 网络模式（极致性能场景） docker service create \ --name high-perf-api \ --network host \ --mode global \ high-perf-api:latest # 4. 内核参数优化 sysctl -w net.core.somaxconn=65535 sysctl -w net.ipv4.tcp_max_syn_backlog=65535 sysctl -w net.ipv4.tcp_tw_reuse=1 sysctl -w net.ipv4.ip_local_port_range="1024 65535"四、网络策略与安全
4.1 容器网络隔离模型
flowchart TD A[网络隔离层级] --> B[L1: 网络命名空间隔离<br/>容器间默认隔离] A --> C[L2: Bridge 网络隔离<br/>不同网络间不可达] A --> D[L3: iptables 规则<br/>细粒度流量控制] A --> E[L4: 网络策略<br/>K8s NetworkPolicy] B --> B1[同一 Bridge 内可通信] C --> C1[跨 Bridge 需路由] D --> D1[DOCKER-USER 链] E --> E1[Ingress/Egress 规则]4.2 K8s NetworkPolicy 配置
# K8s 网络策略：数据库只允许 API 服务访问 --- apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: db-access-policy namespace: production spec: podSelector: matchLabels: app: mysql policyTypes: - Ingress - Egress ingress: # 只允许 API 服务访问 MySQL - from: - podSelector: matchLabels: app: api-server ports: - protocol: TCP port: 3306 # 允许监控采集指标 - from: - namespaceSelector: matchLabels: name: monitoring ports: - protocol: TCP port: 9104 egress: # 允许 DNS 解析 - to: [] ports: - protocol: UDP port: 53 - protocol: TCP port: 53 --- # 默认拒绝所有入站流量 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny-ingress namespace: production spec: podSelector: {} policyTypes: - Ingress五、边界分析与架构权衡
5.1 网络模式选型
| 网络模式 | 性能 | 隔离性 | 可移植性 | 适用场景 |
|---|---|---|---|---|
| host | 最高 | 无 | 低 | 极致性能、网络密集型 |
| bridge | 中 | 好 | 高 | 单机容器、开发环境 |
| overlay | 低（VXLAN 开销） | 好 | 高 | 跨主机集群 |
| macvlan | 高 | 中 | 中 | 需要容器直接暴露物理网络 |
| none | - | 完全隔离 | 高 | 自定义网络栈 |
5.2 关键决策点
Bridge vs Overlay。单机用 Bridge，跨主机用 Overlay。不要在单机场景用 Overlay，VXLAN 封装的开销完全没必要。
加密 vs 不加密。Overlay 的 IPsec 加密会损失约 10-15% 性能。内网可信环境下可以关闭，公网或混合云必须开启。
NetworkPolicy 的粒度。生产环境建议默认拒绝 + 白名单放行。先部署默认拒绝策略，再逐步添加放行规则。不要反过来——先全放行再收紧，大概率会漏。
六、总结
Docker 网络模型不复杂，但坑多。三个要点：
第一，自定义 Bridge 替代默认 Bridge。默认 Bridge 不支持 DNS 自动解析，容器间只能用 IP 通信，这在动态环境下根本不可用。自定义 Bridge 开启 DNS，容器名即主机名。
第二，Overlay 的 VXLAN 开销要心里有数。跨主机通信的 VXLAN 封装会增加 50 字节头部和 UDP 封装/解封装的 CPU 开销。对延迟敏感的场景，考虑 host 网络或 macvlan。
第三，网络策略是安全的基础。默认拒绝 + 白名单放行，这是生产环境的安全基线。没有 NetworkPolicy 的集群，任何 Pod 都能访问任何 Pod，这跟内网裸奔没区别。
网络问题排查的核心是搞懂数据路径——包从哪来、经过哪些链路、在哪被丢弃。理解了数据路径，排障就是顺藤摸瓜。
五、总结
围绕“Docker 网络模型深度解析：从 Bridge 到 Overlay 的生产级配置”，更稳妥的落地方式不是一次性追求完整平台，而是先确定核心路径，再把复杂能力逐步收敛到可验证的模块。第一步，明确输入、输出和失败边界，避免把不稳定因素藏在默认配置里。第二步，优先实现最小闭环，用真实数据验证性能、稳定性和维护成本。第三步，把监控、告警和回滚策略前置到设计阶段，而不是上线后再补。
后续迭代可以从三个方向推进：补齐自动化测试，覆盖正常路径、边界路径和异常路径；建立基准数据，持续比较版本变化带来的收益和副作用；沉淀操作手册，把排障步骤、指标含义和禁用场景写清楚。只要这些基础工作到位，方案就不会停留在概念层，而能成为团队可以长期维护的工程资产。
