2. 云原生网络挑战与卸载需求
容器网络在云原生环境中承担着 Pod 之间、Pod 与 Service、Pod 与外部网络之间的全部通信。它看起来只是“把包发出去”，但在实际数据路径上，一个数据包往往要穿过 veth pair、Linux bridge、iptables/ipset、conntrack、Overlay 隧道封装、物理网卡驱动与队列等多个环节。理解这些环节的开销来源，才能判断什么时候需要 SR-IOV，什么时候需要 DPU/IPU 来卸载。
一、容器网络性能瓶颈从哪里来
先看一个典型场景：两个 Pod 位于不同节点，通过 VXLAN Overlay 通信。数据包从源容器发出后，大致经历以下路径：
- 容器 eth0 发出报文，经 veth pair 进入宿主机网络命名空间；
- 宿主机 bridge 或路由模块查表转发，iptables/ipset 做 Service、NetworkPolicy 匹配；
- conntrack 记录连接状态，NAT 改写源/目的地址；
- VXLAN 封装：增加 50 字节左右的外层头（14 字节以太 + 20 字节 IP + 8 字节 UDP + 8 字节 VXLAN）；
- 封装后的报文进入物理网卡队列，由驱动发送；
- 对端节点解封装、反向查表、再送入目标容器。
这条路径上的主要开销可以归纳为四类：
- CPU 上下文与内存拷贝：veth、bridge、隧道封装通常涉及多次 skb 分配与拷贝，单核处理小包时容易成为瓶颈。
- 规则匹配开销：iptables 规则随 Service、Pod 数量增长而线性膨胀，kube-proxy 的 iptables 模式在数千 Service 规模下匹配延迟明显上升。
- 封装开销：VXLAN/Geneve 增加额外头部，降低有效 MTU，并带来封装/解封装计算成本。
- 中断与队列：高 PPS 场景下，网卡中断、NAPI 轮询、单队列竞争会限制吞吐。
这些开销并非在所有场景都致命。小规模集群、低带宽业务可能完全感知不到；但当出现高 PPS、低延迟、大带宽或密集 Service 访问时，瓶颈就会暴露。判断是否需要卸载，关键看三个指标：PPS、端到端延迟、CPU 占用。如果业务在 10Gbps 线速下 CPU 已被网络软中断占满，或 Service 数量超过数千后延迟抖动明显，就说明需要重新审视数据路径。
二、CNI 模型：插件化与数据路径选择
CNI（Container Network Interface）定义了一套标准接口：容器运行时在创建/删除网络命名空间时调用 CNI 插件，插件负责分配 IP、配置接口、设置路由。CNI 本身不规定数据路径，只规定“怎么被调用”。因此不同插件可以实现完全不同的转发模型：
- Bridge + veth：最常见，Pod 通过 veth 接入宿主机 bridge，跨节点靠路由或 Overlay。实现简单，但路径长、规则多。
- Overlay（VXLAN/Geneve）：在 Underlay 之上建隧道，Pod IP 可跨子网。灵活但封装开销大。
- Underlay / 路由型：Pod IP 直接由物理网络路由可达，无封装，性能好，但要求网络与 IP 规划配合。
- SR-IOV / 智能网卡：把 VF 直接给 Pod，绕过宿主机内核数据路径，接近线速。
CNI 的选择直接决定后续卸载方案。例如 Calico 的 IPIP/VXLAN 模式与 BGP 路由模式，数据路径完全不同；Cilium 用 eBPF 替代 iptables，减少规则匹配开销，但仍可能保留 veth 与隧道。理解 CNI 模型，就是理解“包从容器出来之后，第一跳交给谁”。
三、Overlay 封装开销的量化理解
以 VXLAN 为例，外层封装通常为：14 字节以太头 + 20 字节 IPv4 头 + 8 字节 UDP 头 + 8 字节 VXLAN 头 = 50 字节。若物理网络 MTU 为 1500，则容器内有效 MTU 约为 1450。若未正确设置，会出现“小包正常、大包丢包”的典型问题。
封装不仅占带宽，还消耗 CPU：每个包都要构造外层头、计算校验和、查 FDB 表。假设单节点 100 万 PPS、每包封装处理约 1 微秒，则仅封装就占用约 1 个 CPU 核。若业务要求 500 万 PPS，封装开销就会成为主要瓶颈。这也是为什么高性能场景倾向 Underlay 或硬件卸载。
四、SR-IOV 与 DPU/IPU 的引入动机
SR-IOV 的核心思想是：物理网卡通过 PF（Physical Function）管理，暴露多个 VF（Virtual Function），每个 VF 可直通给 Pod 或虚拟机。Pod 直接使用 VF 后，数据包不再经过宿主机 veth、bridge、iptables，而是由网卡硬件完成 DMA 与队列分发，显著降低 CPU 占用和延迟。
但 SR-IOV 也有代价：VF 数量有限、Pod 迁移与热插拔复杂、宿主机侧难以做统一策略与可观测性。于是 DPU/IPU 被引入：把网络、存储、安全卸载到独立处理器上，宿主机 CPU 只跑业务。DPU 可以承担 Overlay 封装/解封装、Service 负载均衡、NAT、防火墙、加密等，相当于把“基础设施数据路径”从主机 CPU 迁移到专用硬件。
下图给出从传统内核路径到 SR-IOV、DPU 卸载的对比关系，帮助判断不同方案的卸载位置与收益。
五、如何判断该不该卸载
卸载不是越早越好。可以从以下维度做判断：
| 判断维度 | 倾向内核路径 | 倾向 SR-IOV | 倾向 DPU/IPU |
|---|---|---|---|
| PPS / 带宽 | 低到中等 | 高 PPS、低延迟 | 极高 PPS、多租户 |
| CPU 预算 | 充足 | 希望释放主机 CPU | 主机 CPU 只跑业务 |
| 策略与可观测性 | 内核统一处理 | 需额外方案补足 | DPU 集中卸载 |
| 运维复杂度 | 低 | 中 | 高 |
实际工程中，常见做法是分层：普通业务走内核 CNI，高性能业务走 SR-IOV，基础设施与多租户安全策略交给 DPU。Marvell 的云原生网络卸载方案正是围绕这一分层思路，把 Overlay、Service、NAT、加密等从主机 CPU 迁移到 DPU/IPU，同时保留与 Kubernetes CNI 的对接能力。
softirq 占比、conntrack 条目数、iptables 规则数量与平均包大小。若 softirq 长期超过 30%、conntrack 接近上限、或 Service 规则超过 5000 条，就值得进一步验证 SR-IOV 或 DPU 方案。
总结来看，容器网络性能瓶颈来自内核数据路径的多次拷贝、规则匹配与封装开销；CNI 决定了第一跳的转发模型；Overlay 带来灵活性的同时也带来 50 字节左右的封装成本；SR-IOV 通过 VF 直通绕过内核，DPU/IPU 则把整个基础设施数据面卸载到专用硬件。理解这三者的位置与代价，才能在云原生网络设计中做出合理取舍。