1. 项目概述这不是教你怎么敲命令而是带你搞懂 Docker 网络的“交通管制系统”你有没有遇到过这样的场景本地跑得好好的两个容器一上测试环境就 ping 不通或者 Swarm 集群里服务明明部署成功却死活访问不到前端页面又或者调试一个微服务调用链时抓包发现请求根本没出宿主机网卡——不是代码问题是网络在“装死”。这背后90% 的根因不是 Docker 写得烂而是我们对它的网络模型理解得太浅。Docker Networking这个词听起来像运维黑盒但其实它就是一套高度抽象、可编程的 Linux 网络交通管制系统docker0是老城区十字路口bridge网络是新建的封闭园区环线overlay是跨城高速而macvlan就是给容器直接发一张市政交通卡让它混进物理局域网里开车。本项目标题里的 “Mastering” 不是指背熟docker network create --driver bridge这条命令而是要你能站在内核 netns网络命名空间视角看懂veth对是如何穿墙打洞的明白iptables规则怎么在DOCKER-USER链里悄悄放行或拦截流量清楚Swarm的ingress网络为什么既不是纯 overlay 也不是纯 host而是一套带负载均衡的混合路由架构。它适合三类人正在从单机开发转向多节点部署的后端工程师、需要稳定交付容器化中间件的 DevOps 工程师、以及被 CI/CD 流水线中偶发网络超时问题反复折磨的 SRE。如果你还停留在--network host能解决问题就绝不碰自定义网络的阶段那这篇内容就是为你量身定制的“网络认知升级手册”。2. 整体设计思路拆解为什么必须放弃 docker0又不能盲目拥抱 Swarm2.1 从 docker0 到自定义 bridge一次必须做的“断奶手术”刚接触 Docker 的人几乎都默认使用docker0网桥。它由 Docker daemon 自动创建所有未指定网络的容器都会被接入其中IP 段通常是172.17.0.0/16。这看似省事实则埋下三颗定时炸弹第一颗是IP 地址冲突炸弹。docker0的子网段是硬编码的当你本地开发环境和公司测试环境都用默认配置时一旦通过 VPN 连接172.17.0.10很可能和某台测试服务器的真实 IP 重叠导致路由混乱。我亲眼见过一个团队因为这个原因花了三天排查“服务间调用偶尔失败”最后发现是curl http://172.17.0.5:8080实际走的是宿主机到测试服务器的物理路由而非容器内部通信。第二颗是安全隔离失效炸弹。docker0是全局共享的所有容器都在同一个二层广播域。这意味着 A 项目容器能直接arp-scan -l扫出 B 项目容器的 MAC 地址甚至用nmap对其发起端口扫描——这在多租户或敏感业务共存的环境中是不可接受的。Linux 的网络命名空间本意是强隔离但docker0把它变成了“开放式办公室”。第三颗是排障能力归零炸弹。当网络异常发生时docker0下堆叠了太多自动注入的iptables规则DOCKER,DOCKER-ISOLATION-STAGE-1等它们像一层毛玻璃让你无法看清真实的数据包走向。tcpdump -i docker0抓到的包你根本分不清是哪个容器发出的因为所有流量都经过docker0的统一 NAT 处理。所以“Custom Bridges” 不是锦上添花而是生存必需。我们创建docker network create --driver bridge --subnet192.168.100.0/24 --gateway192.168.100.1 myapp-net本质是在 Linux 内核里新建一个独立的netns并为其分配专属的brctl网桥设备。这个网桥不与docker0互通每个容器启动时Docker 会为其创建一对veth虚拟以太网设备一端留在容器的netns内作为eth0另一端插入宿主机的myapp-net网桥。这种设计让 IP 分配、ARP 表、防火墙规则全部收束在一个可控范围内相当于为每个应用划出一块“网络特区”。提示不要用--internal参数盲目关闭外部访问。很多教程把它当作“安全开关”但实际它只是禁用了网桥的iptablesSNAT 规则容器仍可通过宿主机路由访问外网。真正的隔离应结合--ipam-driver和--opt com.docker.network.bridge.enable_ip_masqueradefalse组合使用。2.2 从单机 bridge 到 Swarm overlay跨越“物理边界”的必然选择当你把应用从一台机器扩展到三台、五台甚至几十台服务器组成的集群时bridge网络立刻失效。原因很朴素bridge是二层技术依赖 ARP 广播发现邻居而不同宿主机上的容器物理上不在同一个交换机下ARP 请求根本传不过去。这时候overlay网络登场了。但很多人误以为overlay就是“把 Docker 网络搬到 UDP 上”这是巨大误解。Docker Swarm 的overlay网络底层基于vxlanVirtual Extensible LAN但它绝非简单封装。VXLAN 本身只解决“如何把二层帧跨三层网络传输”的问题而 Swarm 在其之上叠加了三重关键机制控制平面Control Plane由dockerd的内置 Raft 共识模块实现。当你在 manager 节点执行docker network create -d overlay myswarm-net时该操作不是在单台机器上生效而是作为一条日志条目写入 Raft 日志经多数派确认后同步到所有 manager 节点。这意味着网络定义本身具备强一致性不会出现“A 节点说有这个网络B 节点说没有”的脑裂。数据平面Data Plane每个 worker 节点上运行一个dockerd子进程dockerd --data-root /var/lib/docker它会监听 Raft 同步来的网络事件并在本地创建对应的vxlan设备如vxlan-1000。当容器 A在 Node1要访问容器 B在 Node2时Node1 的vxlan-1000设备会将原始以太网帧封装进 UDP 包目标地址是 Node2 的 VXLAN 端点 IP即 Node2 的docker_gwbridge网关地址端口固定为8472。Node2 收到后解封装再根据FDBForwarding Database表将帧投递给正确的容器。服务发现Service Discovery这才是 Swarm 网络的灵魂。overlay网络本身不提供 DNS但 Swarm 会为每个服务自动注册一个tasks.service-name的 DNS 记录。当你在容器内执行ping tasks.webDNS 解析返回的不是单个 IP而是一个包含所有web服务实例 IP 的列表。更关键的是这个解析结果会被容器内的glibc或musl库缓存并在后续连接时进行轮询。这使得curl http://tasks.api:8000/users这样的调用天然具备客户端负载均衡能力无需额外部署 Nginx 或 Traefik。因此“Swarm-Ready Architectures” 的核心不是堆砌docker stack deploy命令而是理解这套控制面数据面服务发现三位一体的协同逻辑。它要求你放弃“单机思维”转而用“分布式状态机”的视角去设计网络拓扑。3. 核心细节解析与实操要点从 veth 对到 ingress 网络的逐层穿透3.1 自定义 Bridge 网络的底层实现veth、netns 与 iptables 的三角关系要真正掌控自定义 bridge必须亲手拆解它的三个核心组件veth对、网络命名空间netns、以及iptables规则链。下面以创建一个名为mynet的 bridge 网络为例全程跟踪数据包流向。首先执行docker network create --driver bridge --subnet192.168.200.0/24 --gateway192.168.200.1 mynet。此时Docker 在宿主机上做了三件事创建网桥设备ip link add name br-mynet type bridge然后ip addr add 192.168.200.1/24 dev br-mynet ip link set br-mynet up。你可以用brctl show看到br-mynet已存在但目前没有端口。配置 iptables 规则Docker 会向filter表的FORWARD链插入两条关键规则-A FORWARD -i br-mynet -o br-mynet -j ACCEPT -A FORWARD -i br-mynet -o eth0 -j ACCEPT第一条允许br-mynet网桥内部的容器互访即二层转发第二条允许容器通过br-mynet访问宿主机的eth0即出站上网。注意这里没有-o docker0说明mynet和docker0是完全隔离的。准备 IPAMIP 地址管理Docker 使用内置的defaultIPAM 驱动将192.168.200.0/24划分为可用池并记录已分配的 IP。接着启动一个容器docker run -it --network mynet --name c1 alpine sh。这时Docker 在宿主机上执行创建一对veth设备vethc1a和vethc1b。将vethc1b的一端插入br-mynet网桥brctl addif br-mynet vethc1b。将vethc1a的一端移动到容器的netns中并重命名为eth0。在容器netns内为eth0分配 IPip addr add 192.168.200.2/24 dev eth0并设置默认网关ip route add default via 192.168.200.1。现在当你在容器c1内执行ping 192.168.200.1即网关数据包流向是c1的eth0发出 ICMP 请求经vethc1a-vethc1b进入宿主机br-mynetbr-mynet查找 MAC 地址表发现192.168.200.1对应自身即网桥的 IP于是将包交给协议栈处理宿主机内核的ICMP模块响应ping reply原路返回。而当你执行ping 8.8.8.8时流程变为c1发出请求目标 IP 是8.8.8.8因默认网关是192.168.200.1包被送到br-mynetbr-mynet查表发现8.8.8.8不在本地子网于是将包交给宿主机的eth0接口此时iptables的POSTROUTING链中的MASQUERADE规则生效-t nat -A POSTROUTING -s 192.168.200.0/24 ! -o br-mynet -j MASQUERADE将源 IP 替换为宿主机eth0的公网 IP包最终从eth0发出。注意MASQUERADE是动态 NAT适用于宿主机 IP 可能变化的场景如 DHCP。若宿主机有固定公网 IP应改用SNAT性能更高-t nat -A POSTROUTING -s 192.168.200.0/24 ! -o br-mynet -j SNAT --to-source 203.0.113.10。3.2 Overlay 网络的 VXLAN 封装与解封装抓包实录理解overlay的关键在于亲眼看到 VXLAN 封包过程。我们搭建一个最小 Swarm 集群1 个 managerIP192.168.1.101 个 workerIP192.168.1.11。在 manager 上创建 overlay 网络docker network create -d overlay --attachable myoverlay。注意--attachable参数它允许独立容器非 Swarm service接入此网络方便调试。在 worker 上启动一个容器docker run -it --network myoverlay --name w1 alpine sh。此时worker 节点上会自动生成一个vxlan-1000设备ID 1000 来自网络 ID# ip -d link show vxlan-1000 7: vxlan-1000: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1450 qdisc noqueue master docker_gwbridge state UNKNOWN mode DEFAULT group default link/ether 02:42:ac:12:00:02 brd ff:ff:ff:ff:ff:ff promiscuity 1 vxlan id 1000 srcport 0 0 dstport 8472 proxy l2miss l3miss ageing 300 udpcsum关键参数解读mtu 1450VXLAN 封装会增加 50 字节8 字节 VXLAN header 20 字节 IP header 20 字节 UDP header 2 字节 UDP checksum所以原始容器 MTU 必须从 1500 降到 1450否则大包会被丢弃。dstport 8472VXLAN 标准端口。proxy l2miss l3miss启用代理模式当本地 FDB 表找不到目标 MAC 时会向所有 VXLAN 端点泛洪 ARP 请求。现在在w1容器内执行ping 10.0.0.2假设 manager 上有一个容器m1分配了此 IP。我们在 worker 的eth0接口上抓包tcpdump -i eth0 -nn -X udp port 8472你会看到类似这样的输出10:22:34.123456 IP 192.168.1.11.52123 192.168.1.10.8472: UDP, length 102 0x0000: 0000 0000 0000 0000 0000 0000 0800 4500 ................E. 0x0010: 0066 0000 4000 4011 0000 c0a8 010b c0a8 .f.............. 0x0020: 010a ca0b 20e8 0052 0000 0000 0800 0000 .......R.......... 0x0030: 0000 0000 0000 0000 0000 0000 0000 0000 .................. 0x0040: 0000 0000 0000 0000 0000 0000 0000 0000 .................. 0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 .................. 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 .................. 0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ..................其中0x0020行的c0a8 010a就是192.168.1.10manager IP的十六进制表示。UDP 负载部分0x0030开始就是被封装的原始以太网帧。这个帧的源 MAC 是w1的eth0目标 MAC 是m1的eth0而 IP 层的目标地址是10.0.0.2。整个过程对上层应用完全透明ping命令只看到一个普通的 ICMP 请求/响应循环。3.3 Ingress 网络Swarm 的“隐形高速公路”与它的双面性ingress网络是 Swarm 最神秘也最易被误解的组件。当你部署一个带有publish端口的服务如docker service create --publish 8080:80 nginx流量并非直接进入你的容器而是先流经ingress网络。它不是一个用户可管理的overlay网络而是一个由 Swarm 自动创建、深度集成的特殊网络。ingress的核心功能是集群范围的负载均衡Load Balancing和服务发现Service Discovery。其工作原理如下当你在任意节点访问http://node-ip:8080时请求首先到达该节点的docker_gwbridge一个特殊的 bridge 网络用于连接 Swarm 的ingress网络和宿主机。docker_gwbridge将请求转发给ingress-sboxIngress Sandbox这是一个运行在每个节点上的轻量级网络沙箱容器。ingress-sbox内部运行着ipvsIP Virtual Server模块。ipvs是 Linux 内核的四层负载均衡器比iptables性能高一个数量级。它维护着一个virtual server列表其中10.255.0.1:8080是你的服务的 VIPVirtual IP。ipvs根据预设的调度算法默认rr轮询将请求转发给后端真实容器的 IP即tasks.nginx解析出的某个实例 IP。这个过程可以用ipvsadm命令验证。在任意 Swarm 节点上执行# ipvsadm -L -n IP Virtual Server version 1.2.1 (size4096) Prot LocalAddress:Port Scheduler Flags - RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 10.255.0.1:8080 rr - 10.0.0.3:80 Masq 1 0 0 - 10.0.0.4:80 Masq 1 0 0这里10.255.0.1就是ingress网络的 VIP10.0.0.3和10.0.0.4是两个nginx容器的 IP。ingress的双面性在于它提供了开箱即用的高可用但也引入了额外的跳数和潜在瓶颈。ipvs转发虽然快但所有publish流量都必须经过ingress-sbox如果服务并发量极大单个节点的ingress-sbox可能成为性能瓶颈。这就是为什么生产环境强烈建议对于高吞吐 API 服务使用host模式发布端口--publish modehost,target80,published8080绕过ingress直接绑定到宿主机端口对于 Web 前端等需要 TLS 终止的场景部署专用的反向代理如 Traefik让它通过tasks.serviceDNS 直连后端同样规避ingress。实操心得ingress网络的 VIP10.255.0.1是固定的但它的子网10.255.0.0/16可以通过--default-addr-pool参数在初始化 Swarm 时修改。如果你的公司内网恰好用了10.255.0.0/16那么docker swarm init --default-addr-pool 10.200.0.0/16 --default-addr-pool-mask-length 24就是必选项否则会导致路由冲突。4. 实操过程与核心环节实现从零构建一个生产级 Swarm 网络架构4.1 环境准备与基础网络规划一份必须手写的“网络宪法”在动手之前必须完成一份详尽的网络规划文档我称之为“网络宪法”。它不是可有可无的纸面功夫而是避免后期大规模重构的唯一保障。以下是我为一个中型电商项目制定的宪法范本你可以直接套用网络类型名称子网用途是否加密备注HosthostN/A宿主机直连用于监控、日志采集等基础设施否所有节点必须开放2377Swarm 管理端口、7946节点发现、4789VXLANBridgedocker_gwbridge172.18.0.0/16连接ingress网络与宿主机禁止用户容器接入否初始化 Swarm 时自动创建可通过--fixed-cidr修改Overlayprod-overlay10.100.0.0/16生产环境所有服务的默认网络启用加密是--opt encrypted是底线防止同网段嗅探Overlaydev-overlay10.101.0.0/16开发/测试环境网络不加密便于抓包调试否与prod-overlay物理隔离无任何路由Ingressingress10.255.0.0/16集群负载均衡禁止手动修改是由 Swarm 自动管理这份宪法的核心原则是“三隔离”环境隔离prod和dev使用完全不同的 overlay 子网确保即使配置错误开发容器也无法访问生产数据库。功能隔离docker_gwbridge仅服务于ingress用户容器严禁接入避免污染。加密隔离生产环境强制--opt encrypted它会在 VXLAN 封装前用 AES-GCM 对原始以太网帧进行加密密钥由 Swarm Raft 集群安全分发。初始化 Swarm 时严格按宪法执行# 在 manager 节点执行 docker swarm init \ --advertise-addr 192.168.1.10 \ --listen-addr 192.168.1.10:2377 \ --default-addr-pool 10.100.0.0/16 \ --default-addr-pool-mask-length 24 \ --data-path-addr 192.168.1.10 # 加入 worker 节点 docker swarm join \ --token SWMTKN-1-abc123... \ --advertise-addr 192.168.1.11 \ --listen-addr 192.168.1.11:2377 \ 192.168.1.10:2377注意--data-path-addr参数至关重要。它指定了 VXLAN 数据面通信所用的 IP 地址。如果节点有多个网卡如eth0内网eth1公网必须明确指定内网 IP否则 VXLAN 流量会走错网卡导致集群脑裂。4.2 构建高可用 MySQL 集群网络配置决定生死MySQL 在容器化环境中极易因网络配置不当而“假死”。我们以部署一个主从复制的 MySQL 集群为例展示如何将网络宪法落地。第一步创建专用 overlay 网络# 在 manager 上执行 docker network create \ -d overlay \ --opt encrypted \ --subnet10.100.10.0/24 \ --gateway10.100.10.1 \ mysql-net这里--opt encrypted是强制项--subnet严格遵循宪法为 MySQL 单独划出/24子网避免与其他服务 IP 冲突。第二步部署 MySQL 主节点masterdocker service create \ --name mysql-master \ --network mysql-net \ --replicas 1 \ --constraint node.rolemanager \ --env MYSQL_ROOT_PASSWORDsecret \ --env MYSQL_DATABASEecommerce \ --mount typevolume,sourcemysql-master-data,destination/var/lib/mysql \ --publish published3306,target3306,modehost \ mysql:8.0关键点解析--network mysql-net确保主节点只在加密的mysql-net内通信。--publish modehost不使用ingress。MySQL 是有状态服务ingress的 VIP 会掩盖真实的主节点位置且ipvs转发对长连接不友好。modehost让它直接绑定到 manager 节点的3306端口应用通过manager-ip:3306访问语义清晰。--constraint node.rolemanager强制主节点只在 manager 上运行利用其高可用性。第三步部署 MySQL 从节点slavedocker service create \ --name mysql-slave \ --network mysql-net \ --replicas 2 \ --constraint node.roleworker \ --env MYSQL_ROOT_PASSWORDsecret \ --env MYSQL_MASTER_HOSTmysql-master \ --env MYSQL_MASTER_USERrepl \ --env MYSQL_MASTER_PASSWORDreplpass \ --mount typevolume,sourcemysql-slave-data,destination/var/lib/mysql \ --publish published3307,target3306,modehost \ mysql:8.0这里--env MYSQL_MASTER_HOSTmysql-master是灵魂。由于mysql-net是 overlay 网络mysql-master这个服务名会被 Swarm 的内置 DNS 解析为mysql-master服务的所有任务 IP即主节点的 IP。从节点启动时会自动向这个 IP 发起主从复制连接。--publish 3307是为了区分端口避免与主节点冲突。第四步验证网络连通性在mysql-slave容器内执行# 验证 DNS 解析 nslookup mysql-master # 验证 TCP 连通性注意必须用 mysql-master 的 VIP不是 localhost telnet mysql-master 3306 # 验证 MySQL 复制状态 mysql -h mysql-master -uroot -psecret -e SHOW SLAVE STATUS\G如果telnet失败99% 是mysql-net网络未正确创建或--opt encrypted导致握手超时需检查节点时间是否同步。如果SHOW SLAVE STATUS显示Seconds_Behind_Master: NULL说明复制通道未建立大概率是MYSQL_MASTER_HOST环境变量指向了错误的主机名。4.3 构建弹性 Web 前端Traefik Overlay 的黄金组合Web 前端是流量入口必须兼顾安全性、可观测性和弹性。ingress网络在此场景下是次优解我们采用 Traefik 作为反向代理它与 Docker 的集成堪称完美。第一步创建 Traefik 专用网络docker network create \ -d overlay \ --subnet10.100.20.0/24 \ --gateway10.100.20.1 \ traefik-net这个网络将 Traefik 与后端服务隔离开来只允许必要的通信。第二步部署 Traefik 服务docker service create \ --name traefik \ --network traefik-net \ --publish published80,target80,modehost \ --publish published443,target443,modehost \ --publish published8080,target8080,modehost \ --constraint node.rolemanager \ --mount typebind,source/var/run/docker.sock,destination/var/run/docker.sock,readonly \ --env TRAEFIK_PROVIDERS_DOCKERtrue \ --env TRAEFIK_PROVIDERS_DOCKER_SWARMMODEtrue \ --env TRAEFIK_PROVIDERS_DOCKER_EXPOSEDBYDEFAULTfalse \ --env TRAEFIK_ENTRYPOINTS_WEB_ADDRESS:80 \ --env TRAEFIK_ENTRYPOINTS_WEBSECURE_ADDRESS:443 \ --env TRAEFIK_API_INSECUREtrue \ --env TRAEFIK_METRICS_PROMETHEUStrue \ traefik:v2.10关键配置说明--publish modehost再次强调入口流量不走ingress避免单点瓶颈。--mount ... /var/run/docker.sockTraefik 通过 Docker Socket 实时监听服务事件自动更新路由规则。TRAEFIK_PROVIDERS_DOCKER_EXPOSEDBYDEFAULTfalse安全基线要求每个服务必须显式声明traefik.enabletrue才能被暴露。第三步部署 Web 服务并关联 Traefikdocker service create \ --name web-app \ --network traefik-net \ --network mysql-net \ --replicas 3 \ --label traefik.enabletrue \ --label traefik.http.routers.web.ruleHost(www.example.com) \ --label traefik.http.routers.web.entrypointsweb \ --label traefik.http.services.web.loadbalancer.server.port80 \ nginx:alpine这里--network traefik-net让 Web 容器能与 Traefik 通信--network mysql-net让它能访问数据库。--label是关键它告诉 Traefik“这个服务叫web当请求 Host 头是www.example.com时把它路由过来目标端口是 80”。部署完成后访问http://www.example.comTraefik 会自动将请求负载均衡到三个web-app实例。你可以在 Traefik 的 Dashboardhttp://manager-ip:8080上实时看到所有路由、服务和中间件的状态。实操心得Traefik 的--label配置非常灵活可以添加traefik.http.middlewares.ssl-redirect.redirectscheme.schemehttps实现 HTTP 自动跳转 HTTPS或traefik.http.routers.web.tlstrue启用 Lets Encrypt 自动证书。这些都不需要重启服务配置即刻生效。5. 常见问题与排查技巧实录那些年我们一起踩过的网络深坑5.1 问题速查表从症状到根因的快速定位症状可能根因排查命令解决方案容器内ping宿主机 IP 失败宿主机防火墙ufw/firewalld阻止了FORWARD链sudo ufw status verbosesudo iptables -L FORWARD -n -vsudo ufw allow in on br-m