KubeRay standardizes Ray deployment on Kubernetes, per AnyScale

AnyScale says KubeRay is the standard way to run Ray on Kubernetes, positioning the open-source operator as the bridge between Ray workloads and Kubernetes-native infrastructure. In a blog post published on 15 Oct. 2026, the company said KubeRay reduces the hand-built deployment, submission, scaling and recovery logic teams otherwise need when they try to run Ray directly on Kubernetes.

Evidence and context

According to AnyScale, Ray is an open-source framework for scaling Python and AI workloads across many machines, while Kubernetes already manages infrastructure such as GPUs, quotas, access control, networking and monitoring. The problem, the company said, is that Kubernetes does not natively understand Ray clusters, Ray jobs or Ray Serve applications. KubeRay is designed to fill that gap by adding Kubernetes-native lifecycle management, autoscaling, scheduling, reliability and observability for Ray workloads.

AnyScale said KubeRay introduces three custom resources: RayCluster for long-running clusters, RayJob for single jobs that use ephemeral clusters, and RayService for Ray Serve applications. In the article, the company described RayCluster as the basic building block, with RayJob adding job submission and cleanup, and RayService adding Serve applications and a Serve service. The post also said KubeRay is the foundation of managed Ray offerings from major cloud providers.

The company drew a clear division of responsibilities between Kubernetes and Ray. Kubernetes schedules Pods onto nodes, while Ray schedules tasks and actors onto CPUs and GPUs inside those Pods. KubeRay sits between the two, translating a RayCluster spec into Pods and reporting Ray state back to Kubernetes through status fields and events. AnyScale said that lets platform teams continue using Kubernetes tools for node pools, quotas, access control and monitoring, while Ray users focus on Ray code and run it through the custom resources KubeRay creates.

Features and workload types

AnyScale listed several KubeRay capabilities. For RayCluster, it cited Ray-aware autoscaling based on pending tasks, actors and placement groups; Global Control Service fault tolerance for recovering cluster metadata after a head-node failure; and heterogeneous compute across worker groups with different CPU and accelerator configurations. For RayJob, it cited ephemeral clusters, multiple submission modes and lifecycle controls such as retries, deadlines and cleanup policies. For RayService, it cited high availability and zero-downtime upgrades, including blue-green and incremental rollout support.

The post also said KubeRay integrates with Kubernetes scheduling and security tools, including Kueue and MultiKueue, gang scheduling frameworks such as Volcano, YuniKorn, scheduler-plugins and NVIDIA KAI Scheduler, and token authentication, Kubernetes RBAC, mTLS and NetworkPolicy. On observability, AnyScale pointed to Prometheus, Grafana, Kubernetes-native status and Events, and a History Server for preserving events and logs in object storage after a cluster is deleted. It also highlighted kubectl ray and a KubeRay API Server as tooling for operators and user interfaces.

Deployment example and limitations

AnyScale said KubeRay works with any Kubernetes cluster and has been tested on managed services including Amazon EKS, Google Kubernetes Engine and Azure Kubernetes Service. The article included a RayJob example that used a Kubernetes custom resource to run a PyTorch Fashion MNIST training workload with Ray Train. In the example output, the RayJob moved from PENDING to SUCCEEDED, and the logged training result showed loss of 0.3702628721599095 and accuracy of 0.8646. Those figures were presented as output from the sample training run, not as a broader performance benchmark.

The source material does not provide an independent comparison of KubeRay against other Ray deployment methods, nor does it quantify adoption, performance gains or failure rates. It does, however, place the announcement in the context of ongoing Ray development: related news supplied with the brief noted Ray 2.59.0 on 2 Oct. 2026, which made Ray Data LLM and Ray Serve LLM APIs generally available and added disk-backed external shuffle, after Ray 2.57.0 on 11 Aug. 2026 enabled DataSourceV2 by default.