KubeRayのベストプラクティスは、生産規模とクラスターの故障に焦点を当てています

Anyscaleの最新のKubeRayフィールドガイドは、Rayワークロードが単一の成功したジョブから共有の本番環境インフラへ移行した際に何が変わるかに焦点を当てています。2026年10月26日に公開されたこの投稿では、最も一般的な障害は一時的なクラスター、GPUの競合、オートスケーラのデフォルト、ヘッドノードの乱れに起こると述べており、基本的なRayJobフロー自体に起こるものではありません。

証拠と背景

記事ではKubeRayをRayとKubernetesの架け橋と説明し、本番環境のRayJobは通常、GPU、Kueueベースのキューイング、ヘッドノード隔離、ワーカースケール・トゥ・ゼロ動作を追加すると述べています。また、Ray 2024 Trainが 10,000 Kubernetesノードにスケールした公開講演を引用し、その例を用いてクイックスタート展開とフリートスケール運用のギャップを位置づけています。

いくつかの具体的な運用シナリオが特定されています。まず、ログやダッシュボードが短命に使えるRayJobsで消えてしまうことがあり、実行開始直後の故障を診断しにくくします。次に、PCIe、NVLink、NFSなどのハードウェア問題が、ポッドがまだ準備完了を報告していてもアプリケーションエラーとして現れることがあります。第三に、デフォルトのオートスケーラ設定は競合時に崩壊し、例えば配置グループが形成が遅くなったり、再試行でリソースが滞留したりする場合などです。また、ヘッドノードの消耗、メモリ負荷、サービスメッシュやその他のプラットフォーム制御による共有クラスタの副作用がクラスタ全体のワークロードを低下させる可能性があるとも述べられています。

そのようなケースに対応するため、本投稿では六つの実践を推奨しています:クラスタを削除する前にログやイベントをオブジェクトストレージや外部ログスタックに永続化すること、DCGMエクスポーターアラートやノードの健康チェックを用いてGPUの健康状態をスケジューリング信号として扱うこと、静かなクラスタ挙動ではなく本番競合を調整すること、ヘッドをタスクスケジューリングを行わず必要に応じてフォールトトレランスを用いることでヘッドノード損失に備えること、Rayを既存の名前空間、ポリシー、メッシュに組み込むこと、そして重要な障害に対してアラートを行いながら可能な限り最初の応答を自動化すること。

このソースはKubeRayの組み込み機能に関するバージョンコンテキストを追加します。提供されたエンリッチメントで引用されたリリースノートによると、KubeRay v1.7.0は2026年8月20日にリリースされ、Ray History ServerおよびRayServiceの段階的アップグレードをベータ版に移行し、alpha mTLSおよびNetworkPolicyのサポートを導入しました。KubeRay v1.7.1は2026年9月21日にリリースされ、RayJobの送信停止とHistory Serverのログ収集を修正し、ライブクラスタプロキシをデフォルトで無効化しました。

また、記事が述べているコミュニティおよび運用上の制限、例えば手動チャージバックマッピング、MultiKueueがカバーする範囲を超えたマルチクラスタオーケストレーション、チームやクラスターの増加に伴うカスタムヘルスチェックやグルーコードの維持コストなども指摘されています。さらに、現在プライベートプレビュー中のAnyscale KubeRay Connectを、既存のKubeRay、Kueue、GitOpsワークフローを変更することなく、永続的なダッシュボード、集約ログ、相関GPUおよびKubernetes信号、その他の管理機能を提供するレイヤーとして位置づけています。

この記事のタイミングが重要なのは、強化内容でKubeRayが2026年10月27日から公式にサポートされているRayのオープンソースKubernetesオペレーターとして特定されており、RayCluster、RayJob、RayServiceがクラスタのライフサイクル、バッチジョブ、サービングのコアリソースタイプとして残っているからです。この記事ではKubeRay Connectのリリース日については、プライベートプレビュー中であることのみ明記しており、価格や広範な採用データも含まれていません。