The PARK stack (PyTorch, AI models, Ray, and Kubernetes) is emerging as the de facto open source standard for production AI. Within that stack, KubeRay has become the bridge connecting scalable AI applications built on Ray with the compute orchestration of Kubernetes.
Nearly every core piece of the PARK stack already lives under the Linux Foundation: PyTorch and Ray through the PyTorch Foundation, and Kubernetes through the Cloud Native Computing Foundation (CNCF). KubeRay was the missing piece.
Today, we’re announcing that KubeRay is joining the CNCF, bringing the entire PARK stack under Linux Foundation governance and giving teams full confidence in its neutrality and openness.
Scaling Ray clusters on Kubernetes
KubeRay is a powerful, open source toolkit and Kubernetes operator designed to run distributed AI, machine learning, and Python workloads powered by Ray seamlessly on cloud-native infrastructure. As distributed AI workloads become a core cloud native construct, KubeRay bridges the gap between Python-first AI frameworks and Kubernetes-native infrastructure.
KubeRay provides three Kubernetes Custom Resource Definitions (CRDs) for scaling and operating Ray workloads in production:
- RayCluster: The foundational building block for running Ray on Kubernetes. `RayCluster` manages the full lifecycle of a Ray cluster, automating head and worker pod provisioning, health checks, Global Control Service (GCS) fault tolerance, and dynamic autoscaling in coordination with the Ray Autoscaler.
- RayJob: Purpose-built for batch processing, distributed training, and reinforcement learning (RL) workloads. `RayJob` automatically provisions an ephemeral `RayCluster`, submits a Ray job once the cluster is ready, and tears down the cluster upon completion to maximize compute and accelerator utilization.
- RayService: Designed for long-lived, high-availability online inference with Ray Serve. `RayService` manages both the underlying `RayCluster` and the Ray Serve deployment graph, enabling zero-downtime rolling upgrades, automated failover, and seamless traffic routing for production AI services.
Together, these custom resources provide the foundation for enterprises to build modern machine learning platforms on top of Ray and Kubernetes. For example, end users like Spotify use KubeRay to scale their internal machine learning platform, Hendrix, which is used to train and fine-tune Spotify’s machine learning models using Ray on GKE.
> *”<Insert quote from Spotify>”*
> — **[Name, Title, Spotify]**
Growing the KubeRay ecosystem
Beyond core cluster lifecycle management, KubeRay has seen widespread adoption because of how deeply it integrates with other CNCF projects and the broader cloud-native ecosystem. Rather than reinventing infrastructure primitives, KubeRay plugs directly into the tools platform teams already rely on:
- Observability with OpenTelemetry, Prometheus and Fluent Bit: Ray uses OpenTelemetry within its metrics pipeline and exposes metrics in Prometheus format, enabling platform teams running KubeRay to monitor cluster utilization, task execution, and Ray Serve latency alongside their existing Kubernetes infrastructure. Paired with Fluent Bit for lightweight log collection and forwarding, operators can easily aggregate distributed worker and job logs across ephemeral and long-lived Ray clusters.
- Batch Scheduling and Quota Management with Kueue, Volcano, and KAI: As organizations scale distributed training across scarce GPU and TPU resources, KubeRay integrates natively with different schedulers to bring Kubernetes-native job queueing to `RayJob` and `RayCluster`. This enables gang scheduling (all-or-nothing pod placement), multi-tenant resource quotas, priority preemption, and topology-aware scheduling.
- Workload Security and Isolation: As AI workloads scale, robust security and multi-tenancy are critical. KubeRay provides the foundation to secure Ray clusters using automated mTLS and Kubernetes network policies.
What’s Next?
KubeRay’s success so far has been due to its fast-growing community members — we want to give thanks to everyone who has contributed to KubeRay so far.
Becoming a CNCF sandbox project is just the beginning of KubeRay’s next chapter under open, vendor-neutral governance, and we’d love for you to be part of it.
If you’re at KubeCon NA 2026, come meet the KubeRay maintainers at our Birds of a Feather (BoF) session to discuss the roadmap, share production use cases, and help shape the future of Ray on Kubernetes. Hark will also be giving a talk about how they use KubeRay for multimodal AI use cases as well.
You can also connect with the community in the #kuberay channel on the CNCF or Ray Slack workspaces and attend our biweekly community meetings.