1. 第1章
01 课程导论：SR-IOV与Kubernetes高性能网络场景
掌握课程导论在课程导论中的定位、故障信号与验证顺序。
配置证据
课程导论常见问题来自默认值、路径、版本或权限没有对齐。
本节把课程导论相关配置拆成参数来源、生效条件和回滚检查。
生产环境中的网络瓶颈：为什么通用网络方案在Kubernetes中失效
课程导论的验收口径
在Kubernetes（K8s）集群中运行高性能工作负载时，通用Overlay网络（如Flannel、Calico的IPIP模式）往往成为性能瓶颈。典型场景包括：电信核心网的用户面功能（UPF）、金融交易系统的低延迟消息传递、AI训练中的分布式通信（NCCL AllReduce）。这些场景对吞吐量（通常要求10Gbps以上）和延迟（微秒级抖动控制）有严苛要求，而通用网络方案因CPU中断处理、协议栈开销和内存拷贝，会导致性能下降30%-50%
一个真实案例：某5G核心网厂商在Kubernetes上部署UPF时，使用默认的Calico VXLAN模式，数据面吞吐量仅达到线速的60%，且P99延迟抖动超过200μs。根本原因在于：每个数据包都需要经过宿主机的网络协议栈、隧道封装/解封装以及iptables规范匹配，CPU成为瓶颈。这正是SR-IOV（Single Root I/O Virtualization）技术介入的典型场景——它允许容器直接独占物理网卡的硬件虚拟化功能（VF，Virtual Function），绕过宿主机内核协议栈，实现接近物理机的网络性能
在Kubernetes集群中，使用kubectl get nodes -o wide检查节点网卡型号。若支持Intel XL710/XXV710或Mellanox ConnectX-5及以上系列，即可启用SR-IOV。通过lspci | grep -i ethernet确认网卡是否支持SR-IOV（通常需VF数量≥8）
学习路径总览：从SR-IOV原理到Kubernetes生产化部署
本课程以“理解原理-环境搭建-配置集成-排障优化”四阶段为主线，确保学员能独立完成SR-IOV在Kubernetes集群中的落地
SR-IOV并非所有场景的银弹。若工作负载对网络性能不敏感（如Web后端、批处理任务），通用CNI（Container Network Interface）方案更易维护。仅在需要确定性低延迟（<10μs）或线速转发（>40Gbps）时，才应引入SR-IOV
能力交付边界：学完本课你能获得什么
本课程不涉及DPDK应用层开发或网卡固件定制，而是聚焦于Kubernetes生态中SR-IOV的集成与运维。完成学习后，你将具备以下能力：
- 环境搭建能力：在任意支持SR-IOV的硬件上，通过Operator完成设备插件、网络策略的自动化部署，而非手动修改kubelet配置
- 排障定位能力：当Pod无法获取VF或网络不通时，能通过
kubectl logs查看SR-IOV设备插件日志、检查/var/log/kubelet.log中的设备分配错误、使用dmesg确认VF驱动加载状态 - 性能调优能力：理解
exclusiveResourcePool、resourceName等关键参数对CPU亲和性和NUMA（Non-Uniform Memory Access）绑定的影响，避免跨NUMA节点访问导致性能下降
一个典型的交付验证场景：学员将能部署一个使用SR-IOV VF的DPDK-Pod，并通过testpmd工具观察到单核转发性能达到14.88 Mpps（64字节小包），而相同硬件下通用OVS（Open vSwitch）方案仅能达到5.2 Mpps
真实项目场景
某云原生边缘计算平台需要在Kubernetes上运行vBRAS（虚拟宽带远程接入服务器）控制面。团队最初使用Macvlan方案，但发现当并发用户数超过5000时，CPU软中断占用超过80%。引入SR-IOV后，每个vBRAS Pod独占一个VF，通过cpuManagerPolicy: static绑定物理核，软中断占用降至15%以下，成功支撑2万并发用户
不要将SR-IOV VF直接暴露给非特权容器。必须通过securityContext.privileged: true或allowPrivilegeEscalation: true赋予容器操作VF的能力。同时，VF的MAC地址需在SriovNetworkNodePolicy中显式指定，否则可能导致网络冲突