NVIDIA GPU Operator中NFD重启导致驱动Pod重建问题分析

问题背景

在使用NVIDIA GPU Operator部署Kubernetes集群中的GPU资源时，用户报告了一个关键问题：当Node Feature Discovery（NFD）组件重启时，会导致NVIDIA驱动DaemonSet被意外重建。这一现象在将NFD从GPU Operator命名空间分离部署时尤为明显。

问题现象

具体表现为：

1. 当NFD worker pod在GPU节点上重启时
2. NVIDIA驱动DaemonSet会被终止并重新创建
3. 节点标签nvidia.com/gpu-driver-upgrade-state保持在"upgrade done"状态
4. 驱动Pod陷入init崩溃循环，等待节点上的Pod被驱逐

根本原因分析

经过深入调查，发现该问题与NFD的标签管理机制有关。在NFD v0.15.4版本中存在一个已知问题：当NFD worker pod被删除并重新创建时，它会先删除所有由其管理的节点标签，然后再重新添加。这种标签的临时消失会触发GPU Operator的响应机制，导致驱动DaemonSet被重建。

影响范围

该问题主要影响以下环境配置：

• 使用GPU Operator v24.3.0版本
• 驱动版本535.183.01
• NFD版本0.15.4
• 将NFD与GPU Operator分离部署的场景

解决方案

针对此问题，社区提供了多种解决方案：

1. 降级NFD版本：使用不受此bug影响的NFD版本（如v0.14.6或更早版本）

2. 禁用NFD垃圾回收器：通过修改NFD的helm values配置，禁用标签的垃圾回收功能

3. 升级到修复版本：NFD v0.16.2及更高版本已经修复了此问题，GPU Operator v24.6.0已集成NFD v0.16.3

临时应对措施

在无法立即升级的情况下，可以采取以下手动干预措施：

1. 将节点标签手动设置为nvidia.com/gpu-driver-upgrade-state=upgrade-required
2. 这将触发GPU Operator的升级控制器驱逐节点上的所有GPU Pod
3. 允许驱动Pod恢复正常运行状态

技术建议

对于生产环境，建议：

1. 保持GPU Operator和NFD版本的兼容性
2. 在分离部署NFD和GPU Operator时，特别注意版本匹配
3. 定期关注组件更新，及时应用修复版本
4. 对于关键业务环境，考虑实施升级前的充分测试

通过理解这一问题的本质和解决方案，用户可以更好地规划和管理GPU加速的Kubernetes集群，确保GPU资源的稳定性和可靠性。