跨节点容器网络通信指南：从静态路由到VXLAN Overlay

跨节点的容器间网络通信，这标题光看可能觉得没什么，但真上手做容器集群的时候，它往往是第一个让你半夜爬起来抓包的东西。单机环境下跑几个 Docker 容器，网络折腾起来几乎是无感的——你只需要知道-p 8080:80这种端口映射就能干活。可一旦容器分布在两台、三台甚至更多宿主机上，事情就完全变了：两个容器的 IP 怎么分配、跨主机之后数据包怎么走、防火墙和路由怎么配合，这些问题一个处理不好，服务就是不通。这篇文章我会把跨节点容器网络的底层逻辑拆开讲清楚，从最省事的“普通路由 + 独立网段”方案，一直聊到生产环境常用的 VXLAN Overlay 网络，把每一步的原理、参数和踩坑点都给你过一遍。适合谁看？正在搭多机 Docker 集群、准备上 Kubernetes 需要选网络插件，以及被跨主机容器不通这个问题折磨过的人，看完基本都能自己定位问题。

1. 跨节点容器通信到底在解决什么问题

1.1 单机网络的习惯性直觉，到多机就失灵了

先回忆一下单机 Docker 给你自动做的事。Docker 启动时会创建一个名为docker0的 Linux bridge，默认网段是172.17.0.0/16，在这个网段里给每个容器分配一个 IP。每个容器内部有一对 veth 虚拟网卡，一头塞进容器，另一头挂到docker0上。容器发出去的包，经过docker0，再由宿主机的 iptables NAT 规则做 MASQUERADE，也就是源地址伪装成宿主机 IP，然后从物理网卡发到外部世界。

这套机制在单机上运行得非常好，你几乎感觉不到它的存在。但问题来了：如果第二台宿主机也用同样的默认配置，它同样创建docker0，同样用172.17.0.0/16。两台机器上跑起来的容器，很可能都是172.17.0.2。这种地址冲突放在单机里不是问题，因为网络是隔离的，但一旦你想让两个容器跨主机通信，就彻底乱套了。数据包到了宿主机路由表，看到目标是172.17.0.0/16，只会在本地找这个网段的接口；如果本地没有这个容器，包就丢了，根本不会想到“这个 IP 也许在另一台机器上”。地址空间必须全局唯一，这是跨节点容器通信要过的第一道关。

我遇到过不少新手把两台服务器上的容器都跑起来，然后在 A 机器上pingB 机器里的容器 IP，发现完全不通，第一反应是去查防火墙、查安全组，折腾一圈最后才发现网段重叠了。这种问题用一条命令就能确认：在宿主机上看ip route show table main，如果路由表里指向容器网段的路由全部通过本机docker0，而对端机器的容器网段与本地完全一致，那路由就没法区分到底该把包转发到哪里。所以做跨节点组网前，先做网段规划，比配置什么工具都重要。

1.2 跨节点通信绕不开的三个核心问题

我把跨节点容器网络拆解成三个核心问题，只要你把这三点想明白了，后面无论用哪种方案，都是在给这些问题找答案。

第一个问题是地址规划。每一台宿主机的容器网段必须不重叠，而且最好不与物理局域网、办公室 Wi-Fi、云上 VPC 的网络段重叠。否则就会出现“容器想去访问192.168.31.5这台打印机，结果这个 IP 被某台宿主机上的容器占用了”的尴尬场景。

第二个问题是数据通路。报文从源容器出来，先经过容器里的路由表，确认默认网关是 veth 对应的 bridge，然后穿过虚拟网卡，到达宿主机内核，宿主机再根据目的 IP 查询自己的路由表，决定是发给本机的 bridge 还是转发给物理网卡。如果是转发，宿主机还要把报文交给物理网卡的下一跳设备。到了对端宿主机，又要经过它自己的路由表，最终从目标 veth 进到目标容器里。这中间任何一环缺了路由、缺了转发许可、缺了网卡，通信就断了。

