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[容器 eth0br/172.17.0.2] -- B[veth pair] B -- C[docker0 网桥br/172.17.0.1] C -- D[iptables NAT] D -- E[宿主机 eth0br/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.namebr-production \ --opt com.docker.network.bridge.enable_icctrue \ --opt com.docker.network.bridge.enable_ip_masqueradetrue \ --opt com.docker.network.driver.mtu1500 \ production-net # 2. 查看网络详情 docker network inspect production-net # 3. 容器接入自定义网络 docker run -d \ --name api-server \ --network production-net \ --network-alias api \ -e DATABASE_HOSTdb \ 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[容器Abr/10.0.1.2] -- A2[veth] A2 -- A3[br-overlay] A3 -- A4[VXLAN 封装] end subgraph 主机B B1[容器Bbr/10.0.1.3] -- B2[veth] B2 -- B3[br-overlay] B3 -- B4[VXLAN 解封装] end A4 --|UDP 4789| B4 subgraph 控制面 C1[Consul/etcdbr/网络元数据] 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.roleworker \ -e DB_HOSTdb \ api-server:latest docker service create \ --name db \ --network overlay-production \ --replicas 1 \ --constraint node.labels.dbprimary \ --mount typevolume,sourcedb-data,target/var/lib/postgresql/data \ postgres:15 # 4. 验证跨主机通信 docker exec -it $(docker ps -q --filter nameapi) 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. 调整 MTUVXLAN 头部 50 字节 # 宿主机 MTU 1500 → 容器 MTU 1450 docker network create \ --driver overlay \ --opt com.docker.network.driver.mtu1450 \ 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.somaxconn65535 sysctl -w net.ipv4.tcp_max_syn_backlog65535 sysctl -w net.ipv4.tcp_tw_reuse1 sysctl -w net.ipv4.ip_local_port_range1024 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。不要在单机场景用 OverlayVXLAN 封装的开销完全没必要。加密 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 的生产级配置”更稳妥的落地方式不是一次性追求完整平台而是先确定核心路径再把复杂能力逐步收敛到可验证的模块。第一步明确输入、输出和失败边界避免把不稳定因素藏在默认配置里。第二步优先实现最小闭环用真实数据验证性能、稳定性和维护成本。第三步把监控、告警和回滚策略前置到设计阶段而不是上线后再补。后续迭代可以从三个方向推进补齐自动化测试覆盖正常路径、边界路径和异常路径建立基准数据持续比较版本变化带来的收益和副作用沉淀操作手册把排障步骤、指标含义和禁用场景写清楚。只要这些基础工作到位方案就不会停留在概念层而能成为团队可以长期维护的工程资产。