The operator that makes Ray behave on Kubernetes

What it does

KubeRay is a Kubernetes operator, written in Go, that manages Ray applications through three custom resources. RayCluster handles creation, deletion, autoscaling, and fault tolerance. RayJob spins up a cluster, submits your job when it’s ready, and can tear the cluster down afterward — the ephemeral-batch pattern without the scripting. RayService pairs a cluster with a Ray Serve deployment graph and offers zero-downtime upgrades and high availability.

The interesting bit

The boring part is the value: it reframes distributed ML as a Kubernetes reconciliation problem. Instead of babysitting head and worker pods, you declare intent and the operator converges. The adoption list backs this up — Spotify, Apple, DoorDash, Roblox, and Google have all given talks about running Ray this way at real scale.

Key highlights

• Three core CRDs: RayCluster, RayJob, RayService — the fully-maintained part of the project
• kubectl ray plugin (beta, since v1.3.0) for friendlier day-to-day workflows
• Optional APIServer (alpha) and an experimental dashboard (since v1.4.0) for building your own management UIs
• Integrates with the usual suspects: Prometheus, Grafana, Kueue, Volcano, YuniKorn, Nginx ingress
• Apache-2.0 licensed, with active Slack channels and bi-weekly community meetings

Caveats

• The dashboard is explicitly not production-ready; the APIServer is alpha
• All user-facing documentation lives on docs.ray.io, not in the repo — expect to hop between sites

Verdict

If you run Ray (or want to run LLM training/inference) on Kubernetes, this is the standard answer, with serious production pedigree. If you’re not on Kubernetes or not doing distributed Python, it’s irrelevant to you.