DRA の Extended Resource 対応が GA、device plugin なしで GPU を要求できる

Kubernetes 1.37 の DRA で最初に見るべき変更は、Extended Resource 対応の GA だ。Pod spec に example.com/gpu と書く従来の要求を、DRA ドライバが、別に device plugin を用意せずに満たせる。GPU の割り当てを DRA に寄せたいが、既存のマニフェストは触りたくないチームに関係する。

残りは Beta が 3つ、Alpha が 7つだ。どれも DRA ドライバか feature gate の有効化を前提に説明されていて、ドライバを入れていないクラスタで今日やることは見当たらない。1.37 の別の変更は Storage Version Migration の GA に書いた。

段階と feature gate を一覧にする

機能	1.37 での段階	feature gate と既定値
Extended Resource 対応	Stable	記載なし
ResourceClaim status の devices	Stable	記載なし
Device taints and tolerations	Stable	記載なし
resource.kubernetes.io/numaNode 属性名	Stable	gate なし
Workload・PodGroup からの ResourceClaim 参照	Beta	DRAWorkloadResourceClaims、既定で無効
Device Attributes Downward API	Beta	記載なし
Consumable Capacity の小数値	節は Alpha、本文は Beta	DRAFractionalCapacityRange、既定は記載なし
属性のリスト型	Alpha（2回目）	記載なし
Node allocatable resource requests	Alpha（2回目）	記載なし
Resource availability visibility	Alpha（2回目）	記載なし
Optional Node Operations	Alpha	記載なし
Derived Attributes	Alpha	記載なし
Device Compatibility Groups	Alpha	DRADeviceCompatibilityGroups、既定で無効
PreQueueingHint	Alpha	SchedulerPreQueueingHints、既定は記載なし

出典：Kubernetes 公式ブログの 1.37 DRA Updates 記事（Kashish Verma、2026年9月3日公開）

「記載なし」が多いのは、ブログが gate 名と既定値を一部の機能にしか書いていないためだ。既定値まで確認できるのは、無効と明記された DRAWorkloadResourceClaims と DRADeviceCompatibilityGroups の 2つだけと読むのが安全だ。

Consumable Capacity の小数値対応は扱いに注意がいる。ブログでは Alpha features の節にありながら、本文では gate の DRAFractionalCapacityRange が「1.37 で Beta」とある。どちらが正しいかはブログだけでは判断できない。

example.com/gpu と書いたまま、割り当てだけ DRA に移す

仕組みは単純だ。DeviceClass に extended resource 名を直接設定すると、その名前を要求する Pod は ResourceClaim を書かなくても DRA 経由でデバイスに割り当てられる。従来はこの形の要求を受けるのに、DRA ドライバの横に別の device plugin が要った。

経緯は KEP の受理が 1.34、Alpha が 1.35、Beta が 1.36、そして 1.37 で Stable と、3リリース続けて進んできた。extended resource 向けに書かれた既存のワークロードは無変更のまま動き、割り当てのロジックだけが裏側で DRA に移る。

実務で変わるのは、GPU ノードを DRA へ移すときに device plugin を残すかどうかだ。DRA ドライバの横に device plugin を置く構成を、DeviceClass の設定で置き換えられる。ただし、手元の DRA ドライバがこの経路を実装しているかはブログに書かれていない。device plugin を外すのは、ドライバ側の対応を確認してからだ。

デバイス単位の taint と、NIC の IP が status に載る

Device taints and tolerations も Stable になった。DRA ドライバが taint を付けたデバイスは新しい Pod のスケジューリングから外れ、クラスタ管理者はドライバを再設定せずに DeviceTaintRule で同じ taint をクラスタ全体へ適用できる。使用中の Pod は自動 evict の対象になるが、ResourceClaim が taint を tolerate していれば残る。1つのデバイスだけを保守で外しても、残りには影響しない。

ResourceClaim の status には devices フィールドが入り、ドライバがデバイスごとの状態を報告できる。ネットワークデバイスならインターフェース名、MAC アドレス、IP アドレスが載る。設定後のデバイスの状態がこれまで見えなかった穴を埋め、報告された IP に依存するネットワークサービスを組む土台になる。

256 Pod の上限を越える claim には gate の有効化が要る

Workload と PodGroup から ResourceClaim を直接参照する機能が Beta に上がった。gate は DRAWorkloadResourceClaims で、既定は無効のままだ。有効にすると 1つの claim を Pod のグループ全体で共有できる。従来は Pod ごとの予約の上限で claim が 256 Pod までだったので、それを超えるジョブを組むならこの gate を試す理由になる。

Beta のもう一つは Device Attributes Downward API で、KubeVirt の VM へのデバイス注入を想定している。ドライバが claim の準備時に Metadata フィールドを埋めると、フレームワークが JSON ファイルに書き出して CDI 経由でコンテナにマウントし、ワークロードは PCI バスアドレスや MAC アドレスを直接読める。

Alpha で入ったもの、ベンチマークの数字があるのは PreQueueingHint

7つの Alpha のうち、スケジューラの判断かマニフェストの書き方に触る 4つを見る。

• Node allocatable resource requests は 2回目の Alpha で、DRA が管理する CPU やメモリをスケジューラと kubelet が通常の要求と同じに扱い、ノードの過剰割り当てと二重記載をなくす。
• Derived Attributes は CEL 式で独自の一致ルールを書く。numa と numaNode のような命名の違いをマニフェスト側で吸収でき、トポロジ文字列からの ID の切り出しや空き容量によるティア分けにも使える。
• Device Compatibility Groups は、同じ GPU の MIG と vGPU のようなパーティションに互換グループを付け、組み合わせられない要求をスケジューラが事前に弾く。gate DRADeviceCompatibilityGroups は既定で無効だ。
• PreQueueingHint は gate SchedulerPreQueueingHints で入るスケジューラの拡張点だ。ResourceClaim イベントのたびに unschedulable な Pod を全件走査していた経路を、pod informer のインデックスで対象だけに絞る。初期ベンチマークでスループットがおよそ 2倍とあるが、条件は示されていない。

自分のクラスタで何をするかを決める条件

DRA ドライバを入れていないクラスタなら、ここで挙げた項目のために設定を足す必要はない。どれもドライバか gate の有効化を前提に説明されているからだ。アップグレードだけで変わる挙動があるかはこのブログからは読み取れないので、リリースノートの feature gate の一覧で確かめる。

DRA ドライバと device plugin を並走させているなら、Extended Resource 対応の GA が最初の検討対象だ。ドライバの対応を確認し、DeviceClass に extended resource 名を設定して device plugin を外せるかを検証環境で試す。マニフェストは触らなくてよい。

1つの claim を 256 を超える Pod で共有したい、あるいは KubeVirt にデバイスを渡しているなら、DRAWorkloadResourceClaims の有効化と Downward API の検証が候補になる。どちらも Beta なので、本番の前に gate の既定値を自分のクラスタで確かめたい。