第三个问题是安全策略。单机模式下容器和外界是被 NAT 和防火墙隔开的，出站流量经过 MASQUERADE 伪装成宿主机 IP，外部想直接访问容器必须经过端口映射。跨节点通信如果直接用路由打通，等价于让两个宿主机之间的容器网段完全暴露给对方。容器网段之间要不要做访问控制？是不是所有容器都能互相访问？是否需要做源地址伪装？这些问题如果不提前设计，后面出安全事件会非常被动。

如果用一个生活化的类比：每台宿主机像一栋公寓楼，容器是楼里的房间，docker0是楼里的走廊。单机模式下，房间号（容器 IP）在每栋楼里是独立编号的，你要出去串门，得先走到楼外的世界（NAT 出去），别人再从外部大堂进来找你。而跨节点通信要做的是，把“房间号”设计成整个小区全局唯一的，然后给每栋楼之间修一条直接通行的路，让住户不用绕到小区外也能串门。修路的方式，可以是物业在每个楼门口挂一块“去 XX 栋请直行”的牌子（路由表），也可以在地下挖一条隧道（VXLAN）。

2. 主流方案与选型：从路由直连到 Overlay

2.1 宿主机路由直连：性能和简单性兼顾

最朴素也最常见的小规模跨节点方案，就是宿主机路由直连。思路很简单：给每台宿主机分配互不重叠的容器网段，在宿主机的路由表里手动加几条静态路由，把“去往对端容器网段”的流量下一跳指向对端宿主机 IP。比如 node1 的容器网段是172.30.1.0/24，node2 的容器网段是172.30.2.0/24，那就在 node1 上加一条路由172.30.2.0/24 via 192.168.31.102，在 node2 上加一条逆向路由172.30.1.0/24 via 192.168.31.101。

这个方案最大的优势是性能和简单性。数据包从容器出来，经过宿主机路由直接走物理网卡，没有任何封装和解封装的开销，延迟和吞吐基本等同于直接跑在宿主机网络上。对于延迟敏感的服务，比如数据库集群、缓存中间件这类场景，路由直连往往比 overlay 网络表现更稳。它的第二个优势是排查问题很直观，ip route get看一下下一跳，tcpdump -i eth0抓一下包，问题就定位了，不需要理解隧道和封装。

但它有非常明显的上限。节点数量一多，比如超过三四十台，静态路由表会变成一场噩梦。每加一台宿主机，要至少改一遍其他所有节点的路由表，人肉维护几乎等于给自己埋雷。另外，路由直连要求宿主机之间的三层网络是通着的，而且宿主机之间没有任何隔离关系。如果宿主机分布在不同的机架、不同的 VLAN，或者靠云厂商的虚拟网络组网，静态路由的维护成本就直线上升。所以路由直连适合两到十几台、且物理网络相对简单的场景，再多就要考虑动态路由或 CNI 方案了。

2.2 VXLAN Overlay：跨三层网络的容器组网

当宿主机不在同一个二层网络里，或者你需要把容器网络和物理网络彻底隔离的时候，VXLAN 这类 Overlay 方案就派上用场了。VXLAN 的核心思想是把二层以太网帧封装在 UDP 报文里，借助底层 IP 网络传输。每个虚拟网络用一个 24 位的 VNI（VXLAN Network Identifier）来标识，最多支持 1600 万个隔离的二层网络，VNI 相同的隧道端点之间交换数据帧，VNI 不同的网络天然隔离。

用 Overlay 网络最典型的场景是：容器跑在多个机架甚至多云平台上，底层网络是三层路由，无法做二层广播，但上层应用又希望容器拥有稳定、可迁移的 IP 地址。Kubernetes 里的 Pod 调度位置会频繁变化，Pod 的 IP 不能跟着宿主机变，这时候必须有一个不依赖物理拓扑的虚拟网络层。VXLAN 隧道把数据包从宿主机 A 的容器网段，封装后穿过任意三层网络，送到宿主机 B 再解封装，从宿主机 B 的角度看，就像收到一个二层帧一样自然。

