KubeRay
3 节点1 篇4 来源
KubeRay作为连接Ray与Kubernetes的关键组件，其默认配置在单团队小规模测试中表现良好，但在扩展至多团队共享GPU池的生产环境时，往往在调试数据留存、硬件故障识别、自动扩缩容争用、头节点高可用及服务网格兼容性这五个边界处失效。
【背景】KubeRay是开源Kubernetes Operator，提供RayCluster、RayJob和RayService三种自定义资源，旨在将Ray工作负载原生化管理。然而，随着集群规模扩大（如超过少量节点或引入第二个团队），简单的kubectl logs不再足以诊断问题，因为临时集群可能在错误发生前销毁，且硬件故障常被伪装为应用错误。
针对这些挑战，Anyscale现场工程师Naila Khan指出，生产级部署需调整默认值：启用History Server以持久化日志，配置GCS容错以应对头节点中断，并为服务网格预留端口空间。同时，官方文档已新增针对DeepSeek等多节点GPU部署的故障排查指南，强调通过隔离测试定位NCCL初始化失败等特定硬件问题。此外，Bitnami Helm Chart因缺失Cluster Role规则导致RayService卡在WaitForServeDeploymentReady的案例，也揭示了RBAC配置在复杂环境下的关键性。
事情怎么走到这一步
Anyscale发布博客《KubeRay in production: best practices from the field》，由现场工程师Naila Khan撰写，详细描述了KubeRay在多团队GPU集群中的五个典型失效场景及六项最佳实践。
anyscale.com ↗Ray项目合并PR #54229，新增《Troubleshooting DeepSeek/multi-node GPU deployment on KubeRay》文档，提供针对LLM多节点GPU服务的系统性调试策略，包括区分单节点与KubeRay行为、变体硬件配置测试等。
github.com ↗GitHub Issue #30648报告Bitnami KubeRay Helm Chart (v1.2.19)因缺失Endpoints资源的RBAC规则，导致RayService状态卡在`WaitForServeDeploymentReady`，凸显了权限配置对服务启动的影响。
github.com ↗
还没定论的部分
- KubeRay History Server从alpha到beta的演进是否已完全解决临时集群日志丢失问题，特别是在驱动极早崩溃的场景下？
- 针对H100等新型GPU实例的NCCL拓扑检测失败，是否有标准化的AWS OFI插件修复方案被纳入KubeRay默认镜像？