意図的に壊したKubernetesクラスターをAIエージェント3種で診断してみた

9月3日、Marmelabが「Can An AI Agent Debug Kubernetes? I Broke A Cluster To Find Out」と題した記事を公開した。この記事では、意図的に壊したKubernetesクラスターに対してAIエージェント3種を試し、診断・修復能力を検証した実験について詳しく紹介されている。

壊れたクラスターを用意する

実験の前提として、筆者はk3dでローカルのk3sクラスターを構築し、Googleが公開するマイクロサービスデモアプリ「Online Boutique」（12サービス構成）をデプロイした。その上で、実運用でよく遭遇する5種類の障害を意図的に注入している。

OOMKilled: メモリ上限20Miに対して250M確保しようとするPod
CrashLoopBackOff: エラーコードで終了し続けるPod
ImagePullBackOff: 存在しないイメージタグを指定したPod
Readiness probe失敗: 404パスを向いたプローブ設定
redis-cartをレプリカ0にスケール: 結果としてショップ全体がHTTP 500を返す状態

この状態に対して、以下の3つのOSSエージェントを順番に投入した。

3つのエージェントの比較

k8sgpt：静的アナライザー＋MCP連携

k8sgptはGo製のCLIで、クラスターに対して決定論的なアナライザーを実行する。同じクラスターなら常に同じ結果を返す設計だ。ポイントは--explainフラグで、アナライザーの出力を元にプロンプトを組み立て、任意のLLMに投げて説明を生成させる。

CLIとして動かすだけなら数コマンドで完結する。ただしLLMへの問い合わせは1回限りで、クラスターをインタラクティブに探索する能力はない。

より強力なのがMCPサーバーとして動かす使い方だ。MCP（Model Context Protocol）とは、LLMアプリケーションが外部ツールやデータソースを統一された方式で呼び出すためのオープンプロトコルで、Anthropicが策定した。claude_desktop_config.jsonに以下を追記するだけでClaude Codeから利用できる。

"args": ["serve", "--mcp"]

この構成では自然言語で質問でき、ログやリソースの膨大な情報の中から必要な情報を絞り込んで答えてくれる。筆者はここで図解まで生成されたと述べている。

なお、k8sgptにはk8sgpt-operatorというクラスター内コントローラーも存在し、アルファ機能としてautoremediation（自動修復）も実装されているが、今回の実験では未検証とのことだ。

kubectl-ai：自律的に探索するエージェント

kubectl-aiはGoogleが開発するCLIで、k8sgptよりエージェント的な動作をする。LLMがツール群を自律的に選択・実行しながらクラスターを探索するループ構造を持つ。

インストールはワンライナーで完結する。

curl -sSL https://raw.githubusercontent.com/GoogleCloudPlatform/kubectl-ai/main/install.sh | bash

実行コマンドの例：

kubectl ai --llm-provider openai --model gpt-4o --quiet \
  "In namespace 'default', the app is crashing. I don't know which pod is at fault. \
  Find the source of this crash and propose a fix. Do not modify anything."

k8sgptのCLI出力と異なり、推論の過程をステップバイステップで示しながら回答する。自然言語で質問できるのも大きな違いだ。筆者はkubectl-aiを「メインツールとして使う」と結論づけている。

kagent：クラスター内に常駐するエージェント群

kagentはアーキテクチャが前の2つとまったく異なる。KubernetesのCRD（カスタムリソース定義）としてエージェントを定義し、クラスター内部にデプロイする構成だ。エージェント同士がA2A（Agent-to-Agent）プロトコルでタスクを委譲し合える。A2AはGoogleが提唱するオープン仕様で、異なるAIエージェント間が標準化されたメッセージ形式で協調動作するためのプロトコルだ。

HelmでCRDと本体をインストールした後、ポートフォワードでWebダッシュボードにアクセスできる。

kubectl -n kagent port-forward svc/kagent-ui 9090:8080

ダッシュボードからエージェントにチャット形式で指示を出すと、推論の各ステップと使用ツールの出力が可視化される。今回の実験ではコードを1行も書かずに全障害を修復できたとのことだ。

ただし、クラスター内にエージェントをインストールしなければならない点が筆者にとってネックになっている。「クライアントも自分も、たとえread-onlyであっても本番クラスターにエージェントを入れたくない」という理由で、個人用クラスターや完全に制御できる環境に限定して使うと述べている。

おまけ：Docker Desktopのエージェント「Gordon」

Kubernetes不要なプロジェクトも多い。そこで筆者はOnline BoutiqueをDocker Compose構成に変換し、同様の障害を注入した上で、Docker Desktopに同梱されているエージェント「Gordon」も試している。GordonはDocker Desktop（Docker Engine単体では不可）があれば追加インストール不要で利用でき、同様に診断・修復の提案を行ったとのことだ。

筆者の結論：使い分けの指針

ツール	特徴	用途
k8sgpt	決定論的分析＋LLM説明	MCPモードでClaude Codeに組み込む
kubectl-ai	自律探索エージェント	日常的な障害調査のメインツール
kagent	クラスター内常駐・A2A連携	個人クラスターや完全制御環境のみ

筆者がまだ試せていないのは、k8sgpt-operatorのautoremediationやkagentのA2A委譲による完全自律修復だ。「エージェントに自分のクラスターを自律で触らせることをどこまで信頼できるか」——これが次の問いになると締めくくっている。

詳細はCan An AI Agent Debug Kubernetes? I Broke A Cluster To Find Outを参照していただきたい。