代价也很现实。VXLAN 每传一个包要额外增加约 50 字节的头部开销，导致 MTU 必须相应下调，MTU 问题引发的“小包通、大包不通”是我在真实环境里见过最多的隐形故障之一。另外，隧道通信依赖 UDP 4789 端口，如果宿主机之间有防火墙或安全组拦了这个端口，隧道就直接瘫痪。性能方面，虽然现代内核和网卡对 VXLAN 有 offload 优化，eBPF 方案也能明显缓解，但相比纯路由，依然有可感知的 CPU 消耗和延迟差异。

2.3 Macvlan/IPVlan：容器当独立主机用

第三种方案是 Macvlan 和 IPVlan，思路和前两种完全不同。Macvlan 直接把宿主机的物理网卡虚拟出多个子接口，每个子接口拥有独立的 MAC 地址，容器挂上去之后，在交换机看来就是局域网里多了一台真实的机器，它有自己独立的 MAC 和 IP，可以直接被外部设备访问，不需要端口映射，甚至不需要宿主机转发。这对于那些需要容器直接暴露到局域网、且希望外部网络能管理它们设备的场景非常有用。

不过 Macvlan 的限制也不少。依赖物理网卡支持，云厂商的 VPC 里很多方案不让用户自己管理 MAC，跑不起来；Macvlan 的 bridge 模式下宿主机自身反而无法访问容器，因为报文被物理网卡直接丢弃了，这是新手最容易踩的坑；另外，它也没有天然的跨节点三层组网能力，两台宿主机上的 Macvlan 容器要互通，还是依赖底层网络的网关和路由。IPvlan 共享物理网卡的 MAC，用 IP 区分设备，能绕开 MAC 数量限制，但网络策略上不够精细。所以这个方案在基础设施自建的物理机场景里偶尔会用，容器上云后基本不碰。

2.4 CNI 插件：Kubernetes 场景下的选择

如果你已经上了 Kubernetes，网络方案的选择权基本就落在 CNI 插件手里了。Kubernetes 本身不实现网络，它通过 CNI 接口调用插件，把 Pod 的网络命名空间、veth、路由这些底层细节交给插件去编排。跨节点 Pod 通信，本质上还是我们前面说的那些问题的自动化版本。

Flannel 是最常见的入门选择。它的 host-gw 后端本质是宿主机路由直连，性能好，配置简单，但要求宿主机二层互通；VXLAN 后端则允许跨三层组网，代价是封装开销。Calico 采用 BGP 动态路由，节点多的时候可以用路由反射器收敛路由表，性能好，网络策略也非常强大，是生产环境最常见的 CNI 之一。Cilium 用 eBPF 技术把网络转发、负载均衡、可观测性都做进了内核态，性能指标非常亮眼，但对内核版本和运维能力有一定要求。选型上我一般这样判断：节点规模几十台以内、只想快速跑通，优先 Flannel host-gw；需要跨机房、跨运营商组网且规模中等，Calico VXLAN 或 Flannel VXLAN 都行；追求极致网络性能和大规模集群，Cilium 值得投入精力。

我把几个方案的对比整理成了表格，方便快速选型：

3. 实操：宿主机路由方案实现跨节点容器互通

3.1 网段规划与 Docker 网络配置

直接拿一套我最近带新人复现过的环境来演示。两台 Ubuntu 22.04 宿主机，node1的 IP 是192.168.31.101，node2的 IP 是192.168.31.102，两机在同一个二层网段。规划容器网段：node1 用172.30.1.0/24，node2 用172.30.2.0/24，网关分别取.1。这样每个宿主机上最多可以跑 254 个容器，网段号一眼能看出是哪台机器，后续加节点直接递增，运维上非常清晰。

第一步是让 Docker 把容器的默认网段改掉。改默认docker0的方式是在/etc/docker/daemon.json里写：

{ "bip": "172.30.1.1/24" }

改完执行systemctl restart docker，docker0就会变成172.30.1.1。node2 上对应写成172.30.2.1/24。这块要注意，改之前先停掉本机所有依赖 docker0 的容器和自定义网络，否则旧的容器网段仍然残留在路由表里，反而制造混乱。

