CNCFブログ：Kubernetes上でのAIエージェント、Pod を実行単位として再考
本文の状態
日本語全文を表示中
詳細モードで約6分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
InfoQ AI/ML
Lin Sun氏はCNCFブログで、kagentプロジェクトの知見に基づき、AI エージェント数が膨大になった際、Pod を実行単位としては適切だが、デプロイ・アイデンティティ・ライフサイクルの単位としては不適切であると論じた。
AI深層分析を開く2026年8月6日 15:21
AI深層分析
キーポイント
Pod の役割の再定義
Lin Sun は、エージェント数が急増する環境において、Pod を実行単位としては適切だが、デプロイ・アイデンティティ・ライフサイクル管理の単位としては不適切であると主張している。
kagent の実装アプローチ
kagent プロジェクトは、各エージェントを独立した Kubernetes ワークロード（Pod、Service、ServiceAccount）として扱うことで、プロセス分離や認証・認可の統合を実現し、後に Agent Sandbox を導入して隔離性を強化した。
マイクロサービスとの挙動差異
エージェントは常時稼働するマイクロサービスとは異なり、タスク割り当て時に起動し短時間で終了したり、人間承認を待ってアイドル状態になったりするため、Pod を個別に割当てることはリソースの無駄になり得る。
制御プレーンによる管理
Google は Kubernetes の上に制御プレーンを導入するアプローチとして Agent Substrate を発表しており、kagent もこの統合をサポートしている。
抽象化と既存概念の対応
WorkerPool は NodePool に、Workers は Nodes に、ActorTemplate は Pod の宣言仕様に対応する。Kubernetes はワーカープールとテンプレートのみを認識し、エージェントのライフサイクル管理は上位レイヤーが担う。
重要な引用
the Pod may be the right execution unit for an agent while no longer being the right deployment, identity, or lifecycle unit
Agents do not behave like the microservices these abstractions were designed around
Pods are excellent execution environments, but that does not make them the right lifecycle abstraction for short-lived, bursty work of this shape
Pods become the execution workers, not the deployment model for agents.
編集コメントを表示
編集コメント
本記事は、AI エージェントの普及に伴うインフラ設計の根本的な見直しを促す重要な指摘を含んでいる。従来のマイクロサービスモデルへの安易な適用がリソース浪費や管理の複雑化を招く可能性を示唆しており、Kubernetes ユーザーにとって実用的な示唆に富む内容である。
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
CNCF のブログ記事「Pod は AI エージェントにとって適切なデプロイ単位なのか？」（2026 年 7 月 14 日付）で、Lin Sun 氏は kagent プロジェクトでの取り組みを踏まえ、「Pod はエージェントの実行単位としては適切だが、デプロイ単位やアイデンティティ、ライフサイクルの管理単位としてはもはやふさわしくない」と主張しています。
エージェント数が膨大になった際に浮き彫りになる課題は、すでに馴染み深いものです。例えば、1 つのエージェントを他からどう隔離するか、各エージェントに固有の ID をどう付与するか、アクセス制御やネットワークポリシーをどう適用するか、個々のエージェントが何をしているかを可視化する方法、そしてマルチテナント環境で誰がエージェントを所有・管理するかといった点です。これらは本質的に Kubernetes の問題というより、エージェントプラットフォーム全体の課題ですが、その解決策は結局 Kubernetes 上で実装されることになります。
シンプルなアプローチとして、各エージェントを Kubernetes の第 1 級ワークロードとし、それぞれに Pod、Service、ServiceAccount を割り当てる方法があります。これは kagent が採用した手法で、当初は単一のランタイム内で多数のエージェントを実行していましたが、この方式に移行しました。これにより、プロセスとコンテナの分離が実現され、既存の認証・認可システムに接続可能な ServiceAccount のアイデンティティが提供されます。また、Kubernetes のネットワーク制御や承認ポリシーを適用可能になり、ログ、メトリクス、トレースをエージェントごとに個別に追跡できます。さらに、Kubernetes ネイティブなスケジューリングとリソース管理も利用可能です。
kagent はその後、Kubernetes Agent Sandbox プロジェクトを通じて、より強力な分離機能のサポートを追加しました。
しかし、課題はエージェントがこれらの抽象化が想定するマイクロサービスとは異なる振る舞いをすることです。常時稼働が前提となるマイクロサービスと異なり、エージェントはタスクを割り当てられたときだけ起動し、数秒から数分間動作した後にアイドル状態になることがあります。そのため、潜在的なエージェントごとに専用 Pod を用意するのは非効率です。
また、エージェントは並列実行のためにサブエージェントを生成したり、ユーザーに代わって行動したり、人間の承認待ちで無期限に待機したりすることもあります。Pod は優れた実行環境ですが、こうした短命かつバースト性の高いワークロードには、適切なライフサイクル抽象化とは言えません。
別のアプローチとして、各エージェントを Kubernetes のワークロードとして扱うのをやめ、Kubernetes 上に制御プレーン（管理層）を導入する方法があります。Google は「Agent Sandbox」と「Agent Substrate」の発表に合わせて Agent Substrate を紹介しました。これはまさにそのアプローチを採用したものです。また、kagent の Agent Substrate 統合ガイド に記載されている通り、kagent もこの方式をサポートしています。
Agent Sandbox は隔離された実行環境を提供し、Agent Substrate は論理エージェントをワーカー上に配置したり移動させたりする管理を行います。Kubernetes は引き続き Pods、Services、ネットワーク、ストレージ、コンピューティングのリソース管理を担当します。一方、その上位レイヤーでは AI アクターの実行ワーカーへのライフサイクル管理と配置制御が行われます。ここで用いられる抽象化は、プラットフォームエンジニアがすでに慣れ親しんでいる概念に似ています。WorkerPool は NodePool に相当し、Workers は Nodes に対応します。また、ActorTemplate は Pod の宣言的仕様と同様の役割を果たします。
Kubernetes は WorkerPool と ActorTemplate の存在のみを認識しており、Worker や Actor は Agent Substrate が独自に提供する CLI および API で管理されます。各 Worker は単一の Pod にマッピングされています。
Actor は AI エージェントとして振る舞う実体であり、作業が到着した際に Worker 上にスケジューリングされる論理単位です。そのライフサイクルに応じて、停止・再開・削除が行われます。これにより、長寿命の Pod を固定プールとして用意するだけで、各エージェントに専用に常時稼働する Pod を割り当てる場合よりもはるかに多くの論理エージェントをサポートすることが可能になります。つまり、Pod はエージェントのデプロイモデルではなく、実行のためのワーカーとして機能します。
この設計の影響はスケジューリング効率を超えて広がります。Sun 氏は、Actor が任意の Worker で実行可能であるならば、そのアイデンティティは Pod や Service に属するのではなく、ActorTemplate、ネームスペース、テナント、バージョンに紐づくべきだと指摘しています。同様に、アクセス制御、ネットワークポリシー、ランタイム権限もテンプレートレベルで定義し、個別の Actor に対してオーバーライドを適用する必要があるかもしれません。
実行が Pod と 1:1 で対応しないようになると、所有権、クォータ、課金の管理は複雑さを増します。また、観測性（オバザビリティ）も論理エージェントに追従する必要があり、ログ、トレース、監査記録を、Actor がどこでスケジューリングされたかに関わらず関連付ける仕組みが求められます。
これらはいずれも、マイクロサービスや大規模な推論ワークロードにおける業界標準プラットフォームとしての Kubernetes の地位を揺るがすものではありません。焦点となるのはより狭い問いです。実行環境としてその能力を実証した Pod が、AI エージェントのデプロイ単位、アイデンティティ、ライフサイクル管理においても引き続き採用されるべきかどうか。Agent Substrate は kagent を通じてこの問いに挑んでいます。その後、Google の「Kubernetes Podcast」は Sun氏の投稿を週刊ニュースまとめの中で取り上げました。
著者について
マーク・シルベスター
マーク・シルベスター氏は、英国バーミンガムに拠点を置くソフトウェアコンサルティング企業 Griffiths Waite でプラットフォームおよびアーキテクチャマネージャーを務めています。プラットフォーム戦略の責任者として、エンタープライズクライアント向けに革新的なソリューションを提供することに注力しています。関心領域は、クラウドネイティブ技術、DevOps 実践、エンジニアリングやアーキテクチャにおける AI の実用的な応用です。
Show moreShow less
原文を表示
In a CNCF blog post, Lin Sun draws on work in the kagent project to argue that the Pod may be the right execution unit for an agent while no longer being the right deployment, identity, or lifecycle unit.
The questions that surface once agent counts grow are familiar: how to isolate one agent from another, how each gets its own identity, how to enforce access and network policies, how to see what an individual agent is doing, and who owns an agent for multi-tenancy. These are agent platform questions rather than Kubernetes questions, even though Kubernetes is where the answers have to be expressed.
One straightforward approach is to make each agent a first-class Kubernetes workload with its own Pod, Service, and ServiceAccount. This is the approach kagent adopted after initially running many agents inside a single runtime. It provides process and container isolation, a ServiceAccount identity that plugs into existing authentication and authorization, the ability to apply Kubernetes network and admission-policy mechanisms, per-agent attribution of logs, metrics, and traces, and Kubernetes-native scheduling and resource management. kagent subsequently added support for stronger isolation through the Kubernetes Agent Sandbox project.
The difficulty is that agents do not behave like the microservices these abstractions were designed around. Unlike services expected to be continuously available, an agent may wake only when assigned a task, run for seconds or minutes, and then sit idle, making a dedicated Pod per potential agent wasteful. Agents may also spawn subagents to run subtasks in parallel, act on a user's behalf, and pause indefinitely while waiting for human approval. Pods are excellent execution environments, but that does not make them the right lifecycle abstraction for short-lived, bursty work of this shape.
Another approach is to stop treating each agent as a Kubernetes workload and instead introduce a control plane above Kubernetes. Agent Substrate, which Google introduced alongside Agent Sandbox in its Agent Sandbox and Agent Substrate announcement, takes this approach. kagent supports it, as described in kagent's Agent Substrate integration guide.
Agent Sandbox provides an isolated execution environment, while Agent Substrate manages how logical agents are placed onto and moved between workers. Kubernetes continues to manage Pods, Services, networking, storage, and compute, while the layer above manages the lifecycle and placement of AI actors onto execution workers. Its abstractions mirror concepts platform engineers already know: a WorkerPool is analogous to a NodePool, Workers to Nodes, and an ActorTemplate to the declarative specification of a Pod.
Kubernetes is aware only of WorkerPools and ActorTemplates; Workers and Actors live in Agent Substrate's own CLI and API, with each Worker mapped to a single Pod. An Actor, the entity that "acts as" an AI agent, is a logical unit scheduled onto a Worker when work arrives and suspended, resumed, or removed as its lifecycle requires. This allows a fixed pool of long-lived Pods to support far more logical agents than would be practical with a dedicated, continuously running Pod for each one. Pods become the execution workers, not the deployment model for agents.
The consequences reach beyond scheduling efficiency. Sun argues that if an Actor can run on any Worker, identity may belong to the ActorTemplate, namespace, tenant, and version rather than to a Pod or Service. Access control, network policy, and runtime permissions may likewise need to be expressed at the template level with per-Actor overrides. Ownership, quotas, and billing become harder to reason about once execution is no longer one-to-one with Pods, and observability must follow the logical agent, associating logs, traces, and audit records with the Actor wherever it was scheduled.
None of this displaces Kubernetes, which remains the industry standard platform for microservices and inference workloads at scale. The open question is narrower: whether the Pod, having proved itself as an execution environment, should also remain the unit of deployment, identity, and lifecycle for AI agents. That is what Agent Substrate is exploring through kagent. The Kubernetes Podcast from Google subsequently featured Sun's post in its weekly news roundup.
About the Author
Mark Silvester
Mark Silvester is a Platform and Architecture Manager working at Griffiths Waite, a software consultancy based in Birmingham, UK. Responsible for platform strategy, with a focus on delivering innovative solutions for enterprise clients. Areas of interest include cloud-native technologies, DevOps practices, and the practical application of AI in engineering and architecture.
Show moreShow less
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み