容器集群 overlay 网络模式确实会带来可见的吞吐损耗，典型场景下 TCP 吞吐会下降一成到三成，小包场景可能更明显，但通过调整 MTU、开启网卡卸载、替换数据面插件，多数业务完全可以把损耗压到可接受范围。
先别急着否定 overlay，它的问题不是“有没有损耗”，而是“损耗从哪来、能压到多低”,下面拆开讲清楚。
容器集群 overlay 网络模式对吞吐的损耗大吗
先说结论：有损耗，但“大不大”要看插件、包大小、跨节点路径和物理网络质量。
Overlay 网络为了保证跨主机 Pod 互通，会在原始报文外面再套一层封装，以 Flannel 默认的 VXLAN 模式为例，数据包从 Pod 出来后会经历：
- 原始 TCP/IP 报文进入宿主机的 veth 设备
- 经 CNI 转发逻辑送到 flannel.1 虚拟网卡
- flannel.1 给原始报文加上 VXLAN 头、UDP 头、外层 IP 头
- 外层报文走物理网卡发到对端宿主机
- 对端宿主机解封装，再交给目标 Pod
每次封装和解封装都会消耗 CPU 周期，外层头部还占用了额外字节，导致有效载荷比例下降，MTU 没调整好，还会触发 IP 分片,吞吐会进一步恶化。
flannel vxlan 性能损耗多少
行业内常见测试里，Flannel VXLAN 跑大包 TCP 吞吐，通常比同节点或 underlay 网络低一成左右，小包场景损耗会冲到两到三成，这不是某个实验室的精确数字,而是多数公开压测结果落在的区间。
影响 flannel vxlan 损耗的主要因素有：
- MTU 是否匹配：默认物理网卡 MTU 是 1500，VXLAN 封装后外层头部多 50 字节，Pod 内 MTU 仍是 1500，就必然分片,分片对吞吐的打击远大于封装本身。
- 网卡卸载能力：物理网卡若支持 UDP 隧道卸载，封装可以由硬件完成，CPU 占用会大幅下降；不支持时,每包都要协议栈处理。
- 内核协议栈路径长短：Flannel 依赖 iptables 或内核路由转发，规则越多，每包经过的链路越长,吞吐越低。
overlay 和 underlay 网络性能对比：吞吐差距在哪
把 overlay 和 underlay 放在同一个集群里压测,你会看到差距主要集中在这几处。
大包场景
- Underlay 转发路径短，报文从 Pod 出去后基本直达物理网卡。
- Overlay 多一跳内核封装，有效带宽会下降,但通常还能跑到物理网卡的大部分能力。
小包场景
- 小包本身有效载荷低,封装头部占比急剧上升。
- 每包都需要协议栈处理，CPU 成为瓶颈,吞吐下降幅度远超大包。
跨可用区或跨地域场景
- 物理网络延迟变大后，overlay 的封装和解封装叠加到 RTT 上,吞吐受拥塞控制影响更严重。
- 这时 overlay 损耗不再是固定比例，延迟越高,有效吞吐下降越明显。
常见插件吞吐表现对比
| 网络模式 | 封装方式 | 吞吐损耗感受 | 适合场景 |
|---|---|---|---|
| Underlay/BGP | 不做封装 | 最低 | 高性能计算、数据库集群 |
| Flannel VXLAN | VXLAN + UDP 封装 | 小包偏高，大包中等 | 中小规模通用集群 |
| Calico IPIP | IP-in-IP 封装 | 中等，略低于 VXLAN 部分场景 | 跨网段、简单运维 |
| Cilium eBPF | 原生路由或 VXLAN + eBPF | 较低 | 大规模、高吞吐、可观测性要求高 |
这张表不是精确打分，只是根据公开资料和常见经验得出的相对感受，行业共识认为，选型时不要只盯着吞吐损耗百分比，还要把运维复杂度、网络策略能力、可观测性一起算进去。
K8s overlay 网络吞吐损耗怎么优化
优化思路很直接：少分片、少走 CPU、少跳内核。
调 MTU，让报文不再分片
这是收益最高的一步。
检查宿主机物理网卡 MTU：
ip link show eth0
如果物理网卡 MTU 是 1500，使用 VXLAN 时 Pod 内 MTU 应设为 1450 或更低，Flannel 部署时可以直接指定：
net-conf.json: |
{
"Network": "10.244.0.0/16",
"Backend": {
"Type": "vxlan",
"MTU": 1450
}
}
或者在 CNI 配置文件里调整：
vim /etc/cni/net.d/10-flannel.conflist
找到 vxlan 段落，设置
"mtu": 1450。
Pod 内部发送大数据包时，TCP 会根据 MSS 自动协商，不让报文超过 MTU 减去封装头的长度，MTU 调好后，分片消失,吞吐通常会有可见回升。
开启网卡卸载能力
物理网卡支持 UDP 隧道分段时，可以让硬件处理封装后的分片，减少 CPU 参与。
查看当前网卡特性：
ethtool -k eth0 | grep udp
如果显示 tx-udp_tnl-segmentation: off,可以尝试开启：
ethtool -K eth0 tx-udp_tnl-segmentation on
部分云厂商虚拟机网卡对嵌套卸载支持有限，开启失败就保持默认,不要强行修改。
换掉 iptables，走 eBPF 数据面
Cilium 用 eBPF 绕过大量 iptables 规则匹配，直接在内核里完成转发和策略判断，数据面路径变短后，小包吞吐会有明显改善，把 Flannel 换到 Cilium 原生路由模式，或者用 Calico eBPF 数据面,都是可行的替代思路。
替换前先确认内核版本：
uname -r
要求内核支持 eBPF 相关特性，5.4 以上内核比较稳妥。
调整内核缓冲区与队列参数
适当的缓冲区能让短时突发流量不掉队,避免重传拖累吞吐。
查看当前值：
sysctl net.core.rmem_max net.core.wmem_max
临时调大：
sysctl -w net.core.rmem_max=16777216 sysctl -w net.core.wmem_max=16777216
生产环境建议写入 /etc/sysctl.conf，再执行 sysctl -p。
用同节点 Pod 通信减少跨节点封装
如果两个服务频繁互相调用，又对吞吐敏感，可以把它们调度到同一台宿主机上，同节点 Pod 通信不经过 VXLAN 封装，吞吐基本等于宿主机本地转发能力，调度时使用 Pod 亲和性即可：
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchLabels:
app: fast-service
topologyKey: kubernetes.io/hostname
容器网络吞吐测试方法：如何定位损耗
光看插件文档没用,自己压测一遍才清楚。
搭建测试基线
在一个集群里分别部署两个测试 Pod：
- 两个 Pod 在同一节点，测本地基线
- 两个 Pod 在不同节点，测 overlay 跨节点性能
- 两个宿主机物理 IP 之间跑一遍，当作 underlay 基线
这样就能算出 overlay 相对 underlay 的损耗。
使用 iperf3 压 TCP 吞吐
服务端：
iperf3 -s
客户端：
iperf3 -c <pod-ip> -t 30 -P 4
记录默认结果后，再测小包或特定 MSS 场景：
iperf3 -c <pod-ip> -t 30 -P 4 -M 1400
对比前后数据，如果大包接近物理基线，小包明显掉速，说明 CPU 协议栈处理是主要瓶颈。
观察压测时的 CPU 占用
在宿主机上执行：
top
重点看 si 软中断和 ksoftirqd 占用，VXLAN 封装和解封装大量消耗软中断，物理网卡不支持卸载时，CPU 会先于带宽达到瓶颈。
Overlay 网络的吞吐损耗不是玄学，它来自封装头部、CPU 处理路径和分片，把 MTU 调对、开启网卡卸载、必要时换成 eBPF 数据面，多数业务完全能接受剩下的损耗，真正需要纠结的，是你要不要为了那点吞吐差异，放弃 overlay 带来的跨子网灵活性和安全策略能力。
Q&A：容器集群 overlay 网络模式吞吐损耗相关疑问
Q：overlay 网络模式一定会比 underlay 吞吐低吗？
A：不一定，overlay 数据面使用了硬件卸载能力，MTU 调整到位，大包吞吐可以接近 underlay 水平，但在小包密集、连接数高的场景下，overlay 的封装处理路径更长，吞吐通常仍会低于 underlay。
Q：云上 K8s 使用 overlay 网络，地域和可用区会影响吞吐损耗吗？
A：会，跨可用区、跨地域时物理延迟变大，TCP 拥塞控制对 RTT 更敏感，overlay 每包多了封装延迟，吞吐下降会比同地域更明显，地域距离越远,损耗叠加效应越突出。
Q：怎么判断当前集群 overlay 网络吞吐损耗是否正常？
A：跑 iperf3 对比大包和小包，记录同节点、跨节点、物理 IP 三组数据，大包吞吐能达到物理网卡的八成以上，小包吞吐达到物理基线六成以上，基本属于正常范围，若大包明显偏低，优先检查 MTU 是否导致分片；小包明显偏低,重点观察宿主机软中断和网卡卸载能力。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/642965.html
