Kubernetes中自愈GPU节点：构建EKS节点监控代理的经验教训
内容提要
AWS在EKS Auto Mode中开源了节点监控代理，自动检测并修复节点故障，如GPU掉线、内核崩溃等。系统通过NodeConditions触发Karpenter自动替换节点，无需人工干预。设计上区分致命与信息事件，避免误判，并优化了CPU抖动以减少对GPU训练的干扰。诊断通过kubectl ekslogs获取日志，无需SSH。整个流程从故障检测到替换约12分钟，显著降低运维负担。
延伸解读
严重级别变更的连锁反应
文章指出，将NvidiaDeviceCountMismatch从Warning改为Fatal看似合理，却导致下游自动化、仪表盘和修复策略失效。这提醒我们，节点健康代理输出的reason code和严重级别是公共API，任何变更都应视为破坏性变更，需谨慎评估影响并做好兼容。
监控禁用的安全语义
当监控器被禁用时，选择不输出任何NodeCondition，而非输出True或Unknown，是避免误判的关键。因为输出True会让自动修复误以为节点健康，输出Unknown可能触发不必要的节点替换。这一设计决策强调了“缺席不等于健康”的原则，对构建类似系统有重要参考价值。
CPU抖动对GPU训练的隐性影响
代理自身的CPU使用模式可能干扰分布式训练。即使总CPU占用很低，若集中在突发脉冲，也会导致NCCL集体通信的微秒级抖动，进而影响整个集群性能。因此，健康代理的资源消耗模式与总量同等重要，添加启动抖动和合并轮询是有效的缓解措施。
检测与诊断分离的设计智慧
将节点故障检测与诊断日志收集分离，避免拖慢检测速度。检测需快速响应，而诊断可稍慢并收集详细日志。通过NodeDiagnostic CRD和kubectl ekslogs，无需SSH即可获取日志，尤其适用于无shell访问的托管节点，兼顾了效率与可观测性。
Q&A
EKS Node Monitoring Agent 是什么？它主要解决什么问题？
EKS Node Monitoring Agent 是 AWS 开源的一个节点监控代理，用于自动检测 Kubernetes 节点故障（如 GPU 掉线、内核崩溃等），并通过写入 NodeConditions 触发 Karpenter 自动替换故障节点，从而减少人工运维干预。
EKS Node Monitoring Agent 如何实现自动节点修复？
代理检测到节点故障后，会写入对应的 NodeCondition，Karpenter 根据预定义的修复策略（条件类型和状态）自动替换节点。整个过程无需人工介入，从故障注入到新节点运行工作负载约需 12 分钟。
EKS Node Monitoring Agent 如何区分致命故障和信息事件？
代理将检测到的问题分为两类：致命故障（如 GPU 设备计数不匹配、关键 XID 错误、NVLink 故障等）会触发节点替换；信息事件（如带宽限制、连接跟踪限制、GPU 热警告等）仅发布 Kubernetes 事件，不影响节点状态。分类原则是：确定性且基础设施拥有的故障触发替换，可能由应用引起或暂时性的信号保持信息性。
为什么 EKS Node Monitoring Agent 的 CPU 抖动会影响 GPU 训练？如何解决的？
代理的监控器在独立 goroutine 上运行，当轮询间隔对齐时，多个 goroutine 会同时唤醒，导致 CPU 突发使用，在分布式 GPU 训练中造成微秒级抖动，影响 NCCL 集合通信，导致吞吐量下降。解决方法是：为每个监控器的轮询间隔添加启动抖动（随机偏移最多 20%），缓存 /proc 系统调用，并将共享间隔的处理程序合并到顺序工作队列中，使 CPU 使用变得平稳可预测。
如何在不使用 SSH 的情况下获取 EKS 节点的诊断日志？
可以使用 kubectl ekslogs <node-name> 命令。该命令创建 NodeDiagnostic 资源，节点上的代理检测到后收集系统状态并打包，通过 kubelet 的 Node Log Query API 下载。整个过程无需 SSH，适用于 EKS Auto Mode 中无 shell 访问的节点。
EKS Auto Mode 中自动节点修复是默认开启的吗？
是的，EKS Auto Mode 默认启用自动节点修复，无需安装附加组件或配置修复策略。代理作为 systemd 服务运行在节点镜像中，Karpenter 自动消费其条件，实现开箱即用的自动修复。
EKS Node Monitoring Agent 监控哪些额外的节点条件？
除了 kubelet 报告的 DiskPressure、MemoryPressure 和 PIDPressure 外，代理还监控五个额外领域：内核健康、容器运行时、网络、存储和加速硬件。例如，GPU 设备计数不匹配、NVLink 故障、VPC CNI 进程状态等。
EKS Node Monitoring Agent 的检测延迟受什么限制？
检测延迟受信号源限制，而非代理本身。例如，内核恐慌的检测时间受 journald 刷新频率影响；GPU 关键故障通过 DCGM 的推送通道实现亚秒级检测，而 NVSwitch 健康等则受 5 分钟窗口限制。
