The KubeRay project, the Kubernetes operator that translates Ray clusters into native Kubernetes resources, is now a CNCF sandbox project. The move places KubeRay under Linux Foundation governance, aligning it with other PARK stack components (PyTorch, Ray, Kubernetes) that already live in CNCF or related foundations. For AI engineers, platform teams, and security practitioners, the shift signals a more stable, neutral roadmap and deeper integration with the broader cloud‑native ecosystem.
KubeRay CNCF integration
By joining CNCF, KubeRay gains formal governance, transparent contribution processes, and a clearer path to long‑term maintenance. The project remains open source, but the CNCF umbrella reduces vendor lock‑in risk and provides a recognized compliance framework for enterprises that require audited open‑source supply chains.
Core operator primitives
KubeRay continues to expose three custom resource definitions (CRDs) that map directly to Ray concepts:
RayCluster: Manages the full lifecycle of a Ray cluster, handling head and worker pod creation, health checks, GCS fault tolerance, and dynamic autoscaling via the Ray Autoscaler.RayJob: Designed for batch, training, or reinforcement‑learning workloads. It provisions an ephemeralRayCluster, runs the job, then tears the cluster down, optimizing accelerator utilization.RayService: Supports long‑running inference services built with Ray Serve. It coordinates the underlyingRayClusterand the Serve deployment graph, enabling zero‑downtime upgrades and automated failover.
These CRDs let platform engineers treat Ray workloads as first‑class Kubernetes objects, simplifying declarative deployment and lifecycle management.
Observability, scheduling, and security implications
KubeRay does not reinvent existing cloud‑native primitives; instead it plugs into established CNCF projects:
- Observability: Ray emits metrics in OpenTelemetry format and exposes them as Prometheus‑compatible endpoints. Combined with
PrometheusandFluent Bit, operators can collect cluster‑wide utilization, task latency, and log streams without additional agents. - Batch scheduling and quota management: Integration with
Kueue,Volcano, andKAIbrings gang scheduling, priority preemption, and multi‑tenant resource quotas toRayJobandRayCluster. This is especially relevant for GPU/TPU‑heavy training pipelines. - Workload security: KubeRay can enable automated mutual TLS (mTLS) for Ray internal traffic and leverages native Kubernetes network policies for isolation. While the source does not detail specific policy templates, the capability exists for engineers to enforce pod‑to‑pod encryption and restrict traffic flow.
Real‑world adoption signals
Enterprises such as Spotify have deployed KubeRay on Google Kubernetes Engine (GKE) to power internal machine‑learning platforms. Hark’s AI infrastructure team also cites KubeRay as a core component for scaling multimodal AI workloads. These references illustrate that production teams are already relying on the operator for both batch training and online inference.
Related CloudNinjas coverage: hands-on guides.
What This Means For Practitioners
Practitioners should treat the CNCF graduation as a cue to evaluate KubeRay for any Ray‑based workloads that need Kubernetes‑native management. Key actions include:
- Review existing Ray deployments and map them to the appropriate CRD (
RayCluster,RayJob, orRayService) to gain declarative control. - Integrate KubeRay metrics with your Prometheus stack and configure Fluent Bit pipelines for unified log collection.
- Assess whether your scheduler (e.g.,
KueueorVolcano) can be leveraged for GPU/TPU quota enforcement and gang scheduling of Ray jobs. - Enable mTLS and define network policies to isolate Ray components, especially in multi‑tenant environments.
- Monitor the CNCF sandbox roadmap and attend community meetings (e.g., the KubeRay BoF at KubeCon NA 2026) to stay informed about upcoming features and best‑practice guidance.
By aligning Ray workloads with the CNCF‑backed KubeRay operator, teams can reduce operational friction, improve observability, and adopt a security posture that matches the broader cloud‑native stack.


