2. Docker 网络基础:Bridge 网络模式、Host 网络模式、Overlay 网络模式、容器间通信原理

在数据库容器化运维中,网络模式直接决定了连接池的延迟、吞吐量以及集群间的可达性。本章从 Docker 的三大核心网络模式入手,解析其数据路径与适用场景,为后续诊断“连接池水位异常”和“慢查询网络瓶颈”奠定基础。

2.1 三大网络模式对比

网络模式 隔离性 性能 跨主机通信 典型场景
Bridge 容器独立 IP,NAT 转发 中等(经 docker0 桥接) 需端口映射 单机多容器、开发环境
Host 共享宿主机网络栈 最高(无额外封装) 直接使用宿主机端口 高吞吐数据库、延迟敏感服务
Overlay VXLAN 隧道封装 较低(有封装开销) 原生支持跨主机 Swarm 集群、跨主机数据库集群
运维要点: 生产数据库容器建议优先评估 Host 模式或 macvlan 模式以降低网络开销;Overlay 模式虽方便跨主机通信,但 VXLAN 封装会增加约 5%-10% 的 CPU 开销和延迟,需结合连接池超时阈值综合评估。

2.2 Bridge 网络模式

Bridge 是 Docker 默认的网络模式。Docker 守护进程启动时会创建虚拟网桥 docker0,每个容器通过 veth pair 连接到该网桥,并分配独立的 IP 地址(通常为 172.17.0.0/16 段)。

  • 数据路径: 容器 eth0 → veth → docker0 → 宿主机 eth0 → 外部。
  • 端口映射: 使用 -p 3306:3306 将宿主机端口 DNAT 到容器 IP。
  • 连接池影响: 每次数据库连接需经过 iptables NAT 规则,长连接场景下影响较小,但短连接频繁创建时可能增加延迟。
# 创建自定义 Bridge 网络(推荐生产使用)
docker network create --driver bridge --subnet 10.10.0.0/16 db-net

# 启动容器并指定网络
docker run -d --name mysql-1 --network db-net -e MYSQL_ROOT_PASSWORD=secret mysql:8.0

2.3 Host 网络模式

容器直接使用宿主机网络栈,不进行网络隔离。容器内的端口即宿主机端口,无需端口映射,性能损耗最小。

  • 数据路径: 容器 eth0 → 宿主机 eth0(无中间桥接/NAT)。
  • 连接池水位: 由于去除了 NAT 和网桥转发,TCP 连接建立时间缩短,适合高并发数据库实例。
  • 风险: 端口冲突风险高,多个容器不能监听同一端口;隔离性弱,容器可访问宿主机全部网络接口。
注意: 使用 Host 模式时,连接池的最大连接数需与宿主机内核参数(如 net.ipv4.ip_local_port_range、fs.file-max)对齐,否则可能出现端口耗尽或文件句柄不足导致的连接失败。

2.4 Overlay 网络模式

Overlay 网络通过 VXLAN 隧道在多个宿主机之间构建二层网络,使跨主机的容器可以像在同一网段内直接通信。该模式依赖 Docker Swarm 或 Kubernetes 的 CNI 插件。

  • 数据路径: 容器 eth0 → veth → 宿主机 Overlay 网桥 → VXLAN 隧道 → 目标宿主机 → 目标容器。
  • 封装开销: 每个数据包增加 50 字节(VXLAN 头部),MTU 需调整为 1450 或更低。
  • 慢查询关联: 如果数据库集群跨主机部署在 Overlay 网络下,网络延迟波动可能被误报为慢查询,需在诊断时区分“网络延迟”与“SQL 执行慢”。
# 创建 Overlay 网络(需先初始化 Swarm)
docker swarm init
docker network create --driver overlay --attachable db-overlay

# 跨主机启动容器
docker service create --name mysql-cluster --network db-overlay --replicas 3 mysql:8.0

2.5 容器间通信原理

容器间通信的核心机制包括 DNS 解析、服务发现和网络命名空间。理解这些原理有助于诊断连接池中的“连接超时”和“找不到主机”类错误。

