Donating KubeRay to CNCF: The PARK stack (PyTorch, AI models, Ray

The KubeRay project is officially joining the Cloud Native Computing Foundation as a sandbox project, placing the final core component of the emerging PARK open-source stack under Linux Foundation governance. According to CNCF Blog's report, the transition unites PyTorch and Ray from the PyTorch Foundation alongside Kubernetes from the CNCF under a single, vendor-neutral foundation. Andrew Sy Kim, Edward Oakes, Kai-Hsun Chen, Jui-An Huang, Richard Liaw, Robert Nishihara, and the KubeRay team announced the donation on November 10, 2026, to guarantee neutral oversight for the bridge layer connecting Python-driven distributed artificial intelligence frameworks to cloud-native compute orchestration.

This breakdown details how KubeRay operates as a Kubernetes operator, its three custom resource definitions, its native ties to CNCF scheduling and observability platforms, and its production deployment inside enterprise architectures. Platform engineers, machine learning operations teams, and distributed systems architects running machine learning workloads across hardware accelerators will find a comprehensive overview of how this governance shift standardizes Ray infrastructure operations across enterprise clusters.

01Unified governance for the PARK stack

Production artificial intelligence infrastructure increasingly relies on the PARK stack, an open-source architecture combining PyTorch, AI models, Ray, and Kubernetes. While PyTorch and Ray already operate under the PyTorch Foundation and Kubernetes resides within the CNCF, KubeRay previously sat outside that formal umbrella. Bringing KubeRay into the CNCF closes that governance gap, placing every foundational element of the stack under the oversight of the Linux Foundation.

The primary driver behind donating KubeRay to the CNCF is establishing open, vendor-neutral stewardship for enterprise infrastructure teams. Neutral governance ensures that no individual corporate sponsor controls development directions or deployment standards for the bridge between Python AI software and container engines. Engineering organizations investing long-term capital into Ray on Kubernetes can now adopt the stack with confidence that operational specifications will remain open and community-driven.

The operator provides a Kubernetes-native control plane specifically engineered for running distributed artificial intelligence, machine learning, and general Python jobs on containerized infrastructure. Because distributed model development has shifted into a primary cloud-native workload, KubeRay ensures that operational patterns match standard Kubernetes management practices without forcing machine learning teams to abandon Python-first machine learning frameworks.

02Three custom resources for cluster lifecycles

KubeRay implements its control plane through three dedicated Kubernetes Custom Resource Definitions, starting with RayCluster. As the fundamental building block for long-running environments, RayCluster manages head and worker pod provisioning, monitors health checks, guarantees Global Control Service fault tolerance, and handles dynamic scaling in direct coordination with the native Ray Autoscaler. Platform teams configure node shapes and cluster baselines while letting the operator handle automated provisioning.

For offline computation, the operator provides RayJob, a custom resource purpose-built to handle batch processing, distributed training, and reinforcement learning routines. RayJob automatically provisions an ephemeral RayCluster, monitors the environment until nodes reach a ready state, submits the specified Ray application, and destroys the entire cluster upon completion. This ephemeral cycle prevents idle node sprawl while maximizing accelerator and compute resource utilization across shared hardware pools.

Online model serving runs through RayService, a custom resource configured for high-availability inference powered by Ray Serve. RayService coordinates both the underlying RayCluster compute layer and the active Ray Serve deployment graph. It delivers automated failover, seamless traffic routing, and zero-downtime rolling upgrades when serving production artificial intelligence models across live endpoints.

03Enterprise scale and multimodal production use

Enterprise engineering teams rely on KubeRay to operate scaled machine learning infrastructure in active production. Spotify uses KubeRay on Google Kubernetes Engine to operate Hendrix, its internal machine learning platform. The platform team leverages the operator to provision the underlying compute required to train and fine-tune Spotify machine learning models, consolidating disparate training environments onto standard managed Kubernetes infrastructure.

Multimodal artificial intelligence applications also leverage the operator to simplify complex infrastructure pipelines. Kai-Hsun Chen, AI Infrastructure Lead at Hark and a core KubeRay contributor, explained that running multimodal artificial intelligence workloads at scale demands tight integration between Python-first frameworks and Kubernetes orchestration. Chen noted that KubeRay serves as that bridge to support scaling reliability and the orchestration of complex agentic workflows.

By decoupling application logic from infrastructure management, the operator allows data science and infrastructure groups to maintain clear boundaries. Data scientists submit jobs using native Ray scripts, while platform operations teams define underlying resource limits, node taints, storage volumes, and accelerator allocations through Kubernetes declarative manifests.

04Observability batch scheduling and cluster isolation

Beyond core pod lifecycle automation, KubeRay integrates directly into established CNCF operational tools rather than creating proprietary alternatives. In observability pipelines, Ray utilizes OpenTelemetry within its metric architecture and exports metrics in standard Prometheus format. Platform operators pair these metrics with Fluent Bit for log collection, enabling teams to aggregate distributed worker logs, track task execution, monitor compute utilization, and evaluate Ray Serve response latency on existing dashboards.

To manage scarce graphics processing units and tensor processing units, KubeRay connects natively with batch schedulers including Kueue, Volcano, and KAI. These integrations bring Kubernetes-native job queueing directly to RayJob and RayCluster resources. Platform teams can enforce multi-tenant quotas, execute topology-aware scheduling, configure priority preemption, and apply gang scheduling to guarantee all-or-nothing pod placement before distributed training begins.

Security across multi-tenant deployments is handled directly through native networking constructs. The KubeRay operator secures inter-node communication across Ray clusters using automated mutual transport layer security. Furthermore, administrators can enforce Kubernetes network policies to isolate tenant workloads, restrict cross-cluster access, and protect distributed compute clusters across corporate infrastructure.

05Community roadmap and KubeCon collaboration

The project transition into the CNCF sandbox marks an expansion of community involvement and technical roadmaps. Maintainers are engaging the broader cloud-native community through active discussion spaces, including the dedicated kuberay channel hosted on both the CNCF and Ray Slack workspaces. Community members and maintainers also coordinate ongoing architectural plans through biweekly community meetings open to outside contributors.

In-person collaboration around the KubeRay roadmap continues at industry events such as KubeCon North America 2026. The project maintainers are convening a Birds of a Feather session at the conference to review upcoming features, discuss production use cases, and outline future enhancements for running Ray clusters on Kubernetes.

Production users will also present their real-world implementations at the event, including a presentation by Hark covering how their infrastructure team uses KubeRay to scale multimodal artificial intelligence systems. These sessions aim to guide incoming community contributors and establish joint technical patterns between the Ray ecosystem and Kubernetes platform engineers.