NVIDIA GPU Operator中预编译驱动与节点状态的循环冲突问题分析

问题背景

在Kubernetes集群中使用NVIDIA GPU Operator时，当配置了预编译驱动（precompiled driver）且GPU节点处于NotReady状态时，系统会出现nvidia-driver-daemonset被循环删除和重建的现象。这种情况会导致不必要的资源消耗和潜在的系统不稳定。

问题现象

具体表现为：

1. 当GPU节点因kubelet服务停止等原因变为NotReady状态时
2. 节点会被自动添加不可调度污点（unreachable:NoSchedule）
3. nvidia-driver-daemonset由于缺少对应的容忍度配置，其期望副本数变为0
4. GPU Operator的清理逻辑检测到这一情况后，会删除该DaemonSet
5. 但由于集群中仍存在GPU节点，Operator又会重新创建DaemonSet
6. 这一过程不断循环，直到节点恢复Ready状态

技术原理分析

问题的核心在于两个方面：

1. 污点与容忍度不匹配：当节点不可达时，Kubernetes会自动添加两种污点：

   • node.kubernetes.io/unreachable:NoExecute
   • node.kubernetes.io/unreachable:NoSchedule

   而nvidia-driver-daemonset默认只容忍了NoExecute效果的unreachable污点，没有容忍NoSchedule效果的相同污点。

2. Operator的清理逻辑：GPU Operator中有一个名为cleanupStalePrecompiledDaemonsets的函数，它会检查DaemonSet的期望副本数。当发现期望副本数为0时，会认为这是陈旧的DaemonSet并将其删除。但由于集群中确实存在GPU节点，Operator又会立即创建新的DaemonSet，导致循环。

解决方案

目前有两种解决方式：

1. 临时解决方案：在安装GPU Operator时，通过values.yaml添加额外的容忍度配置：

daemonsets:
  tolerations:
  - key: node.kubernetes.io/unreachable
    operator: Exists
    effect: NoSchedule

2. 官方修复方案：该问题已在master分支中修复，修复逻辑优化了DaemonSet的清理判断条件，避免了这种循环情况。修复将包含在下一个正式版本中。

最佳实践建议

对于生产环境，建议：

1. 如果使用预编译驱动，应升级到包含修复的版本
2. 对于关键业务节点，应配置适当的节点健康检查机制，避免节点频繁进入NotReady状态
3. 在节点维护期间，可以考虑手动暂停GPU Operator的某些功能

总结

这个问题展示了Kubernetes中污点/容忍度机制与Operator控制逻辑之间微妙的交互关系。通过深入分析，我们不仅找到了临时解决方案，也理解了NVIDIA官方的修复思路。这类问题的解决往往需要对Kubernetes调度机制和特定Operator的实现都有深入理解。