容器网络性能优化通常面临一个核心矛盾：既要保持 Pod 调度的灵活性，又要降低数据路径上的转发开销。Veth + Linux Bridge 或者 Overlay 方案虽然部署简单，但每个数据包都要经过宿主机内核协议栈、iptables 规则和虚拟交换机，CPU 开销与延迟随之上升。SR-IOV（Single Root I/O Virtualization）提供了一条更直接的路径，它把物理网卡的一个物理功能（PF）拆分成多个轻量级虚拟功能（VF），每个 VF 可以独立映射给容器，数据包从容器用户态到网卡硬件只经过很短的路由，几乎不消耗宿主机 CPU。
与虚拟机场景不同，容器使用 SR-IOV 时不会模拟完整的 PCIe 设备。Kubernetes 环境中常见的做法是：SR-IOV Device Plugin 发现宿主机上的 VF 资源，向 kubelet 注册可分配的内核扩展资源，调度器为 Pod 分配 VF，CNI 插件再把对应 VF 移入容器的 netns。这套流程依赖设备插件和 CNI 协作完成，后面会详细展开。
SR-IOV 的核心机制：PF、VF 与直通路径
SR-IOV 的全称是 Single Root I/O Virtualization，它允许一个 PCIe 物理设备在硬件层面呈现为多个独立的虚拟设备。对网卡来说，物理网卡被称为物理功能（PF），每个虚拟出来的轻量级接口称为虚拟功能（VF）。PF 拥有完整的网卡配置能力，例如修改队列数、开关 VF、处理流量卸载；VF 则只负责数据收发，缺少管理能力。把一个 VF 直接映射到容器网络命名空间后，容器内的应用程序通过 VF 驱动直接与网卡硬件通信，数据路径不再经过宿主机内核的 TCP/IP 协议栈、Linux Bridge 和 iptables，这是 SR-IOV 实现低延迟、高吞吐的根本原因。
判断你的网卡是否支持 SR-IOV，可以用 sysfs 接口查看。以下命令在多数 Linux 发行版上都可以直接使用：
# 查看物理网卡支持的 VF 总数 cat /sys/class/net/enp4s0f0/device/sriov_totalvfs # 创建 8 个 VF echo 8 > /sys/class/net/enp4s0f0/device/sriov_numvfs # 查看生成的 VF 列表 ip link show enp4s0f0
上述命令中，sriov_totalvfs 表示网卡可以创建的最大 VF 数量，sriov_numvfs 是当前启用的 VF 数。执行后 PF 下面会出现 vf 0 到 vf 7 的条目。需要注意的是，某些服务器平台需要在 BIOS 中开启 SR-IOV 或 IOMMU，否则 sysfs 中的文件可能不存在或写入失败。
一个常见的误区是认为 VF 之间完全隔离，不会互相影响。实际上同一个物理网卡上的多个 VF 共享物理链路的带宽和硬件队列资源，如果某个 VF 的流量突然暴涨，仍然可能挤占其他 VF 的可用带宽。因此在高负载场景下，需要为不同业务划分不同的 PF，或者在交换机侧做更细粒度的限速。
在 Kubernetes 中启用 SR-IOV 的配置流程
Kubernetes 本身并不能直接识别 VF，需要借助 Multus CNI 和 SR-IOV Device Plugin 两个组件。Multus 允许一个 Pod 挂载多个网络接口，SR-IOV Device Plugin 负责把节点上的 VF 以扩展资源的形式暴露给调度器。安装完成后，首先要定义 NetworkAttachmentDefinition，它描述 Pod 附加网络的 CNI 配置，包括使用 sriov CNI、IPAM 方式以及 VF 的选择策略。
下面是一个典型的 NetworkAttachmentDefinition 示例：
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
name: sriov-net
namespace: kube-system
spec:
config: |
{
"type": "sriov",
"capabilities": {"ips": true},
"ipam": {
"type": "host-local",
"subnet": "10.10.10.0/24",
"rangeStart": "10.10.10.20",
"rangeEnd": "10.10.10.200",
"gateway": "10.10.10.1"
}
}
在这个配置中，type 固定为 sriov，ipam 使用 host-local 从 10.10.10.0/24 网段中给 Pod 分配地址。capabilities 中的 ips 表示启用静态 IP 分配能力。部署时请确保该 NetworkAttachmentDefinition 与 Device Plugin 的资源名称匹配，否则 Pod 无法绑定到正确的 VF。
然后创建 Pod 时，需要通过 annotations 指定附加网络，并在 resources 中请求 VF 资源。示例：
apiVersion: v1
kind: Pod
metadata:
name: latency-test-pod
annotations:
k8s.v1.cni.cncf.io/networks: sriov-net
spec:
containers:
- name: test
image: alpine:3.20
command: ["sleep", "3600"]
resources:
requests:
intel.com/sriov: '1'
limits:
intel.com/sriov: '1'
其中的 intel.com/sriov 并不是固定值，它来自 SR-IOV Device Plugin 的配置。你可以在 ConfigMap 中定义不同的资源池，把指定型号的 VF 划分给不同业务。例如将高性能网卡的 VF 标记为 sriov-netdevice，普通网卡的 VF 标记为 sriov-netdevice-shared。请求资源后，插件会从资源池中选择一个可用的 VF，CNI 再把它移动到 Pod 网络命名空间。
除了 host-local，生产环境更推荐使用 whereabouts 作为 IPAM 插件，因为 whereabouts 支持跨节点的子网管理，并且能避免 IP 冲突。配置时把 type 改为 whereabouts，增加 range 参数，其余类似。无论使用哪种 IPAM，都必须保证 Pod 删除后 CNI 能正确回收 VF，否则节点上会出现 VF 耗尽的问题。
性能对比与实际优化建议
SR-IOV 的主要收益体现在吞吐、延迟和 CPU 占用三个方面。在相同硬件条件下，Linux Bridge + Veth 模式的 64 字节小包转发率通常只有裸机网卡的 60% 到 70%，而 SR-IOV 能达到 90% 以上，延迟则可以降低到个位数微秒。对于高频交易、实时音视频、电信 UPF 等延迟敏感型负载，这种差异非常明显。
不过 SR-IOV 也不是没有代价。由于数据包绕过了宿主机内核，传统的网络调试工具如 tcpdump 在宿主机上无法抓取容器流量，必须进入容器内部或使用 VF 的端口镜像功能。同时，Service 的 kube-proxy 规则默认无法直接处理 SR-IOV 接口上的东西向流量，你需要额外配置相应路由或改用支持 SR-IOV 的 service 实现。另一个常见问题是 VF 数量有限，一块双口万兆网卡通常只支持 64 个 VF，大规模集群中需要提前规划 VF 资源池。
优化时建议关注以下几点：第一，开启硬件多队列，让多个 CPU 核同时处理某个 VF 的中断，命令为 ethtool -L vf-name combined 4；第二，确保 Pod 和 VF 在同一 NUMA 节点上，否则跨 NUMA 内存访问会抵消一部分性能收益；第三，把 MTU 设置为 9000 的巨型帧可以进一步提升大块数据传输效率；第四，配合 DPDK 使用 VF 可以让数据面完全运行在用户态，减少系统调用和中断开销，但这会引入额外的驱动绑定和 hugepages 配置。
# 查看 VF 与 NUMA 节点的关系 cat /sys/class/net/enp4s0f0/device/numa_node # 给 VF 设置 4 个队列 ethtool -L enp4s0f0v0 combined 4 # 测试 TCP 吞吐 iperf3 -c 10.10.10.20 -t 30 -P 8
如果集群中既有需要高性能网络的特殊 Pod，又有大量普通业务，推荐采用混合网络方案：普通业务继续使用 Calico 或 Flannel，延迟敏感业务通过 Multus 附加 SR-IOV 网络。这样既能保证大部分 Pod 的可观测性与网络策略能力，又能让关键服务获得硬件级转发性能。
常见故障排查思路
配置 SR-IOV 时最容易出现的问题是 VF 未正确暴露。先检查 BIOS 是否打开了 SR-IOV 和 IOMMU，再确认节点内核版本和网卡驱动是否支持。可以通过 dmesg 配合 grep 查看驱动加载日志。如果 sriov_numvfs 写入成功，但 Pod 启动后看不到第二个网卡，通常是 Device Plugin 没有匹配到 VF 或 CNI 配置错误，需要查看 device plugin 日志和 multus 日志。
另一个高频问题是 IP 分配失败。host-local 默认把分配记录写到 /var/lib/cni/networks，如果该目录跨节点不同步，可能会产生冲突。这种情况下改用 whereabouts 或指定静态 IP 可以解决。还有一类问题表现为 Pod 能启动，但网络不通，需要检查主机物理交换机是否允许 VF 的 MAC 地址通过。SR-IOV VF 默认可能使用随机 MAC，部分交换机开启端口安全后会丢弃未知 MAC，需要在 PF 上设置固定 MAC 或关闭交换机的 MAC 学习限制。
最后提醒一点，启用 SR-IOV 后，物理网卡 PF 依然可以承载宿主机的管理流量，但不要在 PF 上同时运行其他高速业务，否则 VF 和 PF 会争抢同一物理链路的带宽。对于东西向流量较大的场景，可以单独拿出一块物理网卡专门给 SR-IOV 池使用，这样管理网络和业务网络也能更好地隔离。