AIエージェントはKubernetesを置き換えない：制御の役割を安全に分担する方法

AIエージェントとKubernetesオペレーターは、制御ループ内で同等の代替手段として扱うべきではない。オペレーターは、実際の状態を監視し、それを望ましい状態と比較したうえで、宣言された結果にシステムが近づくまで、再現可能な形で定義済みのルールを実行するよう設計されている。一方、エージェントは結果が分かっているものの、そこへ至る道筋に調査、情報収集、トレードオフの調整が必要な場合に、より大きな価値を発揮する。

Cloud Native Computing Foundation (CNCF) が後援する本稿は、クラウドネイティブ基盤にエージェントを導入すると、権限の境界を定めることが単なる convention ではなく、設計上の問題になると述べている。最も安全な構成は、エージェントを思考、コンテキスト、提案の担当にとどめ、実行権限はオペレーター、ポリシーエンジン、決定論的システムが保持するというものだ。

思考と実行を分離する運用ループ

このモデルは、監視、診断、提案、承認、整合、そして検証という6段階の実務的な流れを提案する。エージェントは初期段階でリソース、ログ、イベント、メトリクス、ドキュメントを調査できるが、変更の適用、リソースの変更、削除を行う権限を自動的に取得することはない。機密性の低い読み取り操作は自動化できる一方、影響の大きい変更は明示的な承認またはポリシーゲートを通過させる。

kagentプロジェクトは、CNCF Sandbox に属するオープンソースプロジェクトであり、その一例を示している。これはエージェントをKubernetesリソースとして実行し、Kubernetes、Helm、監視ツール、カスタムツールに接続することで、分析と実行の間の障壁を取り除くことなく、問題の調査や専門エージェントの調整を可能にする。

なぜオペレーターを大規模言語モデルで置き換えるべきではないのか

Karpenterのケースは、その違いを明確に示している。Karpenterはスケジューリング制約を扱い、NodePoolsとNodeClaimsのリソースを整合させるオペレーターである。未使用のノード、Spotリソースの変動、スケジューリング待ちのPodが発生した場合、運用エージェントはNodePoolとEC2NodeClassの設定、イベント、ログ、Pod Disruption Budgets、Prometheusのメトリクスを調査して原因を探ることができる。

調査によって、エビクションの無効化ポリシーが統合を妨げている、または障害予算がエビクションを阻んでいる、あるいはconsolidateAfterの値が変動するワークロードにおいて回避可能な揺らぎを引き起こしていることが明らかになる場合がある。しかし、必要な成果物は「NodePoolを改善せよ」のような一般的な提案ではなく、証拠、トレードオフ、影響を受ける可能性のあるノード数、安定性を監視する期間を説明した具体的な設定パッチである。

承認後、Karpenterは自身の既存のスケジューリングおよび障害処理ロジックに従って変更を実行する。その後、エージェントは結果を監視し、Podの待ち時間を増加させたり有害な障害を引き起こしたりすることなく、統合が改善したことを検証する。受け入れ基準を満たさなかった場合は、同じ経路を通じてロールバックを提案できる。

もう一つの例：Argo CDとHelmのアップグレード

Argo CDが管理するHelmチャートのアップグレードでは、Gitでバージョンを変更すること自体は比較的容易だが、実行中のアプリケーションへの影響を評価することはより難しい。エージェントはリリースノート、現在の値、生成されたマニフェストを比較し、例えば、readiness probeの設定に使われる値の新しい名前によって、気付かないままデフォルト値に戻る可能性を検出できる。

この結果は、バージョンと影響を受ける値を更新し、運用上のリスクを説明し、デプロイ前のチェックを指定する、範囲を絞ったマージリクエストに変換すべきである。レビューとマージの後、Argo CDがアプリケーションポリシーに従ってマニフェストを生成し、同期する。同期の成功だけでは、アップグレードの安全性を証明するには不十分である。レイテンシー、エラー率、可用性の指標を確認する必要がある。チェックに失敗した場合、エージェントは変更の取り消しや復旧計画を提案できるが、データやスキーマの変更は完全にはロールバックできない場合があることを考慮しなければならない。

自律性は段階的に獲得する

本稿は、まず読み取りと調査だけを行うエージェントから始め、次にパッチやマージリクエストの作成を許可し、その後、明確なロールバック条件を設けたうえで、低リスクかつ範囲を限定した変更を実行させることを推奨している。アクションが理解可能で測定可能になった場合にのみ、そのアクションを自律化する。

編集部の見解：ここでの本当の変化は、kubectlやHelmを呼び出せるエージェントを追加することではなく、確率的な推論が無制限の実行権限へと変わらないように、制御ループを再設計することにある。このモデルの実務的な価値は、監査可能な委任、限定された範囲、監視、影響を元に戻す能力の存在に左右される。提案から自律性へ移行する速度を決める責任は引き続き人間にあり、本稿も、このアプローチがエラーのリスクをなくすことや、あらゆる状況でロールバックを可能にすることを証明しているわけではない。