一、一句话定义SR‑IOV‑Network‑Operator 是一套 Kubernetes 网卡硬件管理套件专门自动管理物理网卡 (PF)、拆分出虚拟网卡 (VF)、把 VF 作为硬件资源交给 Pod 挂载使用 整套工具不是单个程序由Deployment 控制面组件 多组 DaemonSet 节点常驻 Pod共同组成你集群看到所有 Pod 都是它的子组件。适配你两套环境Rancher 命名空间cattle‑sriov‑system、OpenShiftopenshift‑sriov‑network‑operator只是封装名字不一样组件结构一致。 注意这些pod部署在哪个空间使用下面的方法进行查询当你的SriovNetworkNodePolicy出现在哪个租户那么这些控制器pod也在这个空间例如kubectl get SriovNetworkNodePolicy -ANAMESPACE NAME AGEcattle-sriov-system sriov-dpdk-left 290d二、组件分类严格区分 Deployment / DaemonSet第一类Deployment控制平面组件仅跑在主控节点1. sriov‑network‑operator主控制器控制器类型Deployment通常单副本运行位置master 控制节点功能监听 4 个自定义资源 CRDSriovNetworkNodePolicy网卡筛选规则nicSelector、VF 数量、驱动配置SriovNetwork对接 Multus‑CNI定义 SR‑IOV 网络SriovNetworkNodeState每个节点网卡、PF/VF 实时状态SriovOperatorConfigOperator 全局开关解析nicSelector厂商 ID、设备 ID、PCI‑BDF、网卡名筛选需要管理的物理网卡 PF下发网卡配置指令给所有工作节点的 config‑daemon持续调谐 reconcile保证节点网卡配置和 Policy 配置一致2. sriov‑nfd‑master节点硬件识别主控控制器类型Deployment作用接收 nfd‑worker 上报本机硬件信息给节点打上标签feature.node.kubernetes.io/network-sriov.capabletrue后续 sriov‑config‑daemon、device‑plugin 依靠标签只调度到带 SR‑IOV 网卡的节点。第二类DaemonSet节点常驻 Pod分为主控 Webhook 组、Worker 网卡硬件组DaemonSet 该节点上永远常驻一个 Pod webhook 类 DS 部署在全部 master 节点网卡代理 DS 部署在worker 工作节点主控节点‑Webhook 组件每台 master 节点各一个 Pod1. 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 都会调用该 webhookmaster 缺实例就会创建 Pod 超时卡住。原因每台 master 节点各一个 Pod原因现状kube‑apiserver所有 master 节点上都会单独运行一份实例3 台 master 就有 3 个 apiserveroperator‑webhook、network‑resources‑injector 使用 DaemonSet同样每台 master 启动一个 Podwebhook 服务通过 Service 统一暴露。根因集群任意 master 的 apiserver 在接收 Pod 创建请求时只会自己发起一次 HTTPS 请求调用准入 Webhook。假如你只用 Deployment 部署 webhook副本随机调度到 master‑01master‑02、master‑03 的 apiserver 需要跨节点网络去访问 webhook一旦节点网络不通、网络抖动、master‑01 宕机剩下两台 apiserver 调用超时新建 Pod 直接卡住报错。DaemonSet 类型此时每一台本地的 apiserver 优先访问本机 webhook几乎不会出现跨节点调用规避网络故障、超时、单点故障Worker 工作节点硬件组件只运行在业务 worker 节点1. sriov‑network‑config‑daemon最核心硬件管家特权容器控制器DaemonSet每一个开启 SR‑IOV 的 worker 节点运行一个完整工作流程扫描节点本机全部 PCI 网卡设备依照主控制器下发的nicSelector规则匹配目标 PF 物理网卡操作系统内核操作开启 IOMMU、解绑原有网卡驱动、创建指定数量 VF、绑定 vfio‑passthrough、配置 RDMA、硬件卸载更新本机状态 CR SriovNetworkNodeState上报 PF/VF 列表、PCI 地址、网卡名、运行状态2. sriov‑device‑plugin硬件资源上报插件控制器DaemonSet作用扫描 config‑daemon 生成好的全部 VF 虚拟网卡将 VF 注册成 kubelet 可调度的硬件资源Kubernetes 调度器就可以像 GPU 一样把 VF 网卡分配给 Pod3. sriov‑sriov‑nfd‑worker节点硬件采集器控制器DaemonSet扫描主机 PCI 设备、网卡、硬件特性上报硬件信息给 nfd‑master用来给节点打硬件标签。4. OpenShift 环境额外组件mellanox‑config‑daemonset专门为迈络思 Connect‑X 系列网卡做专属固件、RDMA 配置sriov‑network‑metrics‑exporter采集 PF/VF 网卡指标用于监控三、整套完整工作链路你编写 SriovNetworkNodePolicy配置 nicSelector 挑选物理 PF 网卡、设置 VF 数量sriov‑network‑operator主 Deployment 控制器读取策略下发配置各 worker 节点 config‑daemon 扫描网卡、匹配 nicSelector、生成 VFdevice‑plugin 将 VF 上报给 kubelet 作为硬件资源injectormaster‑webhook自动为业务 Pod 注入 VF 资源声明Multus‑CNI sriov‑cni 把 VF 网卡挂载进入 Pod四、一张速查表表格组件部署类型运行节点核心职责sriov‑network‑operatorDeploymentmasterCRD 监听、策略下发、nicSelector 解析sriov‑nfd‑masterDeploymentmaster硬件标签管理主控operator‑webhookDaemonSet全部 master校验 SR‑IOV 配置network‑resources‑injectorDaemonSet全部 masterPod VF 资源自动注入sriov‑network‑config‑daemonDaemonSetworker网卡扫描、匹配 PF、创建 VF、内核配置sriov‑device‑pluginDaemonSetworkerVF 硬件资源上报 kubeletnfd‑workerDaemonSetworker本机硬件信息探测