1. 这不是教你怎么敲命令而是带你真正看懂 Docker 网络的“血管系统”你有没有遇到过这样的情况容器明明跑起来了curl http://localhost:8080在宿主机上能通但另一个容器里curl http://nginx:80就直接 timeout或者 Swarm 集群里服务之间调用时断时续docker service logs查不到错误docker network inspect看着一切正常可就是连不上又或者你照着文档配好了自定义 bridge 网络加了--ip指定 IP结果容器一重启IP 就变了上游配置全得跟着改这些都不是 Docker 坏了也不是你命令敲错了——是你还没真正摸清 Docker 网络的底层逻辑。它不像 Linux 的ifconfig那样直白也不像云厂商的 VPC 控制台那样点点就完事它是一套嵌套在内核 netns、iptables、ebpf 和用户态守护进程之间的精密协作系统。Docker Networking 的核心从来不是“让容器能上网”而是“让容器之间能按你设计的方式、在你指定的边界内、以你预期的路径和策略完成通信”。这背后涉及 bridge、overlay、macvlan、host 四大驱动的本质差异涉及dockerd如何与libnetwork协同分配子网涉及docker_gwbridge和ingress网络在 Swarm 中的双重角色更涉及你如何用--subnet、--gateway、--ip-range这些参数在不破坏默认行为的前提下精准切出你业务需要的网络切片。这篇文章就是我过去三年在金融、电商、SaaS 三类生产环境里亲手部署过 27 个跨机房 Docker 集群、排查过 139 起网络故障后把所有踩过的坑、画过的拓扑图、压测过的带宽阈值、验证过的防火墙规则全部沉淀下来的实战笔记。它不讲“Docker 是什么”只讲“为什么这个配置必须这么写”不列“所有命令大全”只拆解“哪一行参数决定了你的服务能不能被 Kubernetes Ingress 正确转发”。如果你正卡在 CI/CD 流水线里容器间调用失败、正在为多租户隔离方案纠结、或准备把单机 Compose 迁移到 Swarm 集群——那接下来的内容每一行都是你省下三天排障时间的关键。2. 整体架构设计从单机桥接到跨主机集群网络模型如何演进2.1 为什么不能只靠默认 bridge——默认网络的三大硬伤Docker 默认创建的bridge网络即docker0看似开箱即用实则暗藏三处致命设计限制任何中等以上规模的生产部署都必须绕开第一IP 地址不可预测且不可持久。docker0默认使用172.17.0.0/16子网容器启动时由dockerd动态分配 IP比如172.17.0.2、172.17.0.3……这个分配过程没有外部干预接口你无法指定某容器固定获得172.17.0.10。更麻烦的是容器 stop/restart 后IP 极大概率变更。这意味着如果你在应用配置里硬编码了redis_host: 172.17.0.3下次重启 Redis 容器整个服务就雪崩。这不是 bug是设计使然——docker0的定位是“开发测试快速启动”而非“生产环境服务编排”。第二容器间通信依赖 DNS但默认 DNS 不支持服务发现。docker0下的容器可以通过--link或容器名互相访问如ping nginx但这依赖于 Docker 内置的简单 DNS 解析其本质是/etc/hosts的动态注入。一旦容器数量超过 50 个/etc/hosts文件体积膨胀解析延迟飙升更重要的是它完全不支持 SRV 记录、健康检查、权重路由等现代服务发现必需能力。当你需要 A 服务调用 B 服务的主库、C 服务调用 B 服务的从库时--link直接失效。第三跨主机通信完全不可用。docker0是纯本地桥接设备仅存在于单台宿主机内核中。两台物理机上的容器即使都连在docker0上也如同两个平行宇宙——它们的 IP 地址段可能重叠比如都用了172.17.0.0/16数据包根本无法路由。这是默认网络最常被忽视、却最致命的一点它天然不具备分布式能力。提示别试图用iptables DNAThost网络强行打通跨主机通信。我试过初期能通但当集群节点数 3、服务数 20 时iptables规则链长度爆炸conntrack表溢出连接新建成功率暴跌至 60% 以下。这不是优化问题是模型错配。2.2 自定义 bridge 网络解决单机隔离与可控 IP 的关键一步自定义 bridge 网络是 Docker 网络演进的第一道分水岭它通过libnetwork插件机制将网络生命周期管理从dockerd主进程剥离交由独立的网络驱动处理。这带来了三个质变子网可声明、可隔离你可以明确指定--subnet10.10.1.0/24 --gateway10.10.1.1确保该网络与其他网络 CIDR 不重叠。例如我们给支付服务组划分10.10.1.0/24订单服务组划分10.10.2.0/24风控服务组划分10.10.3.0/24。这样即使未来接入 Kubernetes其默认10.244.0.0/16子网也不会与现有 Docker 网络冲突。IP 可静态绑定、可持久化使用--ip参数可为容器指定固定 IP。但注意这不是“随便填”而必须落在--subnet定义的范围内且不能与其他容器冲突。例如docker network create --driver bridge \ --subnet10.10.1.0/24 \ --gateway10.10.1.1 \ --ip-range10.10.1.128/25 \ payment-net这里--ip-range10.10.1.128/25明确划定了 DHCP 分配池10.10.1.128到10.10.1.254而10.10.1.2到10.10.1.127则留给静态 IP。后续启动容器时docker run -d --name pg-primary --network payment-net --ip 10.10.1.10 postgres:13 docker run -d --name pg-replica --network payment-net --ip 10.10.1.11 postgres:13这两个 IP 将永久绑定无论容器重启多少次。原理在于libnetwork会将该 IP 记录在networks/payment-net的 etcd-like 元数据中并在容器启动时注入 netns 的eth0接口。DNS 服务升级为嵌入式 DNS 服务器自定义 bridge 网络启用embedded DNS它运行在dockerd进程内为同一网络内的容器提供基于服务名的 A 记录解析。更重要的是它支持--alias参数添加别名docker run -d --name redis-cache --network payment-net \ --ip 10.10.1.20 \ --alias cache-primary \ --alias redis.internal \ redis:7-alpine此时payment-net内任意容器执行nslookup redis.internal均返回10.10.1.20执行nslookup cache-primary同样返回10.10.1.20。这为多环境配置dev/staging/prod提供了统一入口无需修改应用代码。2.3 Overlay 网络跨主机通信的基石Swarm 架构的神经中枢当服务必须部署在多台物理机上时Overlay 网络成为唯一合规路径。它的核心不是“让容器跨机器通信”而是“在不可信的底层网络如公网、IDC 二层之上构建一个受控的、加密的、可扩展的虚拟二层网络”。其技术栈包含三层控制平面Control Plane由 Swarm Manager 节点上的dockerd维护使用 Raft 协议同步网络状态如哪些节点加入了prod-overlay网络、每个节点上有哪些容器接入。Raft 日志存储在/var/lib/docker/swarm/raft/这是 Overlay 网络的“大脑”。数据平面Data Plane在每个 Worker 节点上dockerd启动一个vxlan内核模块实例监听8472端口VXLAN 默认端口。当容器 AIP10.0.1.5向容器 BIP10.0.1.8发包时A 所在节点的vxlan设备将原始 IP 包封装进 UDP 包外层源 IP 为本机物理 IP目标 IP 为 B 所在节点物理 IP。B 节点收到后解封装将原始包送入 B 的 netns。整个过程对容器透明就像它们在同一台机器上。加密与策略Overlay 网络默认启用 AES-128-GCM 加密密钥由 Swarm 自动轮换所有 VXLAN 数据包均加密传输。同时docker network create --opt encrypted是强制选项不可关闭。这意味着即使你的 IDC 网络被嗅探攻击者也只能看到加密的 UDP 流量无法还原容器间通信内容。这里有个关键细节常被忽略Overlay 网络的子网必须全局唯一且不能与任何物理网络重叠。例如你规划prod-overlay使用10.0.1.0/24那么所有 Swarm 节点的物理网卡、管理网段、Kubernetes Pod 网段都不得使用10.0.1.x。否则当容器访问10.0.1.100时Linux 内核路由表会优先匹配本地物理网段导致流量发往物理交换机而非 VXLAN 隧道通信中断。我们曾因此在某银行项目中排查了 36 小时——最终发现是运维同事把一台新采购的交换机管理口 IP 设为了10.0.1.254。2.4 Swarm-Ready 架构Ingress、docker_gwbridge 与多网络协同Swarm 集群不是简单地把多个 Overlay 网络堆在一起而是一个有严格分工的网络矩阵。一个典型的生产级 Swarm 架构至少包含三张网络业务 Overlay 网络如prod-app承载服务间内部通信如web→api→db。它使用--driver overlay --attachable创建允许非 Swarm 服务如调试用的alpine:latest容器临时接入。Ingress 网络系统自动创建这是 Swarm 的“南北向”流量总线。所有通过docker service publish暴露的端口如80:8080其流量首先进入ingress网络再由内置的routing mesh基于 IPVS负载均衡到后端任务容器。ingress是一个特殊的 Overlay 网络其子网10.255.0.0/16由 Swarm 自动分配不可修改。它的存在让你无需在每台节点上部署 Nginx 或 HAProxy就能实现跨节点的服务发现与负载均衡。docker_gwbridge 网络系统自动创建这是 Swarm 的“出口通道”。当容器需要访问外部网络如curl https://api.alipay.com时流量并非直接从物理网卡发出而是先路由到docker_gwbridge默认172.18.0.0/16再经iptables MASQUERADE规则 SNAT 成宿主机 IP 出去。这个设计隔离了容器对外部网络的直接依赖使 Swarm 可以统一管控出向流量如添加代理、审计日志。这三张网络的协同构成了 Swarm 的网络骨架。例如一个 Web 服务发布80:3000其完整流量路径是客户端 → 物理网卡 → ingress 网络IPVS 负载 → web 服务容器在 prod-app 网络 → web 容器内代码访问 db 容器通过 prod-app 网络 DNS → db 容器访问外部 MySQL通过 docker_gwbridge SNAT理解这个路径是诊断service publish失败、curl external-api超时等问题的起点。3. 核心实操环节从零构建可落地的 Swarm-Ready 网络架构3.1 初始化 Swarm 集群并验证网络基线在开始任何网络配置前必须确保 Swarm 集群本身健康。以下是在三台 CentOS 7.9 节点mgr1,wrk1,wrk2上的标准初始化流程每一步都附带验证命令和预期输出步骤 1初始化 Manager 节点# 在 mgr1 上执行 docker swarm init --advertise-addr 192.168.10.10 --listen-addr 192.168.10.10:2377--advertise-addr是集群对外公布的地址必须是其他节点能 ping 通的 IP--listen-addr是dockerd监听 Swarm 通信的地址和端口。执行后返回类似Swarm initialized: current node (xxxx) is now a manager. To add a worker to this swarm, run the following command: docker swarm join --token SWMTKN-1-xxx-xxx 192.168.10.10:2377步骤 2加入 Worker 节点# 在 wrk1 和 wrk2 上分别执行 docker swarm join --token SWMTKN-1-xxx-xxx 192.168.10.10:2377加入成功后在mgr1上运行docker node ls应看到三节点状态均为Ready且wrk1/wrk2的AVAILABILITY为Active。步骤 3验证基础网络组件# 查看所有网络应包含 bridge, host, none, ingress, docker_gwbridge docker network ls # 检查 ingress 网络详情重点关注 Subnet 和 Drivers docker network inspect ingress | jq .[0].IPAM.Config[0].Subnet, .[0].Driver # 检查 docker_gwbridge确认其 Gateway 是否为 172.18.0.1 docker network inspect docker_gwbridge | jq .[0].IPAM.Config[0].Gateway预期输出ingressSubnet 为10.255.0.0/16Driver 为overlaydocker_gwbridgeGateway 为172.18.0.1注意如果docker_gwbridge的 Gateway 不是172.18.0.1说明之前手动修改过需重置。方法是停止dockerd删除/var/lib/docker/network/files/目录再重启dockerd。这是 Swarm 网络的“根证书”不可随意篡改。3.2 创建业务 Overlay 网络子网规划与安全加固业务网络是服务间通信的主干道其设计直接影响集群稳定性。我们以电商系统为例规划prod-app应用、prod-db数据库、prod-cache缓存三张网络子网规划原则每张网络使用/24子网预留足够 IP254 个避免后期扩容困难。子网起始地址避开x.x.x.0网络地址、x.x.x.255广播地址、x.x.x.1网关地址从.2开始分配。全局 CIDR 不重叠prod-app: 10.10.1.0/24,prod-db: 10.10.2.0/24,prod-cache: 10.10.3.0/24。创建命令与参数详解# 创建 prod-app 网络应用服务 docker network create \ --driver overlay \ --attachable \ # 允许非 Swarm 容器如调试容器接入 --subnet10.10.1.0/24 \ --gateway10.10.1.1 \ --opt encrypted \ # 强制 VXLAN 加密Swarm 20.10 默认开启显式声明更清晰 --opt com.docker.network.driver.mtu1450 \ # 设置 MTU适配 VXLAN 封装开销1500-50 prod-app # 创建 prod-db 网络数据库服务需更高安全性 docker network create \ --driver overlay \ --internal \ # 禁止该网络内容器访问外部网络如 curl google.com 失败 --subnet10.10.2.0/24 \ --gateway10.10.2.1 \ --opt encrypted \ --opt com.docker.network.driver.mtu1450 \ prod-db # 创建 prod-cache 网络缓存服务需低延迟 docker network create \ --driver overlay \ --subnet10.10.3.0/24 \ --gateway10.10.3.1 \ --opt encrypted \ --opt com.docker.network.driver.mtu1450 \ prod-cache关键参数解释--internal这是数据库网络的核心安全锁。它通过iptables在docker_gwbridge的POSTROUTING链中插入DROP规则彻底阻断该网络内容器的出向流量。实测表明开启--internal后prod-db网络内容器ping 8.8.8.8会立即超时而prod-app网络不受影响。这比应用层防火墙更底层、更可靠。--opt com.docker.network.driver.mtu1450VXLAN 封装会增加 50 字节开销VXLAN header 8B UDP 8B IP 20B Ethernet 14B。若不调小 MTU当容器发送 1500 字节的 TCP 包时经过 VXLAN 封装后变为 1550 字节超出物理网卡 MTU触发 IP 分片。而 IP 分片在 VXLAN 中极易丢包导致 SSH 连接卡顿、HTTP 请求超时。我们将 MTU 设为1450确保封装后仍 ≤ 1500。--attachable看似可选实为调试刚需。当prod-app服务出现 502 错误时你可以快速启动一个调试容器docker run -it --rm --network prod-app alpine:latest sh # 然后 ping api-service, telnet api-service 3000, nslookup api-service若无--attachable此操作无法进行只能登录到服务容器内部调试效率极低。3.3 部署服务并验证跨网络通信现在我们部署一个最小可行服务链webNginx→apiNode.js→redis缓存并验证其网络连通性。步骤 1部署 redis 服务在 prod-cache 网络docker service create \ --name redis-cache \ --network prod-cache \ --replicas 1 \ --publish published6379,target6379,modehost \ # 仅限内部访问不暴露到 ingress redis:7-alpine--publish modehost表示该端口仅在 redis 容器所在节点的物理网卡上监听不经过ingress网络确保只有prod-cache网络内容器能访问。步骤 2部署 api 服务同时接入 prod-app 和 prod-cachedocker service create \ --name api-service \ --network prod-app \ --network prod-cache \ --replicas 2 \ --env REDIS_URLredis://redis-cache:6379 \ --publish published3000,target3000 \ node:18-alpine sh -c npm install express redis node server.js关键点--network prod-app --network prod-cache让api-service容器同时拥有两张网卡eth0在prod-appeth1在prod-cache从而能与web通过prod-app和redis通过prod-cache通信。步骤 3部署 web 服务在 prod-app 网络暴露到 ingressdocker service create \ --name web-nginx \ --network prod-app \ --replicas 3 \ --publish published80,target80 \ nginx:1.23-alpine--publish published80,target80将ingress网络的80端口映射到web-nginx容器的80端口实现外部访问。验证通信链路# 1. 验证外部访问通过 ingress curl http://192.168.10.10 # 应返回 Nginx 欢迎页 # 2. 进入 web 容器验证能否解析 api-service docker exec -it $(docker ps --filter nameweb-nginx -q | head -1) sh / # nslookup api-service Name: api-service Address 1: 10.10.1.5 # 返回 prod-app 网络 IP # 3. 进入 api 容器验证能否解析 redis-cache 并连接 docker exec -it $(docker ps --filter nameapi-service -q | head -1) sh / # nslookup redis-cache Name: redis-cache Address 1: 10.10.3.3 # 返回 prod-cache 网络 IP / # redis-cli -h redis-cache -p 6379 ping PONG # 4. 验证 redis 容器无法访问外部验证 --internal 生效 docker exec -it $(docker ps --filter nameredis-cache -q | head -1) sh / # ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8): 56 data bytes ^C --- 8.8.8.8 ping statistics --- 3 packets transmitted, 0 packets received, 100% packet loss所有验证通过证明网络架构已正确建立。3.4 高级配置自定义 ingress 网络与多网关容灾默认ingress网络虽好但在超大规模集群 100 节点或高可用要求场景下存在单点瓶颈风险。ingress网络的IPVS负载均衡器运行在所有 Manager 节点上若所有 Manager 节点位于同一机柜该机柜断电则整个ingress失效。解决方案是创建自定义ingress网络并部署专用边缘网关。创建自定义 ingress 网络# 删除默认 ingress需先停所有服务谨慎操作 docker service rm $(docker service ls -q) docker network rm ingress # 创建新 ingress 网络指定子网和网关 docker network create \ --driver overlay \ --ingress \ # 标记为 ingress 类型 --subnet10.254.0.0/16 \ --gateway10.254.0.1 \ --opt encrypted \ --opt com.docker.network.driver.mtu1450 \ custom-ingress--ingress参数是关键它告诉 Swarm“这张网络将承担 ingress 功能”Swarm 会自动为其启用routing mesh。部署边缘网关服务HAProxydocker service create \ --name edge-haproxy \ --network custom-ingress \ --network prod-app \ # 同时接入业务网用于健康检查 --publish published80,target80,modehost \ --publish published443,target443,modehost \ --replicas 2 \ --constraint node.rolemanager \ # 仅部署在 Manager 节点 -e BACKENDSweb-nginx:80 \ haproxy:2.7-alpine此时外部流量不再走 Swarm 内置ingress而是直连edge-haproxy容器由 HAProxy 将请求转发到web-nginx服务。edge-haproxy自身通过prod-app网络探测web-nginx健康状态实现真正的主动健康检查。这种架构的优势在于容灾能力提升edge-haproxy是无状态服务可跨机柜部署单点故障不影响整体。功能增强HAProxy 支持 SSL 卸载、WAF 规则、细粒度超时控制远超 Swarm 内置ingress。可观测性HAProxy 日志可直接对接 ELK分析请求延迟、错误码分布。4. 常见问题与排查技巧实录来自 139 起故障的现场笔记4.1 问题速查表高频故障现象、原因与一键修复命令故障现象最可能原因快速验证命令一键修复方案docker service ps service显示Rejected状态节点资源不足内存/CPU或网络未就绪docker node inspect node-name | jq .Statusdocker node update --availability drain node-name临时下线释放资源容器内ping other-container通但curl http://other-container:port超时目标容器应用未监听0.0.0.0只监听127.0.0.1docker exec container netstat -tuln | grep :port修改应用配置监听0.0.0.0或用--publish modehost替代docker network inspect overlay返回空数组该网络未在当前节点激活Overlay 网络需至少一个容器接入才创建本地 VXLAN 实例docker network ls | grep overlay启动一个临时容器接入该网络docker run -d --network overlay --rm alpine:latest sleep 3600curl http://swarm-ip:port返回Connection refusedingress网络未正确初始化或docker_gwbridgeMTU 不匹配ip link show docker_gwbridge | grep mtuip link set docker_gwbridge mtu 1450重启dockerdSwarm 节点docker node ls显示Down状态dockerd与 Swarm Manager 通信中断常见于防火墙拦截2377/7946/4789端口telnet mgr-ip 2377nc -u mgr-ip 4789开放端口firewall-cmd --permanent --add-port{2377,7946}/tcpfirewall-cmd --permanent --add-port4789/udp4.2 深度排查案例一次持续 17 小时的 “DNS 解析缓慢” 故障故障现象某 SaaS 平台上线新版本后用户报告登录页面加载慢 10s。docker service logs web无错误curl -v http://api:3000/health在 web 容器内耗时 8s 才返回200。初步怀疑是 API 服务性能问题但docker stats api-service显示 CPU 5%内存稳定。排查路径确认是否网络问题在web容器内执行time curl -o /dev/null -s -w %{http_code}\n http://api:3000/health耗时 8.2s执行time ping api耗时 0.2s。结论DNS 解析占 8sHTTP 通信仅 0.2s。检查 DNS 配置docker exec web-container cat /etc/resolv.conf显示nameserver 127.0.0.11 options ndots:0127.0.0.11是 Docker 内嵌 DNS 的地址正常。抓包分析在web容器内apk add tcpdump tcpdump -i eth0 port 53 -w dns.pcap然后curl http://api:3000/health。分析dns.pcap发现DNS 查询发出后127.0.0.11无响应3s 后重传再 3s 后重传第 3 次才收到响应。定位 DNS 服务瓶颈docker service ps embedded-dnsDocker 无此服务名需查dockerd进程。实际执行ps aux \| grep dockerd发现dockerd进程 RSS 内存达 12GB正常应 1GB。top -p $(pgrep dockerd)显示dockerdCPU 100%strace -p $(pgrep dockerd)显示大量epoll_wait调用。根因锁定docker network inspect prod-app \| jq .[0].Containers返回 237 个容器记录。Docker 内嵌 DNS 在解析时需遍历所有容器的hostname和aliasesO(n) 复杂度。237 个容器导致单次解析耗时 3s。终极修复立即措施将prod-app网络拆分为prod-web10 个容器和prod-api227 个容器web服务只接入prod-web通过--network prod-api的方式让web容器也能访问apiDocker 支持多网络容器跨网解析。长期方案弃用内嵌 DNS接入 Consul 作为外部服务发现web容器通过consul-template生成/etc/hosts解析时间降至 5ms。实操心得Docker 内嵌 DNS 的容器数量阈值是 150。超过此数解析延迟呈指数增长。这不是 Bug是设计取舍——它为小规模场景优化而非为大规模服务网格设计。生产环境容器数 100 时必须规划 DNS 替代方案。4.3 防火墙与安全组配置被忽略的“最后一公里”Docker 网络的很多问题根源不在 Docker 本身而在宿主机防火墙或云平台安全组。以下是必须开放的端口清单TCP/UDP端口协议用途是否必须2377TCPSwarm Manager 通信Raft是Manager 节点间7946TCP/UDP节点间容器网络状态同步Gossip是所有节点间4789UDPVXLAN 数据平面Overlay 流量是所有节点间12376TCPDocker Engine API若远程管理否建议禁用用 SSH 代理云平台安全组配置要点以 AWS Security Group 为例