我更推荐第二种方式，不改全局 daemon，而是为每个跨节点项目单独建一个自定义 bridge。这样做的好处是隔离性好，不影响机器上其他普通容器：

docker network create -d bridge \ --subnet=172.30.1.0/24 \ --gateway=172.30.1.1 \ prod-net

之后启动容器的命令里加--net prod-net就行。两种方式选一种，千万别同时混用，否则两套网段互相干扰时，排查的人会疯掉。

3.2 静态路由、内核转发与防火墙放行

网段配好之后，容器在各自宿主机上是能通的了，但跨宿主机的包还出不去。先打开内核 IPv4 转发，这是宿主机作为路由器转发容器流量的前提，默认 sysctl 值可能是 0：

sysctl -w net.ipv4.ip_forward=1 echo 'net.ipv4.ip_forward=1' >> /etc/sysctl.conf

然后在两台机器上各加一条指向对方容器网段的静态路由。node1 上执行：

ip route add 172.30.2.0/24 via 192.168.31.102 dev eth0

node2 上执行反向的：

ip route add 172.30.1.0/24 via 192.168.31.101 dev eth0

这两条命令的含义是：本机收到目的地址属于对端容器网段的包时，不要尝试在本地找接口，直接发给对端宿主机的物理网卡。宿主机收到后，再把包交给它自己的docker0，最终进容器。

路由加完之后，防火墙往往是下一个绊脚石。如果你的宿主机用的是 CentOS 默认 firewalld，它默认会 DROP 掉 FORWARD 链的流量。Docker 自己会在 iptables 里加规则，但自定义网络或者某些场景下规则不完整，为了保险起见，我一般直接加上两条显式放行：

iptables -I FORWARD -s 172.30.1.0/24 -d 172.30.2.0/24 -j ACCEPT iptables -I FORWARD -s 172.30.2.0/24 -d 172.30.1.0/24 -j ACCEPT

注意这里的入口是 FORWARD 链，不是 INPUT 链。很多新手在这里只用iptables -A INPUT -j ACCEPT放行，结果发现流量还是进不来，就是因为宿主机本来就不是这种业务的最终目的地，它只负责转发，转发路径受 FORWARD 链管控。

3.3 关键一步：绕开 Docker 的 MASQUERADE

这一步是整个跨节点路由方案里最容易出问题、也最容易被忽略的地方。Docker 默认会给通过docker0出去的流量加一条MASQUERADE规则，把源地址伪装成宿主机的 IP。单机模式下这样没问题，但跨主机路由模式下，node1 的容器访问 node2 容器的包经过 node1 宿主机时，源 IP 被伪装成了192.168.31.101，node2 的容器收到请求只能看到宿主机 IP，看不到真实的容器源 IP，所有基于源 IP 的认证、日志、限流全部失效，而且回包路由也会变得不对称，出现“能通但服务异常”的诡异现象。

解决办法是在 nat 表的 POSTROUTING 链最前面插入一条 RETURN 规则，让目的地址属于容器网段的包直接跳过 MASQUERADE：

iptables -t nat -I POSTROUTING -s 172.30.1.0/24 -d 172.30.2.0/24 -j RETURN iptables -t nat -I POSTROUTING -s 172.30.2.0/24 -d 172.30.1.0/24 -j RETURN

这两条规则的意思是：源地址来自本机容器网段、目的地址是对方容器网段的包，直接返回，不做地址伪装。这样容器对容器之间通信时，源 IP 保持真实。容器访问外部互联网时，仍然走 Docker 默认的 MASQUERADE，不受影响。这里建议在配置路由的第一时间就把这两条加上，不要等到业务跑起来再补，否则中间所有耗时都会被算进“网络不通”的排查时间里。

3.4 验证连通性、抓包与持久化配置

配置完成后，验证一下。在 node1 上用自定义网络跑一个 nginx：

docker run -d --name web --net prod-net -p 80:80 nginx:alpine

查看容器 IP：

docker inspect web | grep IPAddress

得到的 IP 比如是172.30.1.10。然后在 node2 上跑一个临时测试容器：

