共有GPUクラスタでジョブが待ち続けるとき、見直すべきなのはGPUの台数だけではありません。チームにどこまで資源管理を任せるかと、空いた資源を次に誰へ渡すかでも、待ち方は変わります。

2026年10月28日のCNCFの紹介記事は、Volcano v1.16.0で加わったNamespaceQueueとfairshareを取り上げています。バージョン自体は2026年10月14日に公開されており、掲載日とは別です。

Kubernetes上で複数チームの計算基盤を運用するなら、この2つをどの問題に使うかが導入判断の出発点になります。キュー管理の権限、時間を含めた公平性、実際の配置先を順にたどると、v1.16で変えられることと残る制約が見えてきます。

NamespaceQueueで資源プールの承認とチーム内の管理を分ける

従来のクラスタスコープのQueueは、チームごとに資源プールを割り当てる構成に適しています。一方、チームの管理境界がNamespaceなら、その内側で学習用・推論用などのキューを自分たちで管理したくなります。

NamespaceQueueは、そのためのNamespace単位のキューです。管理者が親Queueのspec.allowedNamespacesで接続を許可し、テナントは自分のNamespace内でキュー階層を作ります。資源プールへの参加を承認する操作と、参加後のキュー管理を分担できるわけですね。

参照先の書き方にも区別があります。たとえばteam-aのJobから指定する場合、次のように読み分けます。

指定する場所	値の例	参照先
Jobのspec.queue	training	クラスタスコープのQueue
Jobのspec.queue	namespace/training	同じNamespaceのNamespaceQueue
NamespaceQueueのspec.parent	cluster/research	親となるクラスタQueue

既存の接頭辞なしのキュー指定が、自動的にNamespaceQueueへ切り替わることはありません。テナントへのnamespacequeuesのRBAC権限付与と、Ready=True・Authorized=Trueの確認も必要です。v1.16.0のNamespaceQueueガイドでは、この機能をAlpha・既定で無効としています。

有効化には階層対応のcapacityが必要で、独自のスケジューラ設定ならenableHierarchy: trueを指定します。proportionとの併用はできません。既存の重み付けによる配分から移る場合は、資源量を指定して貸し借りするcapacityの配分モデルまで含めて見直したいところです。

fairshareは現在の割り当てに過去の使用時間を加える

キューを管理できるようになっても、同じQueueへ複数のNamespaceからジョブを投入する構成では、別の公平性が問題になります。あるチームがジョブを絶えず追加すると、終了して空いたGPUを同じチームの次のジョブが使い、後から来たチームが待ち続けることがあります。

fairshareは、Queue内のNamespaceごとに資源量と使用時間の積を蓄積し、履歴の少ない側を先に検討します。現在の割り当てを扱うDRFに、時間の視点を補う仕組みです。Queue間の配分を置き換えるものではありません。

履歴は指数的に減衰し、半減期の既定値は4時間です。設計資料の減衰式はusage × 2^(-elapsed / halfLife)で、追加消費がなければ、ある時点の履歴の寄与は4時間後に半分、8時間後に4分の1になります。これは式から求めた例で、ジョブの待ち時間を予測する値ではありません。

ただし、fairshareが変えるのは待機中ジョブの順序と、任意で有効にするenqueueの受け入れ判定です。実行中ジョブからGPUを取り上げる機能はないため、長時間動くジョブで埋まっている場合に、後続ジョブをすぐ開始できる保証はありません。

導入時は設定の並びも効きます。比較処理は先に差を付けたプラグインで決まるため、履歴を判断に使うにはfairshareをdrfより前へ置きます。PriorityClassを優先するならpriorityはさらに前です。v1.16.0のfairshareガイドに、この順序の理由と設定が示されています。

履歴を再起動後も残すfairshare.persistStateは既定でfalseです。運用評価では対象Queueと資源種別を絞り、ConfigMapへの履歴保存も含めて、再起動の前後で待機順序を比べると判断しやすくなります。

HyperNodeで実行順序と障害に備えた配置を別々に設計する

誰を次に動かすかが決まっても、複数の推論インスタンスが同じスーパーノードに集まれば、同じ障害の影響を受ける可能性が残ります。v1.16のPodGroupトポロジーanti-affinityは、HyperNodeで表した領域を使って、異なるPodGroupを分散させます。

requiredは分離を必須にし、preferredは分離を優先しつつ同じ領域への配置も許します。前者では条件を満たす領域や資源が足りなければPendingになるため、分離の保証と配置のしやすさを選ぶことになります。対象を選ぶのはPodGroupのラベルで、Podのラベルではありません。PodGroup Anti-Affinityガイドで指定対象を確認できます。

適用範囲はallocateです。backfillで配置するBestEffort Podには同じ分離保証がなく、稼働中Podを自動で再配置する機能もありません。推論サービスに使うなら、PodGroupの指定だけでなく、メンバーPodがどの経路で配置されるかまで見る必要があります。

別のスケジューラを使う基盤にも接点があります。HyperNodeコントローラの単独配置により、Volcano全体を動かさずにトポロジーの検出・管理を利用できます。配置への利用は連携するスケジューラ側で実装します。既存の統合構成から移す場合は、disabledへの切り替えとロールアウト完了を挟んでstandaloneへ進み、管理主体が重複しないようにします。

v1.16への更新は配分ルールと配置条件を確かめながら進める

NamespaceQueueや新しいPodGroupのフィールドを使う前に、コンポーネントと併せてCRD・RBACも更新します。また、v1.16.0では新しいNamespaceQueue CRDにHelmアンインストール時の保持用注釈がありません。再インストールを更新手順に含めるなら、CRDの保持と所有関係を先に点検する必要があります。公式リリース解説の更新時の注意に記載されています。

性能改善も、配分設定との組み合わせで評価します。新しいUnschedulable Job Cacheは、配置できなかった理由を記録して不要な再判定を減らしますが、Alpha・既定で無効です。NamespaceQueueが必要とする階層型capacityによる拒否は、この版のキャッシュ対象に含まれません。キャッシュの利用ガイドは、親Queueと兄弟Queueの資源解放の関係を安全に追う必要があるためと説明しています。

更新判断には修正内容も含めます。DRAの容量計算でスケジューリングを妨げられるGHSA-j38h-7pfq-cxmwは、v1.15.0・v1.15.1が影響対象で、修正はv1.15.2とv1.16.0に含まれます。該当環境では勧告の成立条件を照合し、新機能の採用とは分けて修正版への更新を判断します。

共有基盤で最初に決めたいのは、待ち時間の問題が「チーム内の資源管理」「共有Queue内の実行順序」「配置できる領域」のどこから来るかです。管理を委ねるならNamespaceQueue、過去の消費を順序に反映するならfairshare、インスタンスを分散するならPodGroupの配置規則が候補になります。ひとつの機能ですべてを解こうとせず、実際の待機理由に合う変更から検証すると、v1.16を採用する理由が明確になります。

出典

• Title: Volcano v1.16 Released: NamespaceQueue, fairshare, and a broader HyperNode ecosystem
• URL: https://www.cncf.io/blog/2026/10/28/volcano-v1-16-released-namespacequeue-fairshare-and-a-broader-hypernode-ecosystem/