将 KubeRay 捐赠给 CNCF
内容提要
KubeRay正式加入CNCF，使PyTorch、AI模型、Ray与Kubernetes组成的PARK开源栈全部归入Linux基金会治理。KubeRay连接Ray分布式AI应用与Kubernetes，提供RayCluster、RayJob、RayService三类CRD，分别管理集群生命周期、批处理任务和在线推理服务，并与OpenTelemetry、Prometheus、Kueue等云原生工具深度集成，Spotify等企业已用于生产。
延伸解读
PARK 栈治理拼图补齐的意义
文章指出，PyTorch 与 Ray 已归属 PyTorch 基金会，Kubernetes 归属 CNCF，KubeRay 此前是 PARK 栈中唯一未纳入 Linux 基金会治理的核心组件。此次捐赠使整个栈统一在 Linux 基金会体系下，作者强调这能让团队对其中立性和开放性更有信心。对采用该技术栈的企业而言，治理归属的统一意味着项目演进不再受单一厂商主导，这是评估长期技术选型时值得关注的信号。
三类 CRD 对应三种生产负载形态
KubeRay 的价值不在于抽象地“运行 Ray”，而在于用三个 CRD 区分负载形态：RayCluster 负责集群全生命周期，包括节点供给、健康检查、GCS 容错与自动扩缩；RayJob 为批处理、分布式训练和强化学习临时创建集群并在完成后销毁，以提升算力利用率；RayService 面向长驻在线推理，支持零停机滚动升级与自动故障转移。读者可据此判断自己的场景应选哪一类资源，而非混用。
集成策略：复用云原生既有工具
文章强调 KubeRay 不重新造基础设施原语，而是接入平台团队已在使用的工具：通过 OpenTelemetry 与 Prometheus 暴露指标，配合 Fluent Bit 收集分布式日志；与 Kueue、Volcano、KAI 等调度器集成，为 RayJob 和 RayCluster 带来 gang scheduling、多租户配额、优先级抢占和拓扑感知调度；并以自动 mTLS 和 Kubernetes 网络策略作为安全隔离基础。这意味着运维体系可延续，但也要求团队熟悉这些周边组件。
当前阶段与后续观察点
需要留意的是，文章明确 KubeRay 此次是以 CNCF 沙箱项目身份加入，作者称这只是开放治理新篇章的开始，而非成熟度终点。生产案例方面，文章提到 Spotify 用其扩展内部机器学习平台 Hendrix，Hark 也将其用于多模态 AI 工作负载。对关注该项目的读者，后续可留意其治理层级演进、路线图讨论以及社区会议中披露的生产实践。
Q&A
KubeRay 加入 CNCF 有什么重要意义？
KubeRay 加入 CNCF 后，PARK 开源栈（PyTorch、AI 模型、Ray 和 Kubernetes）全部归入 Linux 基金会治理，确保了整个栈的中立性和开放性，让团队对其更有信心。
KubeRay 是什么？它主要解决什么问题？
KubeRay 是一个开源工具包和 Kubernetes Operator，用于在云原生基础设施上无缝运行基于 Ray 的分布式 AI、机器学习和 Python 工作负载。它桥接了 Python 优先的 AI 框架与 Kubernetes 原生基础设施之间的差距。
KubeRay 提供了哪些自定义资源定义（CRD）？各自用途是什么？
KubeRay 提供三种 CRD：RayCluster 管理 Ray 集群的完整生命周期，包括自动扩缩容和故障容错；RayJob 用于批处理、分布式训练和强化学习，自动创建临时集群并在完成后销毁；RayService 用于长期高可用的在线推理，支持零停机滚动升级和自动故障转移。
KubeRay 如何与云原生生态集成？
KubeRay 与 OpenTelemetry、Prometheus 和 Fluent Bit 集成实现可观测性；与 Kueue、Volcano 和 KAI 集成实现批调度和配额管理；还支持自动 mTLS 和 Kubernetes 网络策略来保障安全隔离。
有哪些企业已经在生产中使用 KubeRay？
Spotify 使用 KubeRay 扩展其内部机器学习平台 Hendrix，在 GKE 上使用 Ray 训练和微调模型。Hark 也使用 KubeRay 运行多模态 AI 工作负载。
KubeRay 加入 CNCF 后的下一步计划是什么？
KubeRay 成为 CNCF 沙箱项目只是开始，未来将在开放、供应商中立的治理下发展。团队计划在 KubeCon NA 2026 的 BoF 会议上讨论路线图，并鼓励社区通过 Slack 频道和双周会议参与。
