NAD（NetworkAttachmentDefinition）技术更早诞生；SR‑IOV‑Operator 是后来出现、只是会自动生成 NAD 的上层控制器。
一、两者上线时间对比
- NAD‑Multus Multus‑CNI 在 2019‑03‑15 正式发布，NAD 就是 Multus 自带的标准 CRD，是多网卡网络配置标准，属于 CNI‑Network‑Plumbing 工作组的通用规范，面向全部多网卡场景（macvlan、ipvlan、host‑device、SR‑IOV 等）。
- 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 独立存在
- 老式手动方案（无 Operator） config‑daemon、device‑plugin 手动部署 → 手动创建 NAD → Multus 挂载 VF 网卡
- 现在标准方案 SR‑IOV‑Operator 托管硬件 + 自动生成 NAD
- 一个 NAD 可以被其他网络插件使用，和 SR‑IOV‑Operator 毫无关系
Operator 诞生之前，只能手搓 NAD 吗？
是的，NAD 必须手动编写，但整套 SR‑IOV 环境可以拆成三套独立组件手动部署，不是只有 NAD 需要手动维护
旧时代完整手动架构（没有 sriov‑network‑operator）
整套流程分为三块，全部人工维护，没有统一控制器：
1、节点层面：shell 脚本 /udev/systemd 管理 PF、VF
- 开启内核 IOMMU
- 开机脚本写入
/sys/class/net/xxx/sriov_numvfs创建 VF - 解绑网卡原生驱动、绑定
vfio‑passthrough/ iavf - 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 | 一键部署全套组件 |