docker run -it --rm --net prod-net curlimages/curl

进到容器里先ping 172.30.1.10，如果通了，说明二层链路是通的；再curl http://172.30.1.10，如果页面能返回，说明 TCP 层的转发也正常。如果 ping 不通，在 node1 宿主机上抓包看包到底走到哪一步：

tcpdump -i eth0 icmp tcpdump -i docker0 icmp

对比两个抓包结果：如果eth0有报文但docker0没有，说明路由没进容器网桥；如果docker0有收到但容器没回包，可能是对端容器的路由或者 iptables 问题。排查思路要一层层剥。

最后是持久化配置的问题。路由、sysctl、iptables 规则都是重启即失的，必须配置成开机自动生效。Ubuntu 22.04 使用 netplan 的写法是在/etc/netplan下的 yaml 文件里加 routes：

network: ethernets: eth0: routes: - to: 172.30.2.0/24 via: 192.168.31.102

CentOS 系的写法是写在/etc/sysconfig/network-scripts/route-eth0里，一行一条：

172.30.1.0/24 via 192.168.31.101 dev eth0

iptables 规则用iptables-save > /etc/iptables.rules保存，再配合 systemd unit 在开机时iptables-restore。我个人的习惯是写一个network-init.sh脚本，把 sysctl、路由、iptables 全部放进去，在/etc/rc.local或 systemd service 里调用一次，这样换机器、初始化新节点的时候复制脚本改一下 IP 就能复用，比分散管理多条配置更容易维护。

4. 进阶实操：VXLAN Overlay 网络的搭法与原理

4.1 手动建一条 VXLAN 隧道

理解了 Overlay 原理之后，我建议你亲自动手搭一条最简 VXLAN 隧道，不用任何工具，就用ip命令。这一条隧道通了之后，再去看 Flannel 或者 Calico 的配置，你会觉得那些配置文件只是在做同样的事情，只是在更大规模上自动化。

在 node1 上执行：

ip link add vxlan100 type vxlan id 100 \ remote 192.168.31.102 \ local 192.168.31.101 \ dstport 4789 dev eth0 ip addr add 10.200.1.1/24 dev vxlan100 ip link set vxlan100 up

在 node2 上执行对称命令：

ip link add vxlan100 type vxlan id 100 \ remote 192.168.31.101 \ local 192.168.31.102 \ dstport 4789 dev eth0 ip addr add 10.200.1.2/24 dev vxlan100 ip link set vxlan100 up

id 100就是 VNI，两端必须一致，相当于两人约定走同一条隧道；remote是对端的物理 IP，也就是 VXLAN 隧道终点；dstport 4789是 VXLAN 的 UDP 标准端口。建好之后，node1 上ping 10.200.1.2，通了就说明隧道已经工作。

这时候抓个包看看，感受非常直观。在 node1 上开一个终端：

tcpdump -i eth0 udp port 4789 -v

然后在另一个终端 ping 隧道对端，你会看到抓包结果里有一个外层 UDP 报文，目的端口 4789，里面封装着完整的 VXLAN 头，VNI 是 100，再往里才是完整的内层二层的 ICMP 请求帧。这就解释了 Overlay 网络为什么能跨三层：底层网络只需要认得宿主机 IP 就够了，容器之间的二层帧被完整地塞进了 UDP 的 payload 里。

手动搭隧道能让你彻底弄懂数据面，但生产环境不会这么做，因为 VXLAN 隧道端的发现、VNI 的管理、节点的动态加入退出，全靠手动指令是不现实的。了解原理之后，把工作交给 Flannel。

4.2 Flannel VXLAN 模式的数据流转

Flannel 的 VXLAN 模式下，每个节点上会创建一个叫flannel.1的 VXLAN 设备，同时flanneld这个进程负责从 etcd（或 Kubernetes CRD）里读取整个集群的 PodCIDR 分配情况，维护每个节点的“隧道对端地址映射”。当一个 Pod 的流量目标 IP 属于另一个节点上 Pod 的网段时，宿主机路由表会把这个包路由给flannel.1，再由 Linux VXLAN 设备封装成 UDP，从物理网卡发往对端宿主机。

