はじめに
AI/ML ワークロードをクラウドネイティブに運用する流れが急速に広がっています。 これまではモデルのトレーニングや推論サービスを Kubernetes 上で動かす際、GPU の管理や動的なリソース割り当て、セキュアな通信設定など、いくつもの課題がありました。
2025年11月にリリースされた Kubernetes 1.35 では、こうした課題に対応するための 新しい alpha 機能群 が登場しています。 特に「AI-native workloads（AI ネイティブ ワークロード）」のオーケストレーションを改善する機能がいくつか追加されており、エンタープライズ環境での実用を見据えた動きが見えてきました。
本記事では、これらの新機能のうち スケーラビリティ・セキュリティ・安定性 の観点で注目すべきものを中心に解説します。
💡 コラム：そもそも「Alpha機能」とは？
Kubernetes では、新しい機能は Alpha → Beta → Stable（GA） の順に成熟していきます。 「Alpha機能」はその最初の段階であり、まだ開発途上・仕様変更の可能性がある試験的機能です。
| 段階 | 概要 | デフォルト有効 | 本番利用 |
|---|---|---|---|
| Alpha | 開発初期。仕様変更・削除の可能性あり。 | ❌ 無効 | 🚫 非推奨 |
| Beta | 安定化段階。APIはほぼ確定。 | ⚪ 一部有効 | ⚠️ 慎重に |
| Stable (GA) | 安定版。将来も維持される。 | ✅ 有効 | ✅ 推奨 |
Alpha 機能はデフォルトでは無効で、明示的に有効化する必要があります。 例：
kube-apiserver \
--feature-gates=PodLevelResources=true,InPlacePodVerticalScaling=true
🚧 注意点
- 将来のリリースで API仕様や動作が変更／削除される可能性 があります。
- 安定性が保証されない ため、本番利用は避け、PoC や検証環境でのテストが推奨されます。
- 周辺ツール（kubectl, Helm, Operatorなど）が未対応な場合があります。
💡 それでも試す価値がある理由
AI/ML ワークロードのように新しい運用領域では、 こうした Alpha 機能を早期に検証することで以下のようなメリットがあります：
- 近い将来の機能方向性をいち早く把握できる
- 自社クラスタ設計やGPUスケジューリング戦略を先取りできる
- 顧客やチームに「次期Kubernetes対応方針」を示せる
1. Kubernetes 1.35 の新機能 — AIワークロードを支える3本柱
1.1 Pod-Level Resources + In-place Vertical Scaling (α)
これまでの Kubernetes では、CPU やメモリなどのリソース要求 (requests / limits) は コンテナ単位 でしか設定できませんでした。 しかし AI/ML ワークロードでは、「Pod 全体としてのリソース消費」を前提に設計されるケースが多く、個々のコンテナに正確なリソース配分をするのは現実的ではありません。
Pod-Level Resources はこの課題を解消します。Pod 全体で必要なリソース量を指定できるようになり、スケジューラがそれに基づいて最適なノードに配置します。 さらに In-place Vertical Scaling により、Pod を削除せずに CPU / メモリを再調整できるようになります。
apiVersion: v1
kind: Pod
metadata:
name: ai-trainer
spec:
containers:
- name: trainer
image: my-ml-trainer:latest
resources:
requests:
pod.kubernetes.io/memory: "64Gi"
pod.kubernetes.io/cpu: "8"
これにより、以下のような運用が可能になります：
- モデル学習中に必要メモリ量を動的に増やす
- 推論サービスが高負荷時に一時的にリソースを拡張
- Pod 再起動なしで垂直スケーリングが可能
1.2 Dynamic Resource Allocation (DRA) 拡張
GPU や AI チップなど特殊なリソースを動的に割り当てる仕組みとして、Kubernetes 1.29 で登場した Dynamic Resource Allocation (DRA) が 1.35 でさらに拡張されました。
これにより、AI ワークロードが以下のような柔軟な挙動を取れるようになります：
- トレーニング → 推論 → 後処理 というフェーズ間で GPU 要求を動的に変更
- 一時的に GPU リソースを解放し、他のジョブに譲渡
- 複数の Pod が共有する GPU プールを効率的に利用
resources:
claims:
- name: nvidia-gpu
resourceClassName: nvidia.com/gpu
requests:
count: 2
これにより、リソース効率とコスト最適化 が大幅に改善されます。 特にエンタープライズ環境では、GPU のアイドル時間を減らすことが経済的インパクトに直結するため、非常に有用です。
1.3 Workload Identity + Pod Certificates Rotation
セキュリティ面でも重要なアップデートがあります。 これまでは Pod 間通信をセキュアに保つために Service Mesh や外部 CA 管理が必要でしたが、Workload Identity の強化により、Kubernetes 自体が Pod 単位の証明書管理と自動ローテーション を提供できるようになります。
これにより：
- モデルサーバ、前処理・後処理サービス間の通信を mTLS で保護
- 外部 PKI に依存しないゼロトラスト構成が容易に
- 短命な Pod でも安全に認証・通信が可能
AI パイプライン全体をマイクロサービス化する場合に不可欠な基盤要素となります。
1.4 containerRestartRule と安定性向上
AI トレーニングやデータ前処理バッチは長時間実行が前提となりますが、1 コンテナが異常終了しただけで Pod 全体が中断してしまうのは望ましくありません。
Kubernetes 1.35 では containerRestartRule が導入され、コンテナ終了時の再起動ポリシーをより細かく制御できるようになりました。
restartPolicy: OnFailure
containerRestartRule: Always
これにより、たとえば「特定コンテナだけ再起動し、他のコンテナは継続動作」といった柔軟な挙動を定義できます。 AI モデルのトレーニングジョブの安定稼働に役立ちます。
2. 実運用を想定した3つのシナリオ
| ワークロード | 主な課題 | 有効な新機能 |
|---|---|---|
| モデル学習バッチ | リソース変動が大きい、長時間実行 | Pod-level Resources / DRA / containerRestartRule |
| 推論サービス (API) | 短時間で負荷が変動、セキュリティ要求 | In-place Scaling / Workload Identity |
| データ前後処理 | ジョブ多発・リソース効率重視 | DRA / Pod-level Resources |
すべてが単一の Kubernetes クラスタ上で完結し、リソース・セキュリティ・安定性が統合的に制御できる時代が近づいています。
3. 今後の展望と留意点
- これらの機能は現時点では Alpha 機能 のため、本番適用には慎重な検証が必要です。
- GPU 管理まわりでは、NVIDIA Device Plugin や Kueue などの関連プロジェクトとの連携を意識することが重要です。
- 今後の Kubernetes リリースでは、AI/ML ワークロードを “第一級市民” として扱う方向に進化していくでしょう。
まとめ
Kubernetes 1.35 は、単なるコンテナオーケストレーターから「AIネイティブ基盤」への進化を強く印象づけるリリースです。
特に以下の3点は、今後の AI プラットフォーム設計において重要なキーワードになります：
- Pod-Level Resource Management — 柔軟なスケーリングと効率化
- Dynamic Resource Allocation (DRA) — GPU/特殊リソースの最適運用
- Workload Identity & Security — ゼロトラストな AI パイプライン構築
AI ワークロードを Kubernetes に統合する時代は、すでに始まっています。 本番環境への導入前にこれらの新機能を試し、次世代の AI プラットフォーム基盤をいち早く検証してみてはいかがでしょうか。