Anyscale现场工程师Naila Khan：KubeRay默认配置在多团队GPU集群的五个边界处失效

当RayJob从单个成功运行扩展到数百个作业、跨多个团队和集群时，那些在小规模下工作良好的默认配置开始在生产并行和争用下失效。这是KubeRay系列第二篇的核心观察。她强调这些不是KubeRay本身的缺陷，而是Ray、Kubernetes与运行两者的组织之间的边界问题。

她以现场工程师身份描述了两类团队——将Ray适配进为其他用途构建的集群的企业，以及将Ray推向极限的数字原生公司——并指出它们反复遇到相同的五个场景。第一个场景是调试数据与集群生命周期绑定：一个设置了shutdownAfterJobFinishes: true的RayJob在清理自身时也会删除其Ray dashboard。最难排查的情况是驱动进程在最初几分钟内退出——GPU工作节点启动、接收不到任务、集群在任何人捕获驱动日志之前就被拆除。

第二个场景是硬件故障伪装为应用错误。PCIe或NVLink故障、或挂起的NFS挂载可以中断训练运行，而Pod仍报告Ready状态。Ray继续向该节点调度工作，因此故障表现为应用错误。一些团队构建了修改后的operator和自定义资源来检测故障硬件。

第三个场景是默认设置在生产规模下需要调优。Khan举了具体例子：20个集群争用一个GPU池时，空闲GPU工作节点可能在placement group仍在形成时就被回收，训练无法开始；maxReplicas没有余量会在Ray Train重试OOM任务时卡住自动扩缩容器；每次重试还可能留下一个placement group。她称现场团队反馈，可靠性稳定之前需要数周平台工程工作。

第四个场景是头节点中断影响整个集群。Khan引用Klaviyo工程团队运行Ray Serve on KubeRay一年的经验：节点镜像更新和安全补丁的节点排空可以拉下Ray节点，内存压力可以驱逐头Pod。没有GCS容错时整个集群失败；启用后，工作节点仅在头节点于约十分钟内恢复时继续运行——这是KubeRay的默认工作节点重连超时。

第五个场景是Ray与现有平台服务的共存。服务网格、共享命名空间、配额和审计要求先于Ray存在。Khan描述了一个企业团队在Ray Serve上服务数千个模型时发现Envoy sidecar为每个Ray端口创建了一个listener，压垮了网格控制平面并影响了相邻服务。

针对这五个场景，Khan给出六项实践，强调每项都不需要新工具，而是使用Kubernetes生态已有的能力。核心建议包括：启用History Server（KubeRay v1.6引入alpha、v1.7提升为beta）将事件和日志写入对象存储；运行NVIDIA DCGM exporter并对GPU Xid错误告警而非仅监控利用率；使用gang scheduler确保作业的工作节点一起启动或都不启动；为maxReplicas留出至少两个额外工作节点的余量以容纳OOM重试后的替换；在头节点设置num-cpus: "0"；将服务网格保持在边缘并排除Ray内部端口。

文章末尾，Khan提出了一个判断框架：如果你需要维护专门的管道来在RayJob终止前捕获日志、花数小时排查故障是GPU还是Kubernetes还是Ray、手动调优自动扩缩容默认值、运行冗余集群或自定义健康检查器、手动映射工作负载到团队用于审计或分摊、或跨多集群多云多区域操作Ray——如果其中两项以上描述了你的一周，一个平台层可能值得考虑。她随后介绍了Anyscale的KubeRay Connect私有预览版作为这一层的具体实现。

需要指出的是，这篇文章由Anyscale发布，其商业产品KubeRay Connect正是文章推荐的解决方案。六个实践本身基于可验证的Kubernetes和Ray生态工具，但'何时值得引入平台层'的判断标准与Anyscale的商业利益一致。读者可以将实践部分作为独立的技术参考，而将产品推荐视为厂商主张。

Khan还提到一个值得注意的细节：看到已完成RayJob的日志和dashboard是KubeRay社区最早的诉求之一，用户早在2023年就在提出。之所以困难，是因为临时集群正是RayJob的设计初衷，因此证据必须在集群消失之前离开集群。History Server是社区的回应，由多个大型平台团队的贡献者构建。