整个数据流可以用一句话串起来：Pod A 发出报文，进入容器的 veth，到达宿主机上的cni0网桥，根据路由表判断目标网段不在本机，于是交给flannel.1，在flannel.1内核里完成 VXLAN 封装，从eth0发出 UDP 包；对端宿主机eth0收到后，内核识别出 UDP 4789 端口且 VNI 匹配，解封装还原出原始以太网帧，交给本机的flannel.1，再进入cni0网桥，最后从目标 Pod 的 veth 进入 Pod。

对比我们手动搭的隧道，Flannel 多做了两件事：一是自动维护了每个节点的隧道配置，新节点加入集群时flanneld会自动更新其他节点的 FDB 表；二是把 VXLAN 设备和 CNI 的cni0网桥接在了一起，Pod 创建时网络插件会自动完成 veth、网关、路由表的全部设置。你要做的，只是在部署 K8s 时给flanneld一个 backend 配置，声明用 VXLAN 模式。

4.3 MTU 问题：最隐蔽的坑

Overlay 网络最大的坑就是 MTU。原因很简单：VXLAN 给二层帧加了外层 IP 头 20 字节、UDP 头 8 字节、VXLAN 头 8 字节，一共 36 到 50 字节的开销。如果底层物理网卡 MTU 是标准以太网的 1500，VXLAN 设备的 MTU 必须降到 1450 左右，否则封装之后总长度超过 1500，底层网络只能分片或者丢包。

MTU 出问题时的典型症状非常有辨识度：ping小包通，大包不通；HTTP 页面能打开一半，图片加载不出来；ssh连接卡住但偶尔又能敲几个字；scp传输大文件速度奇慢或者直接中断。这些现象非常容易让人误判成“网络质量不好”“延迟太高”“防火墙限制”，白白排查很久。

验证 MTU 问题最快的方式是强制不分片地发大包：

ping -M do -s 1420 目标PodIP ping -M do -s 1472 目标PodIP

-M do意思是禁止分片，-s指定载荷大小。如果 1420 通、1472 不通，那基本就是 MTU 问题。修改 MTU 的方法取决于你的网络方案：Docker 自定义 VXLAN 网络创建时指定--opt com.docker.network.driver.mtu=1450；Flannel 在配置里写"MTU": 1450；K8s 的 CNI 插件也有对应的 MTU 参数。如果你跑在云主机上，底层 veth 本身 MTU 就低于 1500，那 VXLAN 设备的 MTU 要再往下降，总之遵循一个原则：隧道内层 MTU = 底层实际数据面 MTU − 隧道封装修约。宁可调低一点，尤其是对时延敏感的业务，分片带来的连锁问题比按一个过高 MTU 量的损失大得多。

5. 跨节点容器网络的故障排查

5.1 ICMP 通、TCP 连不上的排查顺序

跨节点容器网络里面最气人的一种故障是：容器之间ping通了，但业务端口怎么都连不上。当你排除掉路由、防火墙、安全组都正常之后，问题多半转移到了“服务本身能不能被访问”这件事上。

先看目标容器里的服务监听地址。用docker exec进去执行ss -lntp，如果服务监听的是127.0.0.1:8080，那对不起，它只接受容器本机的回环流量，宿主机都访问不了，更别提跨节点。跨节点访问要求服务监听0.0.0.0或::。这个话题我在帮人排查“容器里 centos7.9 启动 sshd 失败”时经常遇到：sshd 进程起来了，但从别的机器就是连不上，排查一圈发现ListenAddress配成了127.0.0.1，或者 sshd 压根没有在容器 PID 1 体系下正常启动。排查顺序应该是：先确认进程在不在、监听地址对不对，再看容器网络和宿主机路由，最后才是抓包看端口到达情况。

