接入 GPU 前，应先确认容器运行时将要加载的 CDI 设备声明，能够与 Kubernetes 实际调度并分配给该 Pod 的设备集合一一对应。只在容器内看到 GPU 设备节点或查询工具输出，并不足以证明访问权限、NUMA/PCIe 拓扑、驱动用户态库和监控链路已经正确配置。
先判断 CDI 是否处在实际调用路径中
CDI 是向容器运行时声明设备及其注入内容的机制，声明通常涉及设备节点、环境变量、挂载项或其他容器编辑项。接入前先确定集群采用的运行时、运行时配置方式，以及设备插件或 Operator 是否会生成并维护 CDI 规范文件。NVIDIA GPU Operator 的部署、组件职责和平台限制应以NVIDIA GPU Operator Documentation与当前集群版本为准；不要将某一节点上的手工配置直接推定为整个集群的标准行为。
把三份设备视图放在一起核对
核对至少应覆盖三个层面：节点上可被驱动识别的物理或逻辑 GPU，Kubernetes 可调度资源及其分配结果，以及 CDI 规范中可被运行时引用的设备名。Pod 的资源请求决定调度器选择何种可分配资源；CDI 名称则必须能被目标运行时解析。若资源请求是一个设备粒度而 CDI 声明指向另一组设备，容器即使启动，也可能出现设备缺失、访问错误或资源归属混乱。
- 记录节点、运行时类型、驱动与相关组件版本，并保留变更前配置。
- 查看目标 Pod 的资源请求、限制、节点选择条件和调度事件，确认实际落点。
- 在该节点核对 CDI 规范文件的路径、所有者、设备名称和引用的设备节点。
- 检查容器运行时日志，确认其没有忽略、找不到或拒绝 CDI 声明。
设备请求必须先于容器内观察
排障顺序不应从容器内“有没有看到卡”开始，而应从 Pod 已获分配什么资源开始。查看 Pod 状态、事件和节点上的设备插件或 Operator 日志，确认请求数量、分配数量与 CDI 设备名的语义一致。对于 MIG、时间切分、虚拟化或共享策略，资源名称可能不再等同于完整物理 GPU；此时必须按实际启用模式复核，不能用设备节点数量代替资源分配结论。
运行时声明要验证解析，而非只验证文件存在
CDI JSON 文件存在、格式可读，不代表容器运行时已经启用 CDI 或会在当前调用链中使用该文件。应确认运行时二进制、配置加载位置、CRI 集成方式及重启生效条件。NVIDIA Container Toolkit 对运行时集成、CDI 工作方式和配置项有明确说明，可结合NVIDIA Container Toolkit Documentation核验支持边界。涉及运行时、Kubernetes 或工具包版本组合时，应以对应发行版本文档和现场测试为准，避免依据旧配置片段直接迁移。
可见性不能替代权限判断
容器内看到设备不代表权限、拓扑和监控链路都已正确配置。设备节点可见仅说明一部分注入结果；进程仍可能因设备节点权限、容器安全上下文、Linux 安全模块策略、cgroup 设备控制、驱动与用户态库不匹配而无法完成初始化。验证应使用与业务接近的最小工作负载，在容器内执行实际初始化和受控计算，同时检查退出码、应用日志及宿主机驱动日志。不要仅以列举设备的命令成功作为验收依据。
拓扑约束需要单独闭环
GPU 与 CPU、内存、网卡之间的拓扑关系不会因 CDI 自动正确。对延迟敏感或多 GPU 工作负载，应核对 Pod 的 CPU 绑定、NUMA 策略、节点亲和性、GPU 位置和网络设备位置。调度器已将 Pod 放到含 GPU 的节点，不等于已满足业务所需的本地性。若工作负载依赖特定 GPU 对等互连、特定网卡邻近性或多进程通信，应在目标节点用实际工作负载验证，并将不满足条件的节点从候选范围排除。
监控链路也要与分配关系对应
监控应能把节点级 GPU 指标与 Pod、容器或工作负载身份合理关联。先确认采集组件能稳定读取驱动暴露的数据，再核对其标签、设备标识与 Kubernetes 分配记录是否一致。只看到节点总利用率，无法证明某个 Pod 正在使用被分配的设备；反过来，应用能运行也不代表告警会定位到正确工作负载。对于共享或切分设备，指标归属粒度尤其需要按当前组件能力和版本复核。
以小范围发布建立回退路径
先选择单一节点和最小 Pod 模板验证，再逐步扩大。验收指标至少包括：Pod 调度成功且无设备相关警告；运行时无 CDI 解析失败；容器内业务初始化成功；实际设备标识与分配记录相符；基础监控可见且归属可追踪。发布前保留原运行时配置、CDI 规范文件生成方式、节点标签和工作负载清单。若出现设备不可用、错误映射或监控失真，应停止扩大范围，恢复已验证的运行时与设备插件配置，删除或隔离异常节点上的新声明，并重新从调度结果开始核对。
WeChat
Profile