3. Docker网络模型：Bridge、Host、Overlay网络模式与跨主机通信
在微服务架构与容器化编排场景中，网络模型直接决定了服务间通信的效率、安全性与可扩展性。Docker 提供了多种网络驱动，每种驱动对应不同的隔离级别与通信能力。本章将深入剖析 Bridge、Host、Overlay 三种核心网络模式，并解析跨主机通信原理与网络隔离策略。
3.1 网络模式对比总览
下表从网络栈隔离、性能、跨主机能力、典型场景四个维度对比三种模式，帮助你在架构选型时快速决策。
| 网络模式 | 网络栈隔离 | 性能 | 跨主机通信 | 典型场景 |
|---|---|---|---|---|
| Bridge | 容器独立网络命名空间 | 中等（NAT 转换） | 不支持（需端口映射） | 单机开发、测试环境 |
| Host | 共享宿主机网络栈 | 最高（无额外开销） | 不支持（端口直接暴露） | 高性能代理、监控 Agent |
| Overlay | 容器独立网络命名空间 | 中等（VXLAN 封装） | 原生支持 | Docker Swarm / K8s 集群 |
选型建议： 单机压测或契约测试优先使用 Bridge 模式；需要极致网络吞吐时考虑 Host 模式；生产级多节点编排必须使用 Overlay 模式。
3.2 Bridge 网络模式
Bridge 是 Docker 默认的网络模式。每个容器拥有独立的网络命名空间，通过虚拟网桥（docker0）与宿主机通信，并借助 iptables NAT 规则访问外部网络。
核心特性
- 隔离性： 容器间默认无法通过 IP 直接通信，需加入同一自定义 Bridge 网络。
- 端口映射： 使用
-p hostPort:containerPort将容器端口暴露到宿主机。 - DNS 解析： 自定义 Bridge 网络支持容器名自动解析，适合微服务间调用。
通信流程
- 容器 eth0 通过 veth pair 连接到 docker0 网桥。
- docker0 网桥通过 NAT 将容器流量转发到宿主机 eth0。
- 宿主机 eth0 将流量发送到外部网络。
压测注意： Bridge 模式下的 NAT 转换会引入微秒级延迟，高频小包场景下性能下降约 5%-10%。建议压测时使用
--network host 排除网络栈干扰。
3.3 Host 网络模式
Host 模式直接复用宿主机网络栈，容器不拥有独立网络命名空间。容器内应用直接监听宿主机端口，无 NAT 转换，性能最优。
适用场景
- 需要极低网络延迟的压测 Agent 或数据采集器。
- 端口动态分配或需要大量端口映射的中间件。
- 对网络隔离要求较低的内部监控组件。
风险提示
安全风险： Host 模式容器拥有宿主机网络栈的全部权限，可监听所有端口、修改 iptables 规则。生产环境中应严格限制使用，避免容器逃逸攻击。
3.4 Overlay 网络模式
Overlay 网络是 Docker Swarm 和 Kubernetes 实现跨主机容器通信的基础。它通过 VXLAN 隧道技术将二层网络扩展到多台宿主机，使不同节点上的容器可以像在同一个局域网内直接通信。
核心组件
- VXLAN 隧道： 将容器数据包封装在 UDP 报文中，通过宿主机物理网络传输。
- 分布式 KV 存储： 存储网络状态、IP 分配、路由信息（如 etcd、consul）。
- 网络控制器： 管理 Overlay 网络的创建、删除和成员同步。
跨主机通信原理
下图展示了两个宿主机上的容器通过 Overlay 网络通信的完整数据流：
数据封装过程
- 容器 A 发送数据包（源 IP 10.0.0.2 → 目标 IP 10.0.0.3）。
- Overlay 网桥 br0 识别目标 IP 不在本地，交给 VXLAN 隧道端点。
- VXLAN 隧道端点将原始数据包封装为 UDP 报文（外层源 IP 10.0.1.10 → 目标 IP 10.0.1.20，端口 4789）。
- 宿主机 B 的 VXLAN 隧道端点解封装，还原原始数据包并交付给容器 B。
压测指标： Overlay 网络因 VXLAN 封装会增加约 50-100 字节的头部开销，MTU 需设置为 1450 字节。压测时建议关注
net.core.rmem_default 和 net.core.wmem_default 内核参数。
3.5 网络隔离策略
在多租户或微服务架构中，网络隔离是保障安全性和稳定性的关键。Docker 提供以下隔离策略：
策略清单
| 策略 | 实现方式 | 隔离粒度 | 适用场景 |
|---|---|---|---|
| 自定义 Bridge 网络 | 创建独立 Bridge 网络，容器加入不同网络 | 网络级 | 环境隔离（开发/测试/生产） |
| iptables 规则 | 在宿主机或容器内配置 iptables 策略 | IP/端口级 | 精细访问控制 |
| 网络策略（Network Policy） | Kubernetes NetworkPolicy 资源 | Pod 级 | K8s 集群内微服务隔离 |
| Macvlan / IPvlan | 容器直接使用物理网络 MAC/IP | 物理网络级 | 需要直接接入物理网络的场景 |
最佳实践
- 最小权限原则： 每个微服务只加入必要的 Overlay 网络，不共享网络命名空间。
- 加密通信： 在 Overlay 网络启用 IPSec 加密（Docker Swarm 默认支持），防止数据包被嗅探。
- 压测隔离： 压测流量应使用独立的 Overlay 网络，避免干扰生产服务。
常见陷阱： 使用
--network host 时，容器内 localhost 指向宿主机而非容器自身，可能导致服务绑定地址错误。压测脚本中务必显式指定监听地址。
3.6 跨主机通信性能对比
以下数据基于 10Gbps 网络环境，使用 iperf3 测试不同网络模式下的吞吐量和延迟：
| 网络模式 | 吞吐量（Gbps） | 延迟（μs） | CPU 开销（%） |
|---|---|---|---|
| Host（直接物理网卡） | 9.4 | 12 | 2 |
| Bridge（单机） | 8.7 | 18 | 5 |
| Overlay（VXLAN） | 7.2 | 35 | 12 |
| Overlay（IPSec 加密） | 5.8 | 52 | 20 |
压测建议： 在契约测试场景中，如果服务间调用频繁且数据量小（如 HTTP API），Overlay 网络的延迟增加（约 20-30μs）通常可接受。但对于高频 RPC 或流式数据传输，建议使用 Host 网络或 SR-IOV 直通。
3.7 网络模式选择决策树
以下决策树帮助你根据实际需求快速选择网络模式：
3.8 实战：配置 Overlay 网络
以下命令演示如何在 Docker Swarm 集群中创建并使用 Overlay 网络：
# 初始化 Swarm 集群（在管理节点执行）
docker swarm init --advertise-addr 10.0.1.10
# 创建 Overlay 网络（附加可附加模式，允许独立容器使用）
docker network create -d overlay \
--subnet=10.0.0.0/16 \
--gateway=10.0.0.1 \
--attachable \
my-overlay-net
# 启动服务并连接到 Overlay 网络
docker service create \
--name web-service \
--network my-overlay-net \
--replicas 3 \
nginx:alpine
# 验证跨主机通信
docker exec -it $(docker ps -q) ping web-service
压测验证： 使用
docker service ps web-service 确认副本分布在多个节点，然后通过 iperf3 测试跨主机容器间的网络吞吐量。
3.9 本章小结
- Bridge 模式 适合单机开发与测试，隔离性好但性能中等。
- Host 模式 性能最优，但牺牲了网络隔离，仅推荐用于特定场景。
- Overlay 模式 是跨主机编排的基石，通过 VXLAN 隧道实现容器间透明通信。
- 网络隔离策略 需根据安全等级和性能要求综合选择，压测时务必使用独立网络。