k8s-mcp-server MCP — ユースケース, インストール & ライブデモ

なぜ使うのか

主な機能

Bundled CLIs: kubectl, helm, istioctl, argocd
Piping with jq/grep/sed for structured output
Two safety modes: restrictive (default) and permissive
Runs as non-root in a container — mount kubeconfig read-only
Configurable command timeout via K8S_MCP_TIMEOUT

ライブデモ

実際の動作

k8s.replay ▶ 準備完了

0/0

インストール

クライアントを選択

~/Library/Application Support/Claude/claude_desktop_config.json · Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "k8s": {
      "command": "uvx",
      "args": [
        "k8s-mcp-server"
      ],
      "_inferred": true
    }
  }
}

Claude Desktop → Settings → Developer → Edit Config を開く。保存後、アプリを再起動。

~/.cursor/mcp.json · .cursor/mcp.json

{
  "mcpServers": {
    "k8s": {
      "command": "uvx",
      "args": [
        "k8s-mcp-server"
      ],
      "_inferred": true
    }
  }
}

Cursor は Claude Desktop と同じ mcpServers スキーマを使用。プロジェクト設定はグローバルより優先。

VS Code → Cline → MCP Servers → Edit

{
  "mcpServers": {
    "k8s": {
      "command": "uvx",
      "args": [
        "k8s-mcp-server"
      ],
      "_inferred": true
    }
  }
}

Cline サイドバーの MCP Servers アイコンをクリックし、"Edit Configuration" を選択。

~/.codeium/windsurf/mcp_config.json

{
  "mcpServers": {
    "k8s": {
      "command": "uvx",
      "args": [
        "k8s-mcp-server"
      ],
      "_inferred": true
    }
  }
}

Claude Desktop と同じ形式。Windsurf を再起動して反映。

~/.continue/config.json

{
  "mcpServers": [
    {
      "name": "k8s",
      "command": "uvx",
      "args": [
        "k8s-mcp-server"
      ]
    }
  ]
}

Continue はマップではなくサーバーオブジェクトの配列を使用。

~/.config/zed/settings.json

{
  "context_servers": {
    "k8s": {
      "command": {
        "path": "uvx",
        "args": [
          "k8s-mcp-server"
        ]
      }
    }
  }
}

context_servers に追加。保存時に Zed がホットリロード。

claude mcp add k8s -- uvx k8s-mcp-server

ワンライナー。claude mcp list で確認、claude mcp remove で削除。

ユースケース

実用的な使い方： k8s-mcp-server

Morning cluster health check via chat

👤 SRE, platform engineers ⏱ ~5 min intermediate

使うタイミング： Daily, before stand-up — anything red? Any pods crashlooping?

前提条件

kubeconfig on host — Usually ~/.kube/config

フロー

Start the MCP container

Start k8s-mcp-server via Docker mounting ~/.kube read-only.✓ コピーしました

→ Container up
Run the checks

Across all namespaces, list pods not in Running state, nodes not Ready, and recent (last 1h) events of type Warning.✓ コピーしました

→ Three-part health report
Triage

For each crashlooping pod, get last 50 log lines and propose most likely cause.✓ コピーしました

→ Log excerpts + diagnoses

結果： 5-minute daily cluster pulse check.

注意点

Running kubectl get events cluster-wide floods context — Always filter by time and type

Debug a failed Helm release

👤 Devs shipping Helm charts ⏱ ~15 min intermediate

使うタイミング： helm upgrade failed and you want to know why without copying error messages back and forth.

フロー

Get history

helm history my-app -n production. What changed between v4 (working) and v5 (failed)?✓ コピーしました

→ Version diff
Diff templates

Render the template for v5 with current values and compare against v4. Highlight differences.✓ コピーしました

→ Diff of rendered manifests
Roll back if needed

Roll back to v4. Confirm all pods become Ready.✓ コピーしました

→ Rollback + health check

結果： Fast recovery with understanding, not just luck.

注意点

Rolling back without capturing the failure first means you can't fix forward — Always save helm get all v5 to a file before rolling back

組み合わせ： filesystem

Audit Argo CD apps for drift

👤 GitOps practitioners ⏱ ~20 min advanced

使うタイミング： You suspect someone kubectl'd something into prod that Argo CD doesn't know about.

フロー

List out-of-sync apps

argocd app list --output json. Filter to apps where sync status isn't Synced.✓ コピーしました

→ Out-of-sync list
Diff each

For each drifted app, run argocd app diff and summarize what's different from Git.✓ コピーしました

→ Per-app diff summary

結果： Clear picture of manual drift to reconcile.

組み合わせ

他のMCPと組み合わせて10倍の力を

k8s + github

When an app is broken in cluster, open GitHub issue with pod logs

If any pod in 'payments' namespace is crashlooping, fetch logs and open a GitHub issue with them attached.✓ コピーしました

ツール

このMCPが提供する機能

ツール	入力	呼び出すタイミング	コスト
kubectl	command: str (full kubectl args)	General cluster ops	free
helm	command: str	Release management	free
istioctl	command: str	Service mesh ops	free
argocd	command: str	GitOps ops (requires argocd login in container)	free

コストと制限

運用コスト

APIクォータ: None
呼び出しあたりのトークン: kubectl get -o yaml can be huge; prefer -o json | jq to trim
金額: Free, MIT
ヒント: Always use -o wide or -o jsonpath=... to trim. kubectl get all is a token-bomb.

セキュリティ

権限、シークレット、影響範囲

最小スコープ： Kubeconfig scoped to a least-privilege ServiceAccount

認証情報の保管： Mount ~/.kube read-only into the container

データ送信先： Traffic to your cluster API server only

絶対に付与しない： cluster-admin ServiceAccount to the kubeconfig used by the MCP

Default mode is restrictive — whitelists commands. Permissive mode allows anything. Don't switch to permissive unless you trust the prompt chain.
Always review delete, scale --replicas=0, drain, and apply commands before confirming.

トラブルシューティング

よくあるエラーと対処法

The connection to the server localhost:8080 was refused

kubeconfig not mounted or KUBECONFIG env var wrong in the container.

確認： docker exec ... kubectl config view

Command blocked in restrictive mode

Either craft a narrower command, or explicitly opt into permissive mode for that session.

Timeout on long-running command

Raise K8S_MCP_TIMEOUT. For truly long ops, run async via a Job and poll.

代替案

k8s-mcp-server 他との比較

代替案	代わりに使う場面	トレードオフ
Direct kubectl via ssh-manager	You prefer running kubectl on a jump host	Less structured; no command validation
Kagent / AIOps SaaS MCPs	You want managed service rather than self-hosted	Costs money; less control

その他

リソース

📖 GitHub の公式 README を読む

🐙 オープンな issue を見る

🔍 400以上のMCPサーバーとSkillsを見る