概要

Kubernetes v1.37がリリースされ、GPUなどのデバイスをきめ細かく割り当てる仕組み「Dynamic Resource Allocation（DRA）」まわりの複数機能が正式版（GA）に到達した。DRAの拡張リソース対応、ResourceClaimステータスへのネットワークデバイス情報付与、デバイスへのTaint/Toleration機能がいずれもGAとなり、標準numaNodeデバイス属性もあわせて安定版となった。またHorizontalPodAutoscaler（HPA）によるワークロードのゼロレプリカへのスケールダウン機能がベータに昇格し、デフォルトで有効化された。AI/MLワークロードを中心に、リソース管理の柔軟性とコスト効率がさらに高まる格好だ。

DRAの拡張リソース対応とネットワークデバイス情報がGAに

DRAの拡張リソース対応は、v1.34でKEPが採用されて以降、v1.35でアルファ、v1.36でベータと段階を踏み、v1.37で正式にGAへ到達した。DeviceClassに拡張リソース名（例: example.com/gpu）を直接紐付けられるようになったことで、既存のデバイスプラグインベースのワークロードを変更せずに動かしながら、クラスタ管理者はDRAへ段階的に移行できる。デバイスプラグインの導入なしにDRAの恩恵を受けられる点が実務上の利点だ。

あわせて、ResourceClaimのステータスに標準化されたネットワークインターフェース情報（インターフェース名、MACアドレス、IPアドレスなど）を持たせる機能（KEP-4817）もGAとなった。ネットワークデバイスが報告するIPアドレスに依存するネットワークサービスの構築や、ユーザー・コントローラーによるデバイス状態の可視化が容易になる。また、NUMAノードを示す属性がドライバーごとにバラバラだった問題を解消する、標準のnumaNodeデバイス属性もv1.37で直接GAとして導入され、異なるドライバーのデバイスをNUMAノード単位で横断比較できるようになった。

デバイスTaint/TolerationがGA、メンテナンス運用を効率化

ノードレベルのTaint/Tolerationと同様の仕組みをデバイス単位で実現する「DRA: Device Taints and Tolerations」（KEP-5055）もGAに到達した。ドライバー側で個々のデバイスにTaintを設定するほか、クラスタ管理者がDeviceTaintRuleリソースを使ってDeviceClass単位で一括設定することもできる。効果はNoSchedule（新規Podのスケジューリングを停止）とNoExecute（新規スケジューリング停止に加え、Tolerationのない既存Podを退避）の2種類で、Pod側は通常のTolerationと同じ書式で許容を指定する。これにより、GPUなどの高価なデバイスをメンテナンスに入れる際に、対象デバイスへの新規割り当てを止めつつ既存ワークロードを安全に退避させる、といった運用がKubernetesネイティブな機能だけで完結する。

HPAのゼロスケールがベータでデフォルト有効化

DRA関連の更新とは別に、HorizontalPodAutoscalerによるワークロードのゼロレプリカまでのスケールダウン機能もv1.37でベータに昇格し、追加のフィーチャーゲートなしにデフォルトで有効となった。これまでアルファ機能やアドオンに頼る必要があった「スケールtoゼロ」が、HPAのコア機能として利用できるようになる。ただし、Podがゼロになるとメトリクスを取得できなくなるCPU/メモリ使用率は使えず、Prometheus Adapterなどを介した外部メトリクスやオブジェクトメトリクス（キューの滞留数など）を指標にする必要がある。またサービスはPodがゼロの間リクエストをバッファリングしないため、HTTPなど同期的なリクエスト駆動型ワークロードには別途バッファリング層が必要になるなど、キューコンシューマーやバッチ処理といった非同期・間欠的なワークロード向けの機能である点には注意が要る。

今後の展望

Kubernetesチームは今回GAとなった拡張リソース対応について「3つの連続したリリースを通じて推し進めてきた」としており、アルファからGAまで着実に品質を積み上げてきた経緯を強調している。拡張リソースとの互換性により既存ワークロードは無修正のまま動作を継続できるため、クラスタ管理者はまず現行の運用を維持しつつ、Taint/TolerationやネットワークデバイスステータスといったDRA固有の新機能を段階的に取り入れていくことになりそうだ。あわせてHPAのゼロスケールがコア機能として定着したことで、AI/MLの学習・推論基盤に限らず、コスト効率を重視するサーバーレス型・イベント駆動型ワークロードでのKubernetes活用がさらに広がる可能性がある。