排查命令很有讲究。容器内看监听用ss -lntp；宿主机上看连接状态用ss -tn state established '( sport = :8080 )'；想看报文有没有到对端容器，用 tcpdump 抓容器 veth 或 docker0 上的 8080 端口流量。如果报文到了容器网桥但容器内没回包，那就是服务监听问题；如果报文压根没到网桥，就往上游路由查。

5.2 防火墙与安全策略的常见坑

跨节点打通之后，安全反而要收紧。很多人以为容器网段之间通了就万事大吉，结果镜像里的服务被同一网段的其他容器扫到，等于在集群内部开了一堆没锁的门。这里我要提一下“镜像安全和容器安全”的话题：镜像里的不必要端口、弱口令、漏洞组件，在单机网络隔离下危害有限，但跨节点网络一旦打通，攻击面就变成整个集群。所以要在网络层做最小化放行：容器网段之间只允许 80、443、数据库端口、内部 RPC 端口通过，其余默认 DROP，再配合镜像扫描和运行时监控。

Overlay 网络另外要留意的是防火墙对 UDP 4789 端口的放行。不仅宿主机本地防火墙要放行，云上的安全组、分布式 ACL 也要放。如果隧道两端 ping 不通，先确认 4789 端口路径是否界面。我排查过一个 Flannel 跨云场景，底层安全组只开放了常见 TCP 端口，UDP 4789 被默认挡掉，症状是 Pod 创建都正常，但跨节点的 Pod 永远 ping 不通，抓包看到 UDP 包发出去石沉大海。这种问题不看安全组配置，在服务器本地瞎折腾是永远查不出来的。

还有一个容易忽略的是 Docker daemon 的 API 暴露。有些部署图省事把 Docker 的 TCP 端口暴露到所有网卡，这等于把整个宿主机的容器管理权限暴露给网络。跨节点网络环境里，任何一个被攻陷的容器都可能通过 Docker API 对其他节点发起操作。建议只在回环地址监听 Docker API，或者直接不监听 TCP，使用 Unix socket 加访问控制。

5.3 Windows 宿主机与虚拟化环境里的网络差异

很多人在 Windows 或 Mac 上做跨节点容器实验，会遇到一堆在 Linux 物理机上完全不会出现的现象。比如热词里那个“应用程序-特定权限设置并未向在应用程序容器 不可用 sid 中运行的地址”的报错，看起来很像 Linux 容器网络的权限问题，其实是 Windows 的 AppContainer 隔离机制在设置网络策略时，SID 无法解析导致的。Windows 原生容器和 Linux 容器的网络栈完全不同，进程隔离容器共享宿主机内核网络栈，Hyper-V 隔离容器跑在轻量虚拟机里，网络行为几乎等于一台虚拟机配 NAT，不能用 Linux 语境下的docker0、iptables、veth 去理解。

如果你用 Docker Desktop，它本质上是在虚拟机里跑 Linux，容器的网络是 NAT 或桥接到 WSL2 的虚拟交换机，容器看到的物理网络和你宿主机看到的完全不是一回事。跨节点实验建议还是上两台真正的 Linux 服务器，或者最少用两台带桥接网络的虚拟机。用 KVM 或 VMware 做实验时，要确认虚拟交换机的“混杂模式”已开启，否则容器持有非宿主机 MAC 地址的报文会被虚拟交换机过滤掉，宿主机之间永远无法互通，物理上很好用的路由直连在虚拟机里就变成“为什么我明明配了路由还是不通”的经典谜题。宝塔面板或其他管理工具里如果看到容器网络的选项，也建议先确认底层虚拟化类型，再决定采用哪种网络方案。

5.4 排查工具箱与速查表

跨节点容器网络的链路分层太多，定位问题最忌讳的是乱试。我的习惯是从源容器出发，按报文经过的每一层逐级确认：源容器路由、veth、宿主机路由、物理链路、对端宿主机路由、对端 veth、目标容器。每一层用一个命令验证，能快速把故障缩小到具体某一段。

偶尔容器内部路由表也会出问题，尤其是用了多个自定义网络的时候。容器内默认路由不存在，会导致容器只和同网段通，跨网段全丢。检查命令是docker exec <容器> ip route，正常应该有一条 default via 指向其网关。如果容器里没有 ip 命令，用docker exec <容器> cat /proc/net/route也能看到路由表内容。