通信方式 原理 典型问题
同 Bridge 网络 容器通过 IP 或容器名直接通信,Docker 内置 DNS 解析容器名到 IP 容器重启后 IP 变化导致连接失效
跨 Bridge 网络 需通过宿主机端口映射或加入同一自定义网络 端口映射冲突、NAT 表耗尽
跨宿主机(Overlay) VXLAN 封装,通过 VTEP 设备转发 MTU 问题导致丢包、隧道加密开销
跨宿主机(Host 模式) 直接使用宿主机 IP + 端口,需手动管理端口分配 端口冲突、防火墙规则遗漏
Docker 三大网络模式数据路径对比 Docker 三大网络模式数据路径对比 Bridge 模式 容器 A 容器 B docker0 网桥 (NAT) 宿主机 eth0 Host 模式 容器 A 容器 B 宿主机 eth0 无桥接 / 无 NAT Overlay 模式 容器 A 容器 B Overlay 网桥 (VXLAN) 宿主机 eth0 关键诊断指标 • Bridge 模式:检查 docker0 网桥的 ARP 表、iptables NAT 规则是否溢出 • Host 模式:检查宿主机端口占用、内核参数 net.ipv4.ip_local_port_range 是否耗尽 • Overlay 模式:检查 VXLAN 隧道 MTU 一致性、VTEP 设备状态、封装 CPU 开销

2.6 连接池水位与网络模式的关联

网络模式对连接池水位的影响主要体现在以下三个维度:

  • 连接建立延迟: Bridge 模式因 NAT 和 iptables 规则,TCP 握手延迟比 Host 模式高约 0.1-0.5ms;Overlay 模式因 VXLAN 封装,延迟增加 0.5-2ms。
  • 最大连接数限制: Host 模式下连接数受宿主机内核参数限制;Bridge 模式额外受 docker0 网桥的 conntrack 表大小限制。
  • 连接复用效率: 跨主机 Overlay 网络下,连接池若未配置 TCP keepalive,可能因隧道空闲超时导致连接被中间设备重置。
诊断建议: 当连接池水位异常升高时,先通过 docker network inspect <network> 查看网络配置,再使用 ss -tiep 在容器内或宿主机上确认连接状态,排除网络模式导致的连接泄漏或超时。

2.7 容器间通信的 DNS 与服务发现

Docker 内置的 DNS 解析是容器间通信的关键。当容器连接到同一自定义网络时,Docker 自动将容器名解析为 IP 地址,无需手动维护 hosts 文件。

# 验证容器间 DNS 解析
docker exec -it mysql-1 ping mysql-2
# 输出示例:PING mysql-2 (10.10.0.3) 56(84) bytes of data.

# 查看 Docker DNS 配置
docker exec -it mysql-1 cat /etc/resolv.conf
# 输出示例:nameserver 127.0.0.11

127.0.0.11 是 Docker 内置的 DNS 代理,负责将容器名解析为对应网络的 IP。如果连接池配置了容器名作为数据库主机地址,需确保 DNS 解析正常,否则会导致连接失败。

容器间 DNS 解析与服务发现流程 容器间 DNS 解析与服务发现流程 应用容器 查询 "mysql-1" DNS 代理 127.0.0.11 返回 10.10.0.3 TCP 连接 数据库容器 10.10.0.3 连接池配置示例 jdbc:mysql://mysql-1:3306/db host: mysql-1 port: 3306 DNS 解析失败时: UnknownHostException 连接池快速耗尽

2.8 网络模式选择决策树

在数据库容器化部署中,网络模式的选择应遵循以下决策逻辑:

  1. 单机部署: 优先 Host 模式(性能最优)或自定义 Bridge 网络(隔离性更好)。
  2. 跨主机集群: 若使用 Swarm/K8s,选择 Overlay 网络;若手动管理,考虑 macvlan 或 Host 模式 + 端口规划。
  3. 连接池诊断: 当出现大量 Connection refused 或 Timeout 时,首先检查网络模式是否与连接池配置匹配,其次检查 DNS 解析和端口映射。
实战经验: 某生产环境 MySQL 集群使用 Overlay 网络,频繁出现连接池超时。排查发现宿主机 MTU 为 1500,而 Overlay 网络未调整 MTU 导致分片重传。将 Overlay 网络 MTU 调整为 1450 后,超时问题消失。建议在创建 Overlay 网络时显式指定 --opt com.docker.network.driver.mtu=1450。