/ 目錄 / 演練場 / kubectl-mcp-server
● 社群 rohitg00 ⚡ 即開即用

kubectl-mcp-server

作者 rohitg00 · rohitg00/kubectl-mcp-server

透过自然语言操作 Kubernetes — Pod、Deployment、Helm、GitOps、成本优化。253 个工具,收录于 CNCF Landscape。

kubectl-mcp-server (rohitg00) 在 kubectl、Helm、Flux/ArgoCD、Cert-Manager、Velero、KEDA 和 Istio 上提供了 253 个工具的完整功能集。遵循你的标准 KUBECONFIG;通过 context 参数支持多集群。为多租户部署提供可选的 OAuth 2.1。

為什麼要用

核心特性

即時演示

實際使用效果

kubectl.replay ▶ 就緒
0/0

安裝

選擇你的客戶端

~/Library/Application Support/Claude/claude_desktop_config.json  · Windows: %APPDATA%\Claude\claude_desktop_config.json
{
  "mcpServers": {
    "kubectl": {
      "command": "uvx",
      "args": [
        "kubectl-mcp-server"
      ],
      "_inferred": true
    }
  }
}

開啟 Claude Desktop → Settings → Developer → Edit Config。儲存後重啟應用。

~/.cursor/mcp.json · .cursor/mcp.json
{
  "mcpServers": {
    "kubectl": {
      "command": "uvx",
      "args": [
        "kubectl-mcp-server"
      ],
      "_inferred": true
    }
  }
}

Cursor 使用與 Claude Desktop 相同的 mcpServers 格式。專案級設定優先於全域。

VS Code → Cline → MCP Servers → Edit
{
  "mcpServers": {
    "kubectl": {
      "command": "uvx",
      "args": [
        "kubectl-mcp-server"
      ],
      "_inferred": true
    }
  }
}

點擊 Cline 側欄中的 MCP Servers 圖示,然後選 "Edit Configuration"。

~/.codeium/windsurf/mcp_config.json
{
  "mcpServers": {
    "kubectl": {
      "command": "uvx",
      "args": [
        "kubectl-mcp-server"
      ],
      "_inferred": true
    }
  }
}

格式與 Claude Desktop 相同。重啟 Windsurf 生效。

~/.continue/config.json
{
  "mcpServers": [
    {
      "name": "kubectl",
      "command": "uvx",
      "args": [
        "kubectl-mcp-server"
      ]
    }
  ]
}

Continue 使用伺服器物件陣列,而非映射。

~/.config/zed/settings.json
{
  "context_servers": {
    "kubectl": {
      "command": {
        "path": "uvx",
        "args": [
          "kubectl-mcp-server"
        ]
      }
    }
  }
}

加入 context_servers。Zed 儲存後熱重載。

claude mcp add kubectl -- uvx kubectl-mcp-server

一行命令搞定。用 claude mcp list 驗證,claude mcp remove 移除。

使用場景

實戰用法: kubectl-mcp-server

60 秒内诊断 CrashLoopBackOff Pod

👤 值班 SRE ⏱ ~10 min intermediate

何時使用: 告警触发时;在手动深入 kubectl 之前,你想看日志、事件和资源使用情况。

前置條件
  • kubectl 已配置集群访问权限 — kubectl config get-contexts 应该列出你的集群
步驟
  1. 识别崩溃的 Pod
    列出命名空间 X 中重启次数 > 5 的 Pod。显示 Pod 名称、容器和上次退出原因。✓ 已複製
    → 过滤后的列表
  2. 拉取日志和事件
    对于 Pod Y,获取最后 100 行日志和相关事件。突出显示任何错误关键字。✓ 已複製
    → 可能的根本原因
  3. 检查资源压力
    显示 Pod 的 CPU/内存限制与实际值的对比。是否被 OOM 杀死?✓ 已複製
    → 资源诊断结果

結果: 一分钟内得出有针对性的假设,而不是运行十个 kubectl 命令。

注意事項
  • 错误的集群 context — 总是在你的提示中指定 --context;默认值可能会在生产/测试环境中害你。
搭配使用: prometheus

找到过度配置的工作负载以降低集群费用

👤 FinOps、平台工程师 ⏱ ~40 min advanced

何時使用: 季度成本审查时 — 你想要基于数据的缩减候选。

步驟
  1. 运行成本分析
    使用成本优化工具找到过去 30 天中请求/限制是实际值 3 倍的 Deployment。✓ 已複製
    → 过度配置工作负载的排序列表
  2. 估计节省
    对前 10 个,估计如果调整到合适大小每月节省的 $。按团队分组。✓ 已複製
    → 按团队分组的节省表
  3. 提交带有建议清单的 PR
    为前 5 个生成更新的清单,并在相应的 repo 中提交 PR。✓ 已複製
    → 已打开的包含建议差异的 PR

