嗨大家，我是 Debuguy。

前幾天我們處理了 Grafana 和 Kibana 的警報自動分析，讓 Bot 能自動查 Log、解析錯誤。但說實話，生產環境的問題往往不會只停留在「查個 Log」這麼簡單。

凌晨的連環炮

想像一下這個場景：

📱 凌晨 3:17
🚨 [CRITICAL] Pod CrashLoopBackOff
Production namespace 有 Pod 一直重啟
@debuguy @on-call-team

你爬起來，開始標準流程：

# 第一步：看看是哪個 Pod
kubectl get pods -n production

# 第二步：看詳細資訊
kubectl describe pod problem-pod-xxx -n production

# 第三步：看 Log
kubectl logs problem-pod-xxx -n production --tail=100

# 第四步：看 Events
kubectl get events -n production --sort-by='.lastTimestamp'

每次都要打這麼多指令，而且還要記得各種參數、namespace、資源名稱...

「如果能直接問 Bot：『幫我看看 production 那個一直重啟的 Pod 是怎麼回事』該有多好...」

kubectl-ai 來救援了

什麼是 kubectl-ai？

kubectl-ai 是 Google Cloud Platform 開源的工具，它能：

1. 作為 CLI 工具：讓你用自然語言操作 Kubernetes
2. 作為 MCP Server：讓其他 AI 工具（像我們的 ChatBot）能呼叫 kubectl 功能
3. 而且支援 streamable-http 模式，完美符合我們的架構！

為什麼需要這個？

我們已經有了：

• ✅ Elasticsearch MCP - 查 Log
• ✅ Grafana MCP - 看監控和警報
• ✅ 自定義工具 - 解析 Kibana/Grafana URL

但缺了最後一塊拼圖：Kubernetes 本身的操作。

實戰：把 kubectl-ai 接入架構

kubectl-ai 官方沒有提供現成的 Docker image，但提供了 Dockerfile。我們需要自己 build。

Step 1: Build kubectl-ai Docker Image

先 clone kubectl-ai 專案：

git clone https://github.com/GoogleCloudPlatform/kubectl-ai.git
cd kubectl-ai

官方提供的 Dockerfile 在 images/kubectl-ai/Dockerfile，我們可以直接使用：

docker build -t kubectl-ai:latest -f images/kubectl-ai/Dockerfile .

Step 2: 啟動 MCP Server（以 docker-compose 為範例）

在 docker-compose.yml 中加入 kubectl-ai 服務：

services:
  # ... 其他服務 (genkit-service, slack-service, etc.)
  
  kubectl-ai-mcp:
    image: kubectl-ai:latest
    container_name: kubectl-ai-mcp
    ports:
      - "9080:9080"
    volumes:
      # 掛載 kubeconfig (read-only)
      - ~/.kube:/root/.kube:ro
    command: [
      "--mcp-server",
      "--mcp-server-mode", "streamable-http",
      "--http-port", "9080"
    ]
    restart: unless-stopped

重點說明：

• --mcp-server: 啟動 MCP server 模式
• --mcp-server-mode streamable-http: 使用 streamable-http transport
• --http-port 9080: 設定 HTTP 埠
• MCP endpoint 會在 http://localhost:9080/mcp

「等等，這樣會不會讓 AI 可以任意操作 K8s？」

是的！這是個重要的安全問題。所以給予的權限必須控制在 read only

Step 3: 註冊到 MCP 配置

更新 config/mcp-config.json：

{
  "mcpServers": {
    "elasticsearch": {
      "type": "streamable-http",
      "url": "http://elasticsearch-mcp:8080/mcp"
    },
    "grafana": {
      "type": "streamable-http", 
      "url": "http://grafana-mcp:8000/mcp"
    },
    "kubectl-ai": {
      "type": "streamable-http",
      "url": "http://kubectl-ai-mcp:9080/mcp"
    }
  }
}

Step 4: 測試服務

啟動服務：

docker-compose up -d kubectl-ai-mcp

測試 MCP endpoint：

# 用 MCP Inspector 測試
npx @modelcontextprotocol/inspector

現在可以在 Slack 中測試：

@debuguy_bot 列出 default namespace 的所有 pods

安全性：Read-Only

kubectl-ai 本身沒有內建的 read-only 模式，需透過 Kubernetes RBAC 來限制權限。

kubectl-ai 提供哪些工具？

根據官方文件，kubectl-ai 內建的工具包括：

kubectl 工具

• 所有標準 kubectl 命令

bash 工具

• 可以執行 shell 命令
• 用於複雜的診斷腳本

實際使用場景

場景一：快速診斷 CrashLoopBackOff

@debuguy_bot production namespace 有個 Pod 一直重啟，幫我看看是什麼問題

Bot 會自動：

1. 列出 production namespace 的 Pods
2. 找到 CrashLoopBackOff 的 Pod
3. 查看詳細資訊 (describe)
4. 抓取最近的 Logs
5. 檢查相關的 Events
6. 總結可能的原因

場景二：結合 Grafana 警報

🚨 [CRITICAL] High Memory Usage
production/api-server Pod 記憶體使用率超過 90%

@debuguy_bot 幫我分析這個問題

Bot 會：

1. 從 Grafana 取得 metrics 趨勢
2. 用 kubectl 查看 Pod 的 resource limits
3. 檢查是否有 OOMKilled events
4. 查看最近的 logs 是否有記憶體相關錯誤
5. 給出完整分析和建議

效能和成本考量

API Server 壓力

kubectl-ai 每次操作都會呼叫 K8s API。要注意：

1. 在 System Prompt 提醒 AI：

   - Use specific resource names when possible
   - Avoid broad "get all" commands across all namespaces
   - Prefer targeted queries
   

2. 監控 API calls：用 Langfuse 追蹤工具呼叫頻率

小結：運維自動化的最後拼圖

今天我們成功把 kubectl-ai 整合到 ChatBot 架構中：

技術整合：

• ✅ kubectl-ai MCP Server（streamable-http）
• ✅ RBAC 權限控制（read-only ServiceAccount）

實用價值：

• ✅ 自然語言查詢 K8s 資源
• ✅ 結合監控、Log、K8s 的全方位分析
• ✅ 降低值班工程師的認知負擔
• ✅ 加速問題診斷流程

安全性：

• ✅ RBAC 限制權限
• ✅ ServiceAccount 隔離
• ✅ System Prompt 雙重防護

從查 Log 到查 Metrics 再到查 K8s 資源，Bot 現在真的可以做完整的問題診斷了。

當凌晨警報響起時，Bot 能：

1. 🔍 分析 Grafana 警報細節
2. 📊 查詢 Elasticsearch logs
3. 🎯 檢查 Kubernetes 資源狀態
4. 📝 生成完整的診斷報告

工程師只需要根據報告決定下一步，而不用在半夢半醒中敲一堆指令。

完整的原始碼在這裡，包含 kubectl-ai Dockerfile 和完整配置！

AI 的發展變化很快，目前這個想法以及專案也還在實驗中。但也許透過這個過程大家可以有一些經驗和想法互相交流，歡迎大家追蹤這個系列。

也歡迎追蹤我的 Threads @debuguy.dev