北京
当你在数万个Kubernetes集群的规模上运营时，原本以为“罕见”的硬件故障，实际上每天都在舰队的不同角落多次发生。GPU从PCIe总线掉线、容器运行时卡死、网络接口凭空消失——这些在单集群里一年也碰不到一次的故障，到了万级集群就变成了日常节奏。
过去的应对方式完全依赖人工：运维人员被告警叫醒，盯着仪表盘，SSH登录节点，执行cordon、drain，终止实例，再等新节点拉起来。每一个环节都是人肉操作，每一次处理都是重复劳动。如果故障发生在凌晨三点，工作负载就要在降级状态下硬撑好几个小时才有机会恢复。
我们构建了EKS节点监控代理来填补这个缺口，并已在今年四月份开源。它负责检测节点故障，并把问题转换成Kubernetes的NodeCondition写入集群。Karpenter读取这些条件后，就能自动触发节点替换。这个代理只是更大系统中的一个环节——想要理解它到底卡在哪一环，得先看清是谁在管理那些被监控的节点。
事情在EKS Auto Mode上线后彻底变了。这个自动模式接管了Kubernetes集群基础设施的全部运维：计算资源供应、弹性伸缩、网络、存储、操作系统补丁乃至安全加固，团队终于能把精力放回应用本身。它会动态选择最优的EC2实例——包含P5、P6、G6这些GPU机型——按负载需求伸缩，合并利用率不足的节点，并且以自动节点修复作为默认行为。检测、严重级别判定、由Karpenter驱动的节点替换全部开箱即用，不需要额外安装插件，不需要写控制器配置，也不需要自己定义修复策略。
在数千个集群上跑了这么长时间后，经验被压缩成了六条教训。第一条听起来像是给后端开发的老规矩：原因代码是一份API契约。每一个下游消费者——无论是修复控制器、监控面板还是客户自己的自动化脚本——全部用字符串精确匹配来对接这些代码。新增代码属于功能迭代；重命名代码等于破坏性变更；改动严重级别同样是破坏性变更。这些教训并不是我们独有的，无论是在NPD、NVSentinel、AKS Periscope、GKE的自动修复，还是任何人自己写的节点控制器里，都能看到一模一样的模式。它们本应该是一份所有人都能照着打的清单，而我们的开源项目把这六条都落到了代码里——从API层面原因代码的稳定承诺，到解决GPU工作负载干扰的抖动实现，条条有对应。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
