【k8s】SR‑IOV‑Network‑Operator 详解

一、一句话定义

SR‑IOV‑Network‑Operator 是一套 Kubernetes 网卡硬件管理套件 ，专门自动管理物理网卡 (PF)、拆分出虚拟网卡 (VF)、把 VF 作为硬件资源交给 Pod 挂载使用； 整套工具不是单个程序，由 Deployment 控制面组件 + 多组 DaemonSet 节点常驻 Pod 共同组成，你集群看到所有 Pod 都是它的子组件。

适配你两套环境：Rancher 命名空间 cattle‑sriov‑system、OpenShift openshift‑sriov‑network‑operator，只是封装名字不一样，组件结构一致。 注意：这些pod部署在哪个空间，使用下面的方法进行查询，当你的SriovNetworkNodePolicy 出现在哪个租户，那么这些控制器pod也在这个空间，例如：

kubectl get SriovNetworkNodePolicy -A

NAMESPACE NAME AGE

cattle-sriov-system sriov-dpdk-left 290d

二、组件分类（严格区分 Deployment / DaemonSet）

第一类：Deployment（控制平面组件，仅跑在主控节点）

1. sriov‑network‑operator（主控制器）

• 控制器类型：Deployment，通常单副本
• 运行位置：master 控制节点
• 功能

1. 监听 4 个自定义资源 CRD
   • SriovNetworkNodePolicy：网卡筛选规则（nicSelector）、VF 数量、驱动配置
   • SriovNetwork：对接 Multus‑CNI，定义 SR‑IOV 网络
   • SriovNetworkNodeState：每个节点网卡、PF/VF 实时状态
   • SriovOperatorConfig：Operator 全局开关
2. 解析 nicSelector（厂商 ID、设备 ID、PCI‑BDF、网卡名），筛选需要管理的物理网卡 PF
3. 下发网卡配置指令给所有工作节点的 config‑daemon
4. 持续调谐 reconcile，保证节点网卡配置和 Policy 配置一致

2. sriov‑nfd‑master（节点硬件识别主控）

• 控制器类型：Deployment
• 作用：接收 nfd‑worker 上报本机硬件信息，给节点打上标签 feature.node.kubernetes.io/network-sriov.capable=true 后续 sriov‑config‑daemon、device‑plugin 依靠标签，只调度到带 SR‑IOV 网卡的节点。

第二类：DaemonSet（节点常驻 Pod，分为主控 Webhook 组、Worker 网卡硬件组）

DaemonSet = 该节点上永远常驻一个 Pod； webhook 类 DS 部署在全部 master 节点 ；网卡代理 DS 部署在worker 工作节点

主控节点‑Webhook 组件（每台 master 节点各一个 Pod）

1. operator‑webhook（校验准入钩子）

• 控制器：DaemonSet
• 运行：所有 master 节点
• 作用：校验你编写的 SriovNetworkNodePolicy YAML 拦截非法参数：VF 数量超出网卡上限、错误 PCI 编号、冲突配置、驱动参数错误。

2. network‑resources‑injector（资源自动注入器）

• 控制器：DaemonSet
• 运行：所有 master 节点
• 原理：属于 MutatingWebhook（修改型准入钩子）
• 作用：当新建带有 SR‑IOV 网络注解的 Pod 时，自动帮 Pod 填充 VF 硬件资源申请， 业务 yaml 不需要手动书写 resources: requests/limits。

必须所有 master 部署：每一台 kube‑apiserver 都会调用该 webhook，master 缺实例就会创建 Pod 超时卡住。

原因：每台 master 节点各一个 Pod原因：

现状：

• kube‑apiserver：所有 master 节点上都会单独运行一份实例，3 台 master 就有 3 个 apiserver；
• operator‑webhook、network‑resources‑injector 使用 DaemonSet，同样每台 master 启动一个 Pod；
• webhook 服务通过 Service 统一暴露。

根因：

集群任意 master 的 apiserver 在接收 Pod 创建请求时，只会自己发起一次 HTTPS 请求调用准入 Webhook。

• 假如你只用 Deployment 部署 webhook，副本随机调度到 master‑01；
• master‑02、master‑03 的 apiserver 需要跨节点网络去访问 webhook；
• 一旦节点网络不通、网络抖动、master‑01 宕机，剩下两台 apiserver 调用超时，新建 Pod 直接卡住报错。DaemonSet 类型，此时每一台本地的 apiserver 优先访问本机 webhook，几乎不会出现跨节点调用，规避网络故障、超时、单点故障

Worker 工作节点硬件组件（只运行在业务 worker 节点）

1. sriov‑network‑config‑daemon（最核心硬件管家，特权容器）

• 控制器：DaemonSet
• 每一个开启 SR‑IOV 的 worker 节点运行一个
• 完整工作流程

1. 扫描节点本机全部 PCI 网卡设备
2. 依照主控制器下发的 nicSelector 规则匹配目标 PF 物理网卡
3. 操作系统内核操作：开启 IOMMU、解绑原有网卡驱动、创建指定数量 VF、绑定 vfio‑passthrough、配置 RDMA、硬件卸载
4. 更新本机状态 CR SriovNetworkNodeState，上报 PF/VF 列表、PCI 地址、网卡名、运行状态

2. sriov‑device‑plugin（硬件资源上报插件）

• 控制器：DaemonSet
• 作用

1. 扫描 config‑daemon 生成好的全部 VF 虚拟网卡
2. 将 VF 注册成 kubelet 可调度的硬件资源
3. Kubernetes 调度器就可以像 GPU 一样，把 VF 网卡分配给 Pod

3. sriov‑sriov‑nfd‑worker（节点硬件采集器）

• 控制器：DaemonSet
• 扫描主机 PCI 设备、网卡、硬件特性，上报硬件信息给 nfd‑master，用来给节点打硬件标签。

4. OpenShift 环境额外组件

1. mellanox‑config‑daemonset：专门为迈络思 Connect‑X 系列网卡做专属固件、RDMA 配置
2. sriov‑network‑metrics‑exporter：采集 PF/VF 网卡指标，用于监控

三、整套完整工作链路

1. 你编写 SriovNetworkNodePolicy，配置 nicSelector 挑选物理 PF 网卡、设置 VF 数量
2. sriov‑network‑operator（主 Deployment 控制器）读取策略，下发配置
3. 各 worker 节点 config‑daemon 扫描网卡、匹配 nicSelector、生成 VF
4. device‑plugin 将 VF 上报给 kubelet 作为硬件资源
5. injector（master‑webhook）自动为业务 Pod 注入 VF 资源声明
6. Multus‑CNI + sriov‑cni 把 VF 网卡挂载进入 Pod

四、一张速查表

表格

组件	部署类型	运行节点	核心职责
sriov‑network‑operator	Deployment	master	CRD 监听、策略下发、nicSelector 解析
sriov‑nfd‑master	Deployment	master	硬件标签管理主控
operator‑webhook	DaemonSet	全部 master	校验 SR‑IOV 配置
network‑resources‑injector	DaemonSet	全部 master	Pod VF 资源自动注入
sriov‑network‑config‑daemon	DaemonSet	worker	网卡扫描、匹配 PF、创建 VF、内核配置
sriov‑device‑plugin	DaemonSet	worker	VF 硬件资源上报 kubelet
nfd‑worker	DaemonSet	worker	本机硬件信息探测