結果: 有可见成本收益,由指标支持,通过 PR 跟进。

搭配使用: github · prometheus

使用 Claude 安全地升级 Helm release

👤 平台工程师 ⏱ ~20 min advanced

何時使用: 常规 Helm 升级不应该需要 20 分钟的繁琐步骤。

步驟
  1. 比较新旧版本
    对于 release X,显示 values.yaml 与新图表版本之间的差异。✓ 已複製
    → 值/模板差异
  2. 空运行
    使用新图表运行 helm upgrade --dry-run。报告任何渲染模板问题。✓ 已複製
    → 成功的空运行或可操作的错误
  3. 升级并准备回滚
    应用升级。之后立即验证部署状态,并准备好前一个版本以便回滚。✓ 已複製
    → 成功部署,带有回滚说明

結果: 低风险 Helm 操作,从一开始就明确回滚路径。

审计 RBAC 是否存在权限过多的角色

👤 安全工程师 ⏱ ~30 min advanced

何時使用: 认证前或发现可疑角色后。

步驟
  1. 列出通配符角色
    找到资源或动词中包含 '*' 的 ClusterRole 或 Role。按命名空间分组。✓ 已複製
    → 通配符 RBAC 列表
  2. 映射到主体
    对于每一个,谁与它绑定?列出 ServiceAccount/用户/组。✓ 已複製
    → 主体-角色矩阵
  3. 建议最小替换
    对于风险最大的 5 个,根据实际使用情况(审计日志)建议最小所需的动词。✓ 已複製
    → 具体的权限紧化建议

結果: 紧化的 RBAC,有明确的差异理由。

組合

與其他 MCP 搭配,撬動十倍槓桿

kubectl + prometheus

将 Pod 状态与 Prometheus 指标交叉引用

对于 Pod X,显示 kubectl describe 输出,以及来自 Prometheus 的最近 24 小时 CPU/内存。✓ 已複製
kubectl + github

RBAC 审计 → PR 以紧化 YAML 清单

对于 RBAC 审计中的每个发现,针对 infra repo 打开一个 PR,其中包含最小化的 Role YAML。✓ 已複製

工具

此 MCP 暴露的能力

工具輸入參數何時呼叫成本
kubectl_get resource, namespace?, label_selector? 列出任何内容 1 次 API 调用
kubectl_describe resource, name, namespace? 单个对象的深层详情 1 次 API 调用
pod_logs pod, container?, tail?, namespace? 调试 1 次 API 调用
pod_events pod, namespace? 这是为什么发生的? 1 次 API 调用
helm_list namespace? 查看 Helm release 概览 helm 命令
helm_upgrade release, chart, values?, dry_run? 部署 helm 命令
cost_optimize namespace?, period? FinOps 扫描 指标 API
rbac_audit 安全审查 多次 API 调用

成本與限制

運行它的成本

API 配額
受你的集群 API 服务器容量限制
每次呼叫 Token 數
kubectl 输出可能很大 — 特别是 describe/get-wide
費用
免费 MCP;集群成本是你的
提示
优先使用 label_selector 和 field selector 而不是列出所有内容;避免在提示中使用 --output=wide

安全

權限、密鑰、影響範圍

最小權限: 集群只读,除非你需要写权限
憑證儲存: 标准 KUBECONFIG;MCP 不单独存储凭证
資料出站: 仅��你的 Kubernetes API 服务器
切勿授予: 除非绝对必要,否则不要向 MCP context 授予 cluster-admin 权限

故障排查

常見錯誤與修復

未授权/禁止

KUBECONFIG context 缺少权限。检查 kubectl auth can-i 以了解特定的动词/资源

驗證: kubectl auth can-i get pods --namespace X
集群之间的 context 混淆

始终显式设置或传递 --context;在生产中 context 错误会很糟糕

驗證: kubectl config current-context
Helm 升级中途失败

使用 helm rollback <release> <prev-rev>;升级前始终捕获前一个版本

替代方案

kubectl-mcp-server 對比其他方案

替代方案何時用它替代權衡
k8s-mcp-server(官方式,较小)你只需要基本的 kubectl,担心 253 个工具的表面噪声更少的生态系统工具(没有 Helm/Flux)
在 shell 中直接使用 kubectl你已经在终端会话中工作无代理循环

更多

資源

📖 閱讀 GitHub 上的官方 README

🐙 查看未解決的 issue

🔍 瀏覽全部 400+ MCP 伺服器和 Skills