为什么容器网络会成为性能瓶颈？
先看关键判断
折腾Flannel Host-GW时，我发现最麻烦的往往不是安装，而是配置。在Kubernetes集群中，Pod被设计为“随时会死”的临时实体，但它们的IP地址需要在不同Node之间畅通无阻。这就依赖容器网络插件（CNI）来创建一个跨节点的覆盖网络或直连网络。Flannel作为最轻量的CNI之一，提供了两种主流模式：Host-GW（主机网关）和VXLAN（虚拟扩展局域网）。很多新手会困惑：一个简单配置就能跑起来的网络，为什么还要纠结性能？
答案藏在数据包的路径里。每多一次封装、多一次查表，都会带来微秒级的延迟和额外的CPU开销。当集群流量达到数百Gbps时，这种差异会放大成显著的吞吐差距。本文不会给出“哪个更好”的绝对结论，而是带你从原理层面理解两种模式的“取舍逻辑”。
补充参考：此处可内链到“Flannel Host-GW故障排查实例”。
Flannel究竟是什么？
容易忽略的细节
Flannel是一个专门解决“跨节点Pod互通”问题的网络插件。它的核心思路是为每个Node分配一个独立的子网（如10.244.1.0/24），然后通过某种“隧道”或“路由”让这些子网之间可以通信。Flannel不处理NetworkPolicy、Service负载均衡等高级功能——它只负责让Pod的IP能跨节点可达，简单而高效。
Host-GW和VXLAN就是Flannel实现这种跨节点通信的两种具体策略。理解了它们背后的“交通工具”，你就理解了性能差异的来源。
关联教程：此处可内链到“Flannel Host-GW部署与验证”内容。
进阶阅读：此处可内链到“Flannel Host-GW性能优化”指南。
Host-GW：用路由表取代隧道
工作原理
Host-GW模式本质上是一种三层路由方案。Flannel在每个Node上配置路由表，将其他Node的Pod子网下一跳指向对方Node的物理网卡IP。例如，Node A（物理IP 192.168.1.10）上的Pod要访问Node B（物理IP 192.168.1.20）上的Pod，数据包会直接通过Node A的物理网卡发送给Node B的物理网卡，Node B收到后再根据路由转发到目标Pod。
这意味着数据包在网络中没有任何额外封装，就是标准的IP报文。内核只做一次路由查找，然后交由底层网络转发。
适用条件
Host-GW要求集群内所有Node必须处于同一个二层网络（即可以直接ARP通信）。如果Node跨越了路由器或VLAN，Host-GW就无法工作，因为路由表无法跨越三层边界。
性能特点
- 低延迟：没有封装解封装开销，接近裸机网络性能。
- 高吞吐：CPU几乎不参与数据包修改，适合大流量场景。
- 依赖底层网络：一旦底层网络出现拥塞或延迟，Host-GW没有自己的重传机制，完全依赖物理网络能力。
相关阅读：此处可内链到“Flannel Host-GW常见问题”专题。
VXLAN：建立虚拟隧道与Flannel Host-GW
工作原理
VXLAN是一种二层overlay技术，它将原始的Pod IP报文封装在一个新的UDP数据包中，并通过物理网络传输。Flannel为每个Node的VXLAN隧道分配一个VTEP（VXLAN Tunnel End Point），节点之间通过UDP 8472端口通信。数据包在节点内部的流程：Pod发往其他Node的Pod的IP包 -> 被内核VXLAN模块封装，加上外层UDP头、IP头 -> 从物理网卡发出 -> 目标Node收到后解封装 -> 转发给目标Pod。
这种封装引入了额外的头部开销（约50字节），并且CPU需要执行封装/解封装操作。
适用条件
VXLAN不要求Node在同一二层网络，它可以在三层网络之上构建虚拟二层连接。因此适合跨机房、跨VPC（但需要允许UDP端口通信）的集群。
性能特点
- 更高的CPU占用：每个数据包都需要CPU介入封装。虽然现代内核有offload技术（如GSO/GRO、TSO等）可以减少一部分开销，但相比Host-GW仍有差距。
- 更大的延迟：封装/解封装增加微秒级延迟。
- MTU问题：由于额外头部，物理网卡MTU需预留，否则会导致分片。通常建议设置MTU为1450（物理网络1500减去50）。如果忽略此设置，会出现奇怪丢包。
延伸阅读：此处可内链到“Flannel Host-GW配置案例”相关文章。
两者的性能差异有多大？——不编造数据，讲清变量
很多测试报告会给出具体数值（如Host-GW延迟比VXLAN低30%），但这些数值高度依赖测试环境：CPU型号、网卡特性、内核版本、数据包大小、并发数等。对于小白来说，真正重要的是理解性能差异的来源，而不是记住一个特定值。
我们可以从两个关键维度分析：
延迟（Latency）
Host-GW的延迟几乎等于物理网卡本身的传输延迟加上二层交换机转发延迟。VXLAN则多了一次CPU处理时间和UDP封装/解封时间。在小包场景（如Redis、心跳检测）下，这种差异会更明显，因为CPU处理时间占比较小包传输时间更大。
吞吐（Throughput）
吞吐主要受CPU处理能力制约。VXLAN模式下，如果CPU核心数不足或网卡不支持VXLAN offload（如Intel X710等），吞吐可能只有Host-GW的70%~80%。但如果网卡支持硬件加速，差异会缩小。
一个常见的误区：认为VXLAN就一定比Host-GW“慢很多”。实际上在大包大流量场景（如视频流、文件传输）下，由于每包的处理开销相对固定且占比下降，两者的吞吐差距可能缩小到10%以内。所以选型不能只看“模式”，还要看你的核心业务流量特征。
如何做一次简单的自我测试？与Flannel Host-GW
验证与回滚
如果希望验证自己集群的表现，可以用以下工具和方法（注意：不要在生产环境跑破坏性测试）：
- iperf3：跨节点两个Pod之间跑TCP/UDP吞吐测试，分别记录Host-GW和VXLAN下的结果。
- ping：测量跨节点Pod之间的ICMP延迟（虽然不是精确的包延迟，但能反映趋势）。
- netperf：更细致的TCP_RR测试可以反映小包请求/响应场景的延迟。
- tcpdump：在Node上抓包，观察VXLAN模式下是否有额外的UDP报文，以及是否存在分片。
关键控制变量：
- 确保两种模式下的Pod IP网段、MTU设置一致（VXLAN需要检查物理网卡MTU是否预留）。
- 最好在集群压力较低时进行，避免其他业务干扰。
- 记录CPU使用率（通过top或sar），观察VXLAN是否导致更高的系统开销。
如果你发现VXLAN模式的性能远低于预期，首先检查：
- 物理网卡MTU设置是否合理？
- 内核是否开启VXLAN offload（ethtool -k eth0 | grep vxlan）？
- 是否有防火墙或iptables规则干扰UDP 8472端口？
选型建议：不要为了“性能”而盲目选择
先看关键判断
很多人直接选择Host-GW因为它“性能更好”，但忽略了一个前提：你的节点是否真的位于同一二层网络？ 在公有云环境下，VPC内的节点虽然可以内网互通，但通常属于三层网络（即使有ARP广播域限制），VXLAN才是更稳妥的选择。在私有化部署且交换机支持VLAN的情况下，Host-GW可以获得极致性能。
另一个被低估的因素：运维复杂度
Host-GW的路由表完全由Flannel管理，一旦节点IP变动或网络拓扑变化，Flannel会自动更新路由。但如果你需要手动添加额外路由（比如和物理网络互通），Host-GW的配逻辑更简单直接。VXLAN的隧道维护相对复杂，需要对UDP端口、VTEP等有一定理解。
用一句话总结：
- 追求极低延迟 + 同一二层网络 → Host-GW
- 需要跨三层网络 + 容忍少量性能损失 → VXLAN
- 不确定网络拓扑但想快速验证 → 先用VXLAN，后续再根据测试数据决定是否切换到Host-GW
结语：性能不是唯一维度
实际操作要点
Flannel的Host-GW和VXLAN是两种完美的互补方案。对于初学者来说，与其纠结“哪个更快”，不如先理解自己集群的网络约束条件。如果二层网络可达，Host-GW是天然的选择；如果需要跨子网或跨机房，VXLAN是必须付出的代价。掌握这些原理后，你就能在遇到性能问题时快速定位——是网络模式本身的问题，还是MTU、CPU offload等配置缺失导致的。
希望本文能帮你走完从“只会跑通”到“理解为什么跑得快”的第一步。真正做好Flannel Host-GW，靠的不是参数堆砌，而是持续验证。
延伸阅读