★ FEATURED ARTICLE GPU 故障自动处理这件事很多团队的做法是“告警出来之后运维同学手动查节点、手动重启 Pod、手动加标签”。节点少还能撑节点一多、GPU 型号一杂手动处理不仅慢还容易出现重复操作——两个值班同学同时看到告警同时去处理同一个节点结果任务被重启了两遍甚至把正在跑训练的正常任务也带崩了。这次我们来看一个用 Golang 实现 K8s 自愈处理的实战方案监听 GPU 故障信号自动对故障节点上的工作负载做处理同时通过 Leader 选举、注解标记、幂等键等手段防止重复处理。整体方案不依赖特定云厂商直接跑在标准 K8s 集群里适合已经有 Prometheus 监控体系、又想把手动运维流程自动化掉的团队。文章会拆成三层来讲第一层是 GPU 故障检测怎么做第二层是用 Golang 写自愈控制器要包含哪些核心模块第三层是“防重复”这件事到底怎么落地。最后给出部署 YAML、接口设计、测试方法和常见问题排查。1. 核心能力速览能力项说明项目定位Golang 编写的 K8s GPU 故障自愈控制器监听故障信号并自动处置检测来源NVIDIA DCGM、Prometheus Alertmanager、Node Condition、GPU 设备插件事件自愈动作节点标记、Pod 驱逐/重启、工作负载调度规避、事件通知防重复机制Leader 选举、节点注解时间戳、幂等键去重、Finalizer 保护运行环境标准 K8s 集群需要 GPU 节点、NVIDIA 驱动与 device plugin启动方式Deployment 部署容器内运行支持多副本但仅 Leader 执行动作接口能力HTTP 健康检查、指标接口、回调通知接口可按需扩展批量任务支持批量节点巡检与故障批量处理队列显存/资源占用控制器本体占用很低主要是事件缓存与 API 调用开销需按实际集群规模测试适合场景GPU 集群运维、训练任务容灾、定时巡检替代人工值班这里先明确一点文章里所有代码都是工程模板具体版本号、接口字段、镜像名称需要按你们集群的实际环境替换。GPU 故障的判定不能只看单一指标建议把 DCGM 指标、Xid 错误日志、节点状态三者结合。2. 适用场景与使用边界这个方案适合三类团队GPU 节点数量超过 10 台故障告警频率明显超过人工处理速度的团队。已经有 Prometheus 和 Alertmanager但缺少“告警之后的自动化处置环节”的团队。训练任务有状态、不能随意重启但又希望故障节点能被快速隔离的团队。不适合什么场景如果你们的 GPU 任务全部是无状态短任务重启代价很低那不需要写控制器用 K8s 原生 NodeAffinity 加资源回收策略就够了。如果 GPU 故障判定还停留在“看日志猜”没有 DCGM 或 NVML 数据支撑建议先补监控再上自愈。使用边界必须强调几点控制器自动驱逐 Pod 属于高危操作生产环境一定要先加“人工确认模式”或“只通知不动作”的开关。涉及训练数据、模型权重等业务数据时必须确认存储和备份机制避免驱逐导致数据丢失。GPU 故障信息涉及硬件日志和业务负载信息收集范围要收敛在诊断所需字段不要过度采集。任何自动处理动作都要留审计记录包括触发时间、故障详情、执行动作、处理结果。3. 环境准备与前置条件3.1 集群与硬件前置K8s 集群 1.20 以上建议 1.26 以上方便使用更完善的调度字段。GPU 节点需要安装 NVIDIA 驱动并部署 NVIDIA Device Plugin保证 GPU 可作为可调度资源上报。建议部署 DCGM Exporter采集 GPU 利用率、显存、温度、ECC 错误、Xid 错误等指标。控制面需要能访问 K8s API Server控制器使用 ServiceAccount 认证。3.2 软件版本建议Go 开发环境建议 1.21 以上。依赖库方面K8s 客户端使用的是 client-go控制器框架可选 controller-runtime也可以直接用 informer 自己写。NVIDIA 的 NVML 操作在 Go 里一般通过 go-nvml 库包装但控制器容器内不一定有 NVML 环境所以更稳妥的做法是控制器做“事件决策”DCGM Exporter 做“指标采集”两边通过 Prometheus 或直接读取 Node Condition 联动。3.3 检查清单检查项说明GPU 驱动版本nvidia-smi能正常输出驱动版本与 CUDA 兼容Device Pluginkubectl get node -o json能看到nvidia.com/gpu资源DCGM ExporterPrometheus 能拉到dcgm_gpu_xid_errors、dcgm_temp_gpu等指标Alertmanager能接收告警并能把告警转发到控制器 WebhookRBAC控制器 ServiceAccount 有 Node、Pod、Event 的读写权限备份策略故障驱逐前确认业务数据落盘和备份机制4. 整体架构与防重复设计4.1 核心模块划分控制器可以拆成五个模块故障感知模块监听 Prometheus Webhook 或定期查询 DCGM 指标。决策模块根据故障类型、故障次数、时间窗口决定动作等级。执行模块对节点打标签、驱逐 Pod、重启 Deployment、发送通知。防重复模块幂等键、时间戳、状态记录。API 模块提供健康检查、指标输出、手动触发接口。4.2 防重复设计的三个层次这是整个方案里最容易踩坑的地方拆开讲。第一层是控制器自身的 Leader 选举。K8s 部署多个副本时只有 Leader 执行写操作其他副本保持待命避免两个副本同时处理同一个故障。第二层是节点级防重复。控制器在处理某个节点前先读取节点注解gpu-selfhealing.io/last-process-time。如果当前时间减去上次处理时间小于冷却窗口就跳过。冷却窗口通常是 10 到 30 分钟具体看业务容忍度。第三层是任务级幂等。控制器发出的每一个处理动作都带一个 UUID 作为幂等键写入 ConfigMap 或自定义资源里。如果重启后重新开始处理先查幂等键是否存在存在就直接返回已处理。graph 逻辑关系 故障事件 - 写入待处理队列 - Leader 消费 Leader 检查节点冷却时间 - 检查幂等键 - 执行自愈动作 - 记录处理结果当前架构用队列加锁的方式比每个副本各自同时去操作节点要可控得多。4.3 为什么不用简单的 CronJobCronJob 定时扫描也能做自愈但它们之间没有协调机制。两个 CronJob 实例同时发现同一个故障就会同时执行驱逐这就是最常见的重复处理问题。控制器方案的核心价值不是“能执行动作”而是“保证只有一个执行者、一次动作只生效一次”。5. Golang 核心模块实现5.1 控制器主体与 Leader 选举用 client-go 的 leaderelection 包实现 Leader 选举。多副本 Deployment 部署后只有拿到 Lease 的实例会进入处理循环。// leader 选举核心逻辑 func runLeaderElection(ctx context.Context, client kubernetes.Interface, runFunc func(ctx context.Context)) { lock : resourcelock.LeaseLock{ LeaseMeta: metav1.ObjectMeta{ Name: gpu-selfhealing-leader, Namespace: kube-system, }, Client: client.CoordinationV1(), LockConfig: resourcelock.ResourceLockConfig{ Identity: os.Getenv(POD_NAME), }, } leaderelection.RunOrDie(ctx, leaderelection.LeaderElectionConfig{ Lock: lock, ReleaseOnCancel: true, LeaseDuration: 15 * time.Second, RenewDeadline: 10 * time.Second, RetryPeriod: 2 * time.Second, Callbacks: leaderelection.LeaderCallbacks{ OnStartedLeading: func(ctx context.Context) { klog.Info(本实例成为 Leader开始处理 GPU 故障) runFunc(ctx) }, OnStoppedLeading: func() { klog.Info(Leader 身份丢失进入待命状态) }, }, }) }注意ReleaseOnCancel: true很关键Pod 滚动更新时旧实例会主动释放 Lease新实例可以快速接管。5.2 GPU 故障感知故障感知支持两种方式被动接收 Alertmanager Webhook主动查询 DCGM 指标。生产环境建议两者都启用Webhook 响应快主动巡检兜底。// Alertmanager Webhook 接收故障事件 type AlertPayload struct { Status string json:status Alerts []struct { Labels map[string]string json:labels Annotations map[string]string json:annotations StartsAt time.Time json:startsAt } json:alerts } func handleAlert(w http.ResponseWriter, r *http.Request) { var payload AlertPayload if err : json.NewDecoder(r.Body).Decode(payload); err ! nil { http.Error(w, invalid payload, http.StatusBadRequest) return } for _, alert : range payload.Alerts { nodeName : alert.Labels[node] // 过滤 resolved 状态避免告警恢复时误触发处理 if payload.Status resolved { continue } enqueueNode(nodeName, alert.Labels, alert.Annotations) } w.WriteHeader(http.StatusOK) }这里有一个容易犯的错Alertmanager 在告警恢复时会再发一条resolved消息如果不过滤控制器就会把已恢复的节点再处理一遍。主动巡检部分建议每 60 秒做一次查询 DCGM 的关键指标dcgm_gpu_xid_errorsXid 错误次数。dcgm_gpu_ecc_corrected_total、dcgm_gpu_ecc_uncorrected_totalECC 错误。dcgm_temp_gpuGPU 温度。dcgm_gpu_utilization异常持续为 0 且任务仍在运行时的状态判断。5.3 故障决策与自愈动作决策模块把故障分为三个等级等级判定条件处理动作P0Xid 错误达到阈值、ECC uncorrected 错误标记节点为故障驱逐 GPU 相关 PodP1温度持续超阈值、驱动探针失败先告警通知超过观察窗口再驱逐P2利用率异常、单个指标抖动记录事件不做驱逐func decideAction(alert map[string]string) (ActionLevel, error) { xidCount : parseMetric(alert[xid_errors]) temp : parseMetric(alert[gpu_temp]) switch { case xidCount 5: return ActionLevelP0, nil case temp 85: return ActionLevelP0, nil case temp 80: return ActionLevelP1, nil default: return ActionLevelP2, nil } }阈值不要拍脑袋。Xid 5 次、温度 85 度这些数字要根据你们集群的 GPU 型号和历史故障记录调整。可以先跑一段时间的“只记录不动作”模式攒数据再定阈值。5.4 节点级防重复实现冷却窗口用节点注解记录。每次处理完一个节点就在节点对象上打注解func setNodeProcessed(ctx context.Context, client kubernetes.Interface, nodeName string) error { node, err : client.CoreV1().Nodes().Get(ctx, nodeName, metav1.GetOptions{}) if err ! nil { return err } node.Annotations[gpu-selfhealing.io/last-process-time] time.Now().Format(time.RFC3339) node.Annotations[gpu-selfhealing.io/process-id] uuid.NewString() _, err client.CoreV1().Nodes().Update(ctx, node, metav1.UpdateOptions{}) return err }处理前先检查冷却窗口func checkNodeCooldown(node *corev1.Node, cooldown time.Duration) bool { last, ok : node.Annotations[gpu-selfhealing.io/last-process-time] if !ok { return true // 没有处理记录允许处理 } lastTime, err : time.Parse(time.RFC3339, last) if err ! nil { return true // 注解格式异常保守起见允许处理 } return time.Since(lastTime) cooldown }注意注解读出来如果解析失败不要直接 panic也不要直接拒绝处理。保守策略是允许处理但记录一条日志提示注解格式异常。5.5 幂等键防重复节点级防重复能挡住同一轮的处理但挡不住“控制器重启后事件重新消费”的场景。这时需要任务级幂等。每次处理动作生产一个幂等键写入 ConfigMaptype ProcessRecord struct { ProcessID string json:process_id NodeName string json:node_name Action string json:action TriggeredAt time.Time json:triggered_at Status string json:status } func saveProcessRecord(ctx context.Context, client kubernetes.Interface, record ProcessRecord) error { data, _ : json.Marshal(record) cm : corev1.ConfigMap{ ObjectMeta: metav1.ObjectMeta{ Name: gpu-process-record, Namespace: kube-system, }, Data: map[string]string{ record.ProcessID: string(data), }, } _, err : client.CoreV1().ConfigMaps(kube-system).Create(ctx, cm, metav1.CreateOptions{}) return err }实际生产里更规范的做法是定义一个自定义资源CRD比如GpuFault每个故障对应一个 CR 实例控制器依靠 CR 的 Status 字段去重。CRD 的好处是可以用 Finalizer 保证删除顺序但会增加学习成本。第一次落地用 ConfigMap 或节点注解完全够用。6. 驱逐与调度规避实现6.1 驱逐 GPU Pod找到节点上占用 GPU 的 Pod优先驱逐无状态负载有状态负载需要先检查存储是否 Ready。func evictGPUPods(ctx context.Context, client kubernetes.Interface, nodeName string) error { pods, err : client.CoreV1().Pods(metav1.NamespaceAll).List(ctx, metav1.ListOptions{ FieldSelector: spec.nodeName nodeName, }) if err ! nil { return err } for _, pod : range pods.Items { // 只处理使用 GPU 资源的 Pod if !usesGPU(pod.Spec) { continue } // 优先优雅驱逐失败再强制删除 err : client.CoreV1().Pods(pod.Namespace).Evict(ctx, policyv1.Eviction{ ObjectMeta: metav1.ObjectMeta{ Name: pod.Name, Namespace: pod.Namespace, }, }) if err ! nil { klog.Errorf(驱逐 Pod %s/%s 失败: %v, pod.Namespace, pod.Name, err) } } return nil }Evict接口走的是 K8s 的 eviction API会遵守 PodDisruptionBudget。如果 PDB 设置了minAvailable驱逐会被拒绝这是一层保护建议保留。6.2 节点调度规避给节点打上专用污点让新的 GPU Pod 不再调度上去kubectl label node gpu-node-01 gpu-selfhealing.io/statusfaulty # 或者打污点 kubectl taint nodes gpu-node-01 gpu-selfhealing.io/faulty:NoSchedule在 Golang 里操作func markNodeFaulty(ctx context.Context, client kubernetes.Interface, nodeName string) error { node, err : client.CoreV1().Nodes().Get(ctx, nodeName, metav1.GetOptions{}) if err ! nil { return err } taints : append(node.Spec.Taints, corev1.Taint{ Key: gpu-selfhealing.io/faulty, Value: true, Effect: corev1.TaintEffectNoSchedule, }) node.Spec.Taints taints _, err client.CoreV1().Nodes().Update(ctx, node, metav1.UpdateOptions{}) return err }加污点之前先判断污点是否已存在不然每次处理都会追加一条重复污点。7. 部署到 K8s 集群7.1 RBAC 配置控制器需要 Node、Pod、ConfigMap、Lease 的读写权限apiVersion: v1 kind: ServiceAccount metadata: name: gpu-selfhealing namespace: kube-system --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: gpu-selfhealing rules: - apiGroups: [] resources: [nodes, pods, configmaps, events] verbs: [get, list, watch, create, update, patch, delete] - apiGroups: [coordination.k8s.io] resources: [leases] verbs: [get, create, update] - apiGroups: [policy] resources: [pods/eviction] verbs: [create] - apiGroups: [] resources: [pods/status] verbs: [get, update] --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: gpu-selfhealing roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: gpu-selfhealing subjects: - kind: ServiceAccount name: gpu-selfhealing namespace: kube-system7.2 Deployment 配置apiVersion: apps/v1 kind: Deployment metadata: name: gpu-selfhealing namespace: kube-system spec: replicas: 2 selector: matchLabels: app: gpu-selfhealing template: metadata: labels: app: gpu-selfhealing spec: serviceAccountName: gpu-selfhealing containers: - name: controller image: your-registry/gpu-selfhealing:latest imagePullPolicy: IfNotPresent args: - --cooldown15m - --levelP0 - --notify-onlyfalse env: - name: POD_NAME valueFrom: fieldRef: fieldPath: metadata.name ports: - containerPort: 8080 name: http resources: requests: cpu: 100m memory: 128Mi limits: cpu: 500m memory: 512Mi --- apiVersion: v1 kind: Service metadata: name: gpu-selfhealing namespace: kube-system spec: selector: app: gpu-selfhealing ports: - port: 8080 targetPort: 8080--notify-onlyfalse这个参数很关键。第一次上线建议改成--notify-onlytrue跑几天只发通知不动节点确认告警判断逻辑没问题之后再开启自动处理。7.3 Alertmanager 配置把 GPU 故障告警转发到控制器 Webhookroute: group_by: [alertname, node] group_wait: 10s group_interval: 30s repeat_interval: 20m receiver: gpu-selfhealing-webhook receivers: - name: gpu-selfhealing-webhook webhook_configs: - url: http://gpu-selfhealing.kube-system.svc:8080/api/v1/alert send_resolved: falsesend_resolved: false是必须的避免恢复消息触发控制器的误动作。当然如果你们希望控制器在 GPU 恢复后自动移除污点和标签那就需要接收resolved消息并另写一套恢复逻辑。8. 接口 API 与运维集成8.1 健康检查与手动触发控制器至少提供三个接口接口方法用途/healthzGET健康检查配合 K8s 探针/api/v1/alertPOST接收 Alertmanager Webhook/api/v1/processPOST手动触发节点处理用于测试和补漏手动触发接口示例import requests url http://127.0.0.1:8080/api/v1/process payload { node: gpu-node-03, action: evict, reason: manual-test } response requests.post(url, jsonpayload, timeout30) print(response.status_code) print(response.json())手动触发接口要加鉴权。最简单的方案是控制器环境变量里配一个 Bearer Token请求头携带校验。8.2 指标接口控制器应该暴露 Prometheus 指标方便观察自身运行状态gpu_selfhealing_processed_total处理次数。gpu_selfhealing_processed_skipped防重复拦截次数。gpu_selfhealing_evict_pods_total驱逐 Pod 数。gpu_selfhealing_leader_active当前实例是否 Leader。gpu_selfhealing_queue_depth待处理队列长度。// 指标注册示例实际使用 prometheus client 库 var ( processedTotal prometheus.NewCounterVec( prometheus.CounterOpts{ Name: gpu_selfhealing_processed_total, Help: GPU 故障处理总次数, }, []string{node, action}, ) skippedTotal prometheus.NewCounterVec( prometheus.CounterOpts{ Name: gpu_selfhealing_processed_skipped, Help: 防重复拦截次数, }, []string{node, reason}, ) )9. 资源占用与性能观察控制器本身是控制面组件资源占用大头不在计算而在 API 调用和事件缓存。按几十个节点规模估算内存 256Mi 到 512Mi 就够但需要按实际集群规模压测。几个观察重点Leader 实例和待命实例的 CPU 差异。Leader 负责处理CPU 会略高但通常不会超过 200m。队列积压情况。故障风暴时如果 Alertmanager 一次性推入几十个节点事件处理队列会瞬间拉高。建议队列加限流每秒最多处理 2 个节点。API Server 压力。控制器每次处理都要读 Node、写 Node、查 Pod、踢 Pod频繁操作会产生不少 API 请求。可以复用 K8s 的 Informer 缓存减少重复 List。冷却窗口设置。窗口太短同一节点反复处理窗口太长真正的新故障被挡住。建议初始 15 分钟运行两周后看日志调优。# 查看控制器日志重点关注防重复拦截记录 kubectl logs -f -n kube-system deploy/gpu-selfhealing | grep skipped # 查看处理耗时 kubectl logs -f -n kube-system deploy/gpu-selfhealing | grep processed10. 常见问题与排查方法问题现象可能原因排查方式解决方案控制器启动后不处理任何故障当前实例不是 Leader或 Webhook 地址配置错误查看日志确认 Leader 状态检查 Alertmanager 目标地址确认 Leader 选举正常修正 Webhook URL同一节点被重复驱逐冷却窗口太短或注解写入失败查看节点注解gpu-selfhealing.io/last-process-time延长冷却窗口检查 RBAC 是否有 Node 更新权限告警恢复后触发误处理Alertmanagersend_resolved未关闭查看 Alertmanager 配置和控制器日志设置send_resolved: false或过滤statusresolved驱逐命令执行了但 Pod 没走PDB 阻止驱逐查看驱逐错误信息和 PDB 配置调整 PDBminAvailable或在配置中标记允许跳过 PDB控制器 Pod 频繁重启Leader Lease 冲突或内存超限查看 Pod 事件和 Limit 配置调整资源 Limit检查 Lease 冲突日志手动触发接口 401Token 不匹配检查控制器环境变量与请求头统一 Token 配置接入内部鉴权系统GPU 故障判定不准DCGM 指标没对齐或阈值不合理对比 DCGM 面板数据和控制器日志先跑只通知模式用历史数据校准阈值批量节点同时故障时处理堆积队列限流太严格或处理链路过慢查看队列深度指标调整限流参数优化 API 调用并发11. 最佳实践与使用建议11.1 上线节奏分三步第一步只通知不动作。控制器只负责接收告警、记录日志、发通知所有自动处理开关全部关闭。这一步主要验证事件链路的连通性和告警判断逻辑。第二步只标记不驱逐。控制器可以打标签、加污点但驱逐 Pod 的开关保持关闭。这一步验证调度规避效果同时给业务团队留出观察窗口。第三步开启完整自愈。驱逐、调度规避、通知全开但仍保留人工回滚入口。11.2 配置管理建议把阈值、冷却窗口、动作等级集中到一个 ConfigMapapiVersion: v1 kind: ConfigMap metadata: name: gpu-selfhealing-config namespace: kube-system data: config.yaml: | cooldown: 15m alertLevel: P0 notifyOnly: false thresholds: xidErrors: 5 gpuTempHigh: 85 gpuTempWarn: 80 actions: evict: true taint: true notify: true控制器启动时读取 ConfigMap修改配置需要重启 Pod。想做到热更新的话用 Informer 监听 ConfigMap 变化这里不再展开。11.3 审计与回滚所有自愈动作必须留有记录。建议控制器每次处理完把一个审计事件写入 K8s Eventkubectl get events -n kube-system --field-selector reasonGPUSelfHealing手工回滚路径也要准备好。如果控制器误驱逐了正常任务运维可以通过历史记录确认原因恢复节点标签和污点kubectl label node gpu-node-01 gpu-selfhealing.io/status- kubectl taint nodes gpu-node-01 gpu-selfhealing.io/faulty-11.4 合规与安全边界涉及 GPU 训练数据、用户隐私数据的环境自动驱逐一定要联合业务团队确认数据落盘策略。控制器的 Webhook 接口不要直接暴露到公网建议限制在集群内网访问或加内部网关鉴权。故障日志中包含节点信息、GPU 序列号等硬件信息日志采集和保留周期要按公司安全规范执行。12. 总结与下一步这套 Golang 自愈控制器的核心价值不在代码量而在三个地方一是用 Leader 选举解决多副本竞争问题二是用节点注解冷却窗口挡住短时间重复处理三是用幂等键保证任务级只处理一次。第一次实战可以从 Alertmanager 接一个 Xid 错误告警开始通链路后再加驱逐和污点逻辑。最容易踩的坑按优先级排第一resolved告警触发的误处理过滤逻辑必须优先写第二RBAC 权限不足时控制器写注解失败但日志不明显建议把注解更新失败作为告警指标暴露出来第三阈值没有数据支撑就启动了自动驱逐极容易误伤正常任务先跑只通知模式攒数据。后续可以考虑的扩展方向把处理记录从 ConfigMap 迁到自定义 CRD用 Finalizer 管生命周期给控制器加一个 Web UI 页面便于值班人员查看故障处理和回滚操作把多个集群的控制器集中管理统一策略下发。先把防重复这一层做稳再谈更多自动化。这套思路同样适用于 CPU 故障、内存故障、磁盘故障的自愈处理只是检测指标和动作细节不同。
阅读完成 · 觉得有帮助？
