在 Kubernetes 中给 Pod 添加一个 RDMA 资源请求，并不自动完成高速数据路径。设备插件负责向调度器报告可分配资源，CNI 或网络附件负责把网络接口接入 Pod，宿主机驱动和固件提供底层能力，安全上下文决定进程能否访问相应字符设备与内存锁定。任一层的设备身份不一致，都可能出现“资源已分配但应用找不到接口”“接口存在但通信走普通内核网络”或“测试工具可用而业务容器失败”。
先把四张清单对齐
节点资产清单要记录网卡 PF/VF、PCI 地址、端口、NUMA 和固件；Kubernetes 节点资源记录设备插件发布的资源名和数量；网络附件定义接口如何进入 Pod；工作负载清单则声明资源、网络和安全要求。平台应能从一个 Pod 反查到实际 PCI 功能、宿主接口和交换网络。只用自定义资源名表达“高速网卡”而不维护后端映射，会让节点更换或 VF 重建后产生静默漂移。
资源分配与网络连接不是同一动作
调度器依据扩展资源选择节点，但资源计数不包含 VLAN、IP、路由、MTU 或 QoS。多网络环境还要明确默认网络与 RDMA 网络各自承担什么流量，避免模型下载、管理或探针误走高性能网络。若使用 SR-IOV，VF 数量、信任、速率、MAC/VLAN 策略和 IOMMU 都要纳入节点基线。资源耗尽时应清晰拒绝调度，不能回退到另一条不满足性能或隔离要求的路径而不告警。
权限应最小化而不是直接特权运行
为了快速打通 RDMA，把 Pod 设为 privileged 会扩大宿主机风险，也难以证明生产所需的最小权限。应逐项识别设备节点、capability、内存锁定、IPC 和网络命名空间需求，并验证不必要权限已移除。租户环境还要限制谁可以请求稀缺 RDMA 资源、谁能创建网络附件，以及一个工作负载是否能观察其他 VF 或宿主接口。故障排查容器与业务容器应使用不同策略。
拓扑感知不能停留在节点级
Pod 被调度到有 RDMA 资源的节点，不代表网卡与 GPU 位于合适的 NUMA 或 PCIe 路径。设备插件、拓扑管理器、CPU 管理和 GPU 资源分配需要共享同一放置意图。验收应保存容器内设备可见性、宿主 PCI 拓扑、CPU 亲和与通信库选择结果。多轨网络还要明确每个进程绑定哪张卡，避免所有流量集中在第一个可见接口。
升级与重启是最容易暴露问题的阶段
驱动容器、设备插件、CNI、Network Operator 或节点内核升级都可能触发资源暂时消失。更新顺序应先排空工作负载，确认资源回收，再变更底层组件，最后验证资源重新注册和网络附件可用。若设备插件重启后数量变化，调度器可能仍保留旧认知一段时间。自动化必须检测这些差异，不能仅以 DaemonSet Ready 作为完成标准。
端到端验收清单
- 从 Pod 资源声明追溯到 PF/VF、PCI、NUMA、宿主接口和交换网络。
- 验证资源不足、网络附件失败和设备被重置时，工作负载明确失败而非静默降级。
- 用最小安全上下文运行真实应用，确认无需长期 privileged 权限。
- 测试同节点、多节点、多租户和多轨场景下的隔离、绑定与性能分布。
- 演练节点排空、组件升级和重启，确认资源数量、设备身份与策略自动恢复。
NVIDIA Network Operator、驱动与 Kubernetes 网络组件的安装和版本支持应从 NVIDIA Networking Documentation进入相应版本手册核对。不同集群发行版、内核与容器运行时的组合可能改变部署方式，不能从一次测试推断所有节点默认兼容。生产记录应保留完整组件版本与验收结果。
WeChat
Profile