NAD（NetworkAttachmentDefinition）技术更早诞生；SR‑IOV‑Operator 是后来出现、只是会自动生成 NAD 的上层控制器。

一、两者上线时间对比

1. NAD‑Multus Multus‑CNI 在 2019‑03‑15 正式发布，NAD 就是 Multus 自带的标准 CRD，是多网卡网络配置标准，属于 CNI‑Network‑Plumbing 工作组的通用规范，面向全部多网卡场景（macvlan、ipvlan、host‑device、SR‑IOV 等）。
2. sriov‑network‑operator 项目仓库首次初始化提交为 2019‑05‑18，比 Multus/NAD 晚 2 个月，是后续开发出来的专用运维组件GitHub。

时间线：Multus (NAD) → 两个月之后 SR‑IOV‑Operator

二、本质定位，彻底打破误区

1.NAD：通用 K8s 多网卡配置标准 它属于 Multus‑CNI 的配置资源，是整个 K8s 生态通用的网络载体。 不止 SR‑IOV 可以使用 NAD；macvlan、ipvlan、host‑device、ovs‑bridge 全部依靠 NAD 定义二级网络。 你可以完全脱离 SR‑IOV‑Operator，手动编写 NAD 配置 SR‑IOV 网卡，早年集群就是手动维护 NAD。

         通俗来说：它只是一份 Multus‑CNI 的网络配置模板，用来描述 VF、VLAN、MTU、IPAM，定义 Pod 该怎么挂载这块 VF 网卡；它只管网络挂载规则，不会操作硬件 PF/VF。例如nad定义了vlanid为1810，将来CNI 插件在 Pod 挂载网卡阶段动态下发 VLAN时，就会设置为1810！

 2.SR‑IOV‑Operator：网卡硬件自动化管理工具 它只管一件事：自动管控节点 PF、拆分 VF、管理硬件驱动。

• 为了降低用户配置成本，它内置控制器逻辑：读取你编写的 SriovNetwork，自动翻译成 Multus 能够识别的 NAD；
• NAD 只是它输出的一份配置文件，NAD 本身独立于 Operator 存在。

三、三种现实部署方式，佐证 NAD 独立存在

1. 老式手动方案（无 Operator） config‑daemon、device‑plugin 手动部署 → 手动创建 NAD → Multus 挂载 VF 网卡
2. 现在标准方案 SR‑IOV‑Operator 托管硬件 + 自动生成 NAD
3. 一个 NAD 可以被其他网络插件使用，和 SR‑IOV‑Operator 毫无关系

Operator 诞生之前，只能手搓 NAD 吗？

是的，NAD 必须手动编写，但整套 SR‑IOV 环境可以拆成三套独立组件手动部署，不是只有 NAD 需要手动维护

旧时代完整手动架构（没有 sriov‑network‑operator）

整套流程分为三块，全部人工维护，没有统一控制器：

1、节点层面：shell 脚本 /udev/systemd 管理 PF、VF

1. 开启内核 IOMMU
2. 开机脚本写入 /sys/class/net/xxx/sriov_numvfs 创建 VF
3. 解绑网卡原生驱动、绑定 vfio‑passthrough / iavf
4. udev 规则保证服务器重启之后 VF 配置不会丢失

每台服务器网卡名称、PCI‑ID 不一样，需要给不同节点单独写脚本，维护非常麻烦。

2、独立部署 sriov‑device‑plugin（DaemonSet）

单独部署设备插件，扫描本机 VF，向上汇报成 k8s 硬件资源； 该插件很早就独立开源，早于 sriov-Operator。

3、手动 yaml 创建 NAD

你自己写 NAD 完整 JSON 配置，声明资源名称、VLAN、MTU、ipam、trust 开关，交给 Multus‑CNI 使用。

4、手动部署 sriov‑cni 二进制

把 cni 二进制放置到 /opt/cni/bin，供 Multus 调用挂载 VF。

通俗拆解：Operator 本质就是把下面一堆手动工作整合自动化

表格

以前手动操作	现在 Operator 自动完成
节点编写 shell 脚本创建 VF	config‑daemon 依靠 nicSelector 自动匹配 PF、生成 VF
每节点维护 udev、开机服务	CRD 统一配置，集群下发策略
手动手写 NAD yaml	读取 SriovNetwork，自动生成 NAD
单独部署 device‑plugin、cni、webhook	一键部署全套组件