8月28日、Kasia Hilborne（Vultr）が「Your Kubernetes platform is ready for containers. Is it ready for AI?」と題した記事を公開した。AIワークロードをKubernetesプラットフォームで本番運用するために何を変えるべきか——その問いに、実践的な4つの拡張ポイントとして答えた内容だ。
CNCF 2025 Annual Cloud Native Surveyによれば、生成AIモデルをホストしている組織の**66%が推論ワークロードの一部または全部にKubernetesを使用している。一方、AIモデルをデイリーでデプロイしている組織はわずか7%**にとどまる。「KubernetesでAIが動く」ことと「AIを継続的に運用できるプラットフォームが整っている」ことは別問題だ、というのがこの記事の核心だ。
さらに、2025 State of AI in Platform Engineeringによると、35%のプラットフォームチームがAIワークロードをまだオーケストレーションできていないと回答している。前者の66%・7%はKubernetesユーザーの「動かせる／継続運用できる」のギャップを示し、後者の35%はプラットフォームチーム側の整備不足を示す数値だ。採用のスピードと運用基盤の整備がかみ合っていない実態が、複数の調査から一貫して浮かび上がる。
記事では、既存のクラウドネイティブプラクティス（GitOps、オブザーバビリティ、自動化、セルフサービス）をゼロから捨てる必要はないと述べている。ただし、AIが持ち込む4つの新しい要件には対処が必要だ。
1. リソースモデルをCPU・メモリの外へ拡張する
AIをGPUワークロードとして単純に捉えるのは危険だ。実際の本番AIパイプラインは、データ前処理・検索・オーケストレーションはCPUで動き、学習や推論はGPUや他のアクセラレーターを使うという異種混在（ヘテロジニアス）構成になる。
このことはスケジューリングの複雑さに直結する。プラットフォームチームは、CPU・メモリだけでなく、アクセラレーターの種類・可用性・トポロジー・ワークロード特性を考慮した上でポッドを配置する必要がある。
Kubernetes本体もこれに対応しつつある。**Dynamic Resource Allocation（DRA）**は、ワークロードが特殊ハードウェアを宣言的にリクエストできる柔軟な仕組みだ。従来のresources.limitsベースのGPU割り当てでは、GPUをデバイスプラグイン経由で整数単位に予約するだけで、ハードウェアのトポロジーや複数デバイス間の依存関係を表現しにくかった。DRAはこの制約を解消し、ドライバーが提供するリソースクラスを通じてより細粒度かつ柔軟なリソース要求を記述できる。目標は「GPUを使えるようにする」ことではなく、異種コンピュートをKubernetesの一貫したリソースモデルに組み込むことだ。
2. CI/CDをモデルのライフサイクルまで伸ばす
クラウドネイティブ開発では、アプリケーションコードのデリバリーはCI/CDとGitOpsで再現性が確立されている。AIはそこにモデルという新しい成果物を加える。
従来のパイプライン：
Code → build → test → deploy
AI対応後のパイプライン：
Code + model + configuration → evaluate → deploy → observe → update
モデルは容量が大きく、特定のランタイムやハードウェアに依存し、デプロイ前の評価が必要になる。「どのアプリ・モデル・設定が動いているか」「そのデプロイを再現できるか」を答えられる状態にすることが求められる。原則はシンプルで、変更はバージョン管理・再現可能・監査可能であること。デリバリーパイプラインがアプリコード以上のものを扱えるように拡張するだけだ。
3. クラスターではなくワークロードを観測する
CPU・メモリ・レイテンシといった従来のインフラメトリクスはAIでも必要だが、それだけでは不十分だ。追加で可視化が必要になる項目として記事は以下を挙げている。
- アクセラレーターの使用率とメモリ使用量
- スケジューリング待ち時間・キュー時間
- 推論レイテンシ・モデルロード時間・スループット
- エンドポイントのヘルス
重要なのは、AI専用の別監視スタックを立てることではない。既存のクラウドネイティブオブザーバビリティ（OpenTelemetryやPrometheusなど）を拡張し、インフラ・アプリ・AI固有のテレメトリーを一括して相関分析できるようにすることだ。「GPU使用率」だけでは答えられない問い——「ワークロードはどこで待たされているのか」——に答えられる状態が目標だ。
4. AI開発者にゴールデンパスを提供する
AIモデルをデプロイするためにKubernetesのインフラ詳細を知る必要がある、という状況はプラットフォームとして未成熟だ。プラットフォームチームがすべきは、共通のインフラ判断を組み込んだ標準化されたセルフサービスパスの提供だ：
Model → resources → deployment → endpoint → observability → policy
開発者はワークロードの要件を指定し、プラットフォームが実装を担う。これはクラウドネイティブのアプリデリバリーで実績のあるプラットフォームエンジニアリングの原則と同じだ。たとえば、データサイエンティストがモデルのサイズとレイテンシ要件を申告するだけで、適切なGPUノードの選択・エンドポイントの公開・メトリクスの収集までが自動で整う、といった状態がゴールとして想定される。違いは、ゴールデンパスがコンテナ・CPU・メモリに加えて、モデルとアクセラレーターを理解している必要がある点だ。
「AIも普通の本番ワークロード」にすることがゴール
記事の結論は明快だ。AIはリソースタイプとライフサイクル要件の点で新しいが、運用上の課題の多くはすでにクラウドネイティブコミュニティが解いてきたものと同質だ。新しい並列運用モデルを作るのではなく、既存プラクティスを拡張することでAI対応を果たすべきだと主張する。
「KubernetesはAIを動かせるか」という問いはすでに過去のものだ。問うべきは「KubernetesでのAI運用を、他の本番ワークロードと同じくらいルーティン化できるか」だ。
詳細はYour Kubernetes platform is ready for containers. Is it ready for AI?を参照していただきたい。
