KubeRayの三つのカスタムリソースを運用へつなぐ確認点
プロジェクト概要：Kubernetes 上で Ray アプリケーションを実行するためのツールキット。 Kubectl プラグイン (ベータ): KubeRay v1.3.0 以降、kubectl ray プラグインを使用して、Kubernetes に Ray をデプロイする際の一般的なワークフローを簡素化できます。
ひと目でわかる
- これは何？
- Kubernetes上でRayを動かすKubeRayについて、RayCluster、RayJob、RayService、周辺コンポーネント、文書の所在を整理します。
- 誰に向いている？
- KubeRayは、Rayのクラスタやジョブ、サービスをKubernetesのリソースとして管理したいチームが評価するためのGo製オペレーターです。コアのRayCluster、RayJob、RayServiceと、ベータ、アルファ、実験中に分かれる周辺機能を混ぜずに扱ってください。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。直近 1 日以内に新しいコミットがあります。
- 何の言語で書かれている？
- 主に Go です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
KubeRayのコアは三つのCRD
ray-project/kuberayは、Kubernetes上でRayアプリケーションをデプロイし、管理しやすくするオープンソースのオペレーターです。READMEは公式に保守されるKubeRay coreとして、RayCluster、RayJob、RayServiceの三つのカスタムリソース定義を挙げています。Goで実装され、素材時点のGitHub情報ではstarsは2,653、forksは832、open issuesは771、既定ブランチはmasterです。
三つのリソースは役割が違います。RayClusterはクラスタ自体、RayJobはクラスタ作成とジョブ送信、RayServiceはクラスタとRay Serveのデプロイメントグラフを扱います。READMEの定性的な説明を運用の成功率や性能値と読み替えず、使うリソースを一つに絞った試験から始めると切り分けやすくなります。
RayClusterの作成、削除、オートスケール
RayClusterについて、KubeRayは作成と削除、オートスケール、フォールトトレランスを含むライフサイクルを管理するとREADMEに記載しています。これはKubernetes上のPod配置やRayクラスタの状態をオペレーターが追跡する構成を示しています。実際にどのフィールドでヘッドとワーカーを指定し、どの条件でスケールするかはユーザー向けのRayドキュメントを参照してください。
導入試験では、クラスタ作成後にRayの接続が成立するか、ワーカーの追加と削除が期待どおり起きるか、ノードやPodを意図的に停止した場合に復帰するかを確認します。READMEは処理量、復旧時間、スケールの上限を提示していません。Kubernetesのスケジューリング、GPU資源、ネットワーク、ストレージの制約が結果へ影響するため、環境情報を記録して判断します。
RayJobのジョブ単位運用
RayJobは、準備が整ったRayClusterへジョブを送信するためのリソースです。KubeRayは、RayJobを作成するとRayClusterを自動作成し、ジョブ完了後にクラスタを削除する設定もできると説明しています。短時間の学習やバッチ処理では、この作成から実行、終了までの境界が運用設計に関わります。
最初の試験では、ジョブが開始される前の状態、実行中のログ、成功終了、失敗終了、再実行、クラスタ削除の各状態を分けて観測します。永続データやチェックポイントをどこへ保存するかは、RayJobのライフサイクルとは別に決める必要があります。READMEはその保存方式や再試行の細部を示していないため、具体的なマニフェストとRayのジョブ文書を照合してください。
RayServiceと継続稼働の扱い
RayServiceは、RayClusterとRay Serveのデプロイメントグラフから構成され、RayClusterの無停止アップグレードと高可用性を提供するとREADMEは説明しています。推論サービスを継続稼働させながらモデルや設定を更新する用途では、このリソースがRayJobとは別の検討対象になります。
ただし、無停止という表現を自社のSLOへそのまま適用してはいけません。サービスの準備状態、トラフィック切り替え、古いクラスタの終了、モデルのロード、失敗時の戻し方を実際の構成で確かめます。KubernetesのPod障害、ノード交換、Ray Serveのデプロイメント更新を組み合わせ、リクエストエラーと復旧時間を記録してください。READMEの概要だけでは、利用予定のモデルや負荷に対する保証は得られません。
ベータから実験中までの周辺機能
KubeRay core以外にも、READMEは三つの周辺コンポーネントを挙げています。kubectl rayプラグインはv1.3.0からのベータ機能で、RayをKubernetesへ配置する一般的な操作を簡単にします。KubeRay APIServerはアルファ機能で、リソース設定の簡易層として一部組織の管理画面を支える用途が説明されています。
KubeRay Dashboardはv1.4.0から導入された実験的機能で、READMEは本番利用の準備ができていないと明記しています。コアCRDと同じ保守水準だと考えず、版と成熟度を環境表に置きます。各機能には個別のドキュメントがあるため、試す場合も本番の管理面へすぐ組み込まず、権限、認証、更新、削除の動作を先に確認してください。
ユーザー文書とKubernetes連携
2023年9月以降、ユーザー向けのKubeRay文書はRayのドキュメントサイトで公開され、GitHubリポジトリには開発と保守に関する文書が残るとREADMEにあります。RayCluster、RayJob、RayServiceにはそれぞれクイックスタートがあり、例は学習、LLMオンライン推論、バッチ推論などを扱います。
KubeRayはPrometheus、Grafana、py-spyなどの可観測性ツール、Volcano、Apache YuniKorn、Kueueなどのキュー、NginxなどのIngressコントローラーとの統合も説明しています。統合先が多いほど、KubeRayだけではなくKubernetes、Ray、監視、キューの版を合わせる必要があります。外部記事や講演の紹介は導入実績の参考にはなりますが、自社環境の互換性や性能を証明する資料ではありません。
開発、セキュリティ、Apache 2.0
開発者はCONTRIBUTINGガイドを読み、DEVELOPMENT.mdに従ってローカルビルドとテストを行うようREADMEに案内されています。セキュリティ問題は公開GitHub issueではなく、KubeRay SecurityチームへSlackで報告する手順です。通常の不具合報告と機密性のある問題の窓口を分ける運用を決めてください。
ライセンスはApache 2.0です。利用、改変、配布を検討する際は、KubeRay本体だけでなくコンテナイメージ、Ray、追加のHelmや監視部品のライセンスも一覧化します。最新リリースは素材時点でv1.7.0です。採用前には固定版でCRDの作成と更新、クラスタ障害、ジョブ終了、サービス更新、Dashboardを使わない構成、セキュリティ報告の流れを検証し、未確認事項を残してください。
編集部の結論
KubeRayは、Rayのクラスタやジョブ、サービスをKubernetesのリソースとして管理したいチームが評価するためのGo製オペレーターです。コアのRayCluster、RayJob、RayServiceと、ベータ、アルファ、実験中に分かれる周辺機能を混ぜずに扱ってください。ユーザー向けの手順と例はRayのドキュメントサイトへ移されているため、リポジトリだけで設定を推測しないことが大切です。利用するKubernetes環境で生成、更新、削除、障害復旧、アップグレードを試し、Apache 2.0とセキュリティ報告の手順を確認してから採用範囲を決めるべきです。
コミュニティノート