6. 生产环境落地心得

6.1 网段规划与路由维护的工程实践

我在生产环境有几个吃了亏之后养成的习惯，非常适合直接抄。第一，容器网段绝对不要用房间局域网常见的192.168.x.x，也别用172.17.x.x这种 Docker 默认段，建议规划一个独立的大段，比如10.80.0.0/16作为容器网络专用，每个节点切一个/24子网。这样网络拓扑图、防火墙策略、路由表都清晰，也不会和公司内部乱七八糟的 Wi-Fi、打印机、NAS 网段撞车。

第二，所有网络变更必须有记录。静态路由和防火墙规则不像代码有版本管理，人工维护非常容易发生“这台机器上次没加 RETURN 规则”这种事故。我的做法是把所有节点网络初始化的命令写成一个幂等脚本，新机器初始化时跑一遍，脚本里用注释标明每一条命令的用途，配合在变更前先ip route save > /tmp/routes.bak，万一改错了能快速回滚。节点规模到 50 台以上时，静态路由方案就该退役了，直接上 Calico BGP，把路由分发给专门的路由器或反射器接管，人肉改路由表的事一定不要干。

第三，容器网络和物理资源的隔离要一起规划。跨节点通信打通后，容器的 CPU、内存、磁盘 IO 依然要在 yaml 或 docker run 参数里设置限制，避免某个容器把宿主机资源占满后影响整个集群的网络稳定性。资源隔离和网络隔离是两条线，都做好才算一个健康的集群。

6.2 性能验证、监控与容量评估

跨节点网络上线前，我建议用 iperf3 做一次基准测试。分别在两个节点起测试容器，一个跑iperf3 -s，另一个跑iperf3 -c 对端容器IP，能测出实际的 TCP 吞吐。第一次测如果发现吞吐异常低，先用-u测 UDP 模式，区分是 TCP 层的问题（比如拥塞控制、MTU）还是链路本身的问题。这里有个容易踩的细节：iperf3 默认单线程，容器分配到的 vCPU 核数和网卡队列数会直接影响单流吞吐，所以压测时容器要预留足够的 CPU 配额。

监控方面，宿主机上的 conntrack 表是目前最容易漏掉的瓶颈。跨节点通信量大了之后，NAT 和连接跟踪项会占满 conntrack 表，导致新建连接被丢包。检查命令是：

cat /proc/sys/net/netfilter/nf_conntrack_count cat /proc/sys/net/netfilter/nf_conntrack_max

如果nf_conntrack_count接近nf_conntrack_max，就要考虑调大 max，或者优化 NAT 规则减少无谓的连接跟踪项。VXLAN 隧道模式下还要关注宿主机 CPU 和网卡 offload 能力，如果网卡不支持 VXLAN offload，隧道流量会把 CPU 打满，尤其是 10G 以上网卡环境，这个影响会非常明显。

最后提醒一点：容器网络方案确定后不要频繁切换。路由直连换成 VXLAN，意味着所有节点的 MTU、防火墙规则、Pod IP 可能全部要跟着变，切换过程中的流量闪断和配置遗漏比网络本身的问题更让人头疼。我习惯的做法是先在几台测试节点上做灰度切换，验证监控指标稳定后再批量执行，尽量做到可回滚。

我个人实际做下来最深的体会是，跨节点容器通信的坑往往不在“通信”本身，而在“你以为已经通的链路”上。很多问题不是网络真的断了，而是源地址被伪装了、MTU 被忽略了、某个端口被安全组挡了。排查的时候别急着怀疑底层隧道，先用ip route get把源、目的、下一跳三个要素确认清楚，再用 tcpdump 逐层抓包定位，比到处乱试高效得多。另外一个小技巧：每加一个新节点，先在宿主机上用ip route get验证路由，再进容器验证业务，可以省掉大量重复的排查时间。把这个习惯保持住，跨节点容器组网这件事，其实远没有流传的那么玄乎。