·

Kubernetes MCP với Cursor

Cài đặt Kubernetes MCP trong Cursor để AI agent có thể kiểm tra và quản lý cluster, pod và deployment ngay trong trình soạn thảo.

Nếu bạn đã quen với việc mở terminal, chạy kubectl get pods, dán output vào ChatGPT để hỏi "pod này lỗi gì", rồi copy câu trả lời quay lại terminal để sửa — thì Kubernetes MCP (Model Context Protocol, giao thức kết nối AI với công cụ bên ngoài) trong Cursor sẽ thay đổi hoàn toàn quy trình đó. Thay vì bạn làm cầu nối thủ công giữa cluster và AI, Cursor Agent mode có thể tự gọi trực tiếp vào Kubernetes MCP server, đọc log, mô tả pod, đối chiếu với code trong workspace, và đề xuất sửa manifest — tất cả trong một cửa sổ chat, không rời IDE.

Bài này mình sẽ đi sâu vào cách cắm Kubernetes MCP server vào Cursor, cách viết prompt để agent correlate (đối chiếu, liên kết) code với hành vi pod thực tế trên cluster, cách dùng agent để sửa manifest và validate lại an toàn, và quan trọng nhất — những giới hạn và guardrail (rào chắn an toàn) bạn phải dựng lên trước khi để một AI agent có quyền động vào cluster production. Đây là kinh nghiệm thực chiến sau khi mình dùng setup này để debug và điều chỉnh nhiều workload trên các cluster staging/production thực tế, không phải lý thuyết suông.

Kết nối Kubernetes MCP vào Cursor Agent mode

Cursor hỗ trợ MCP từ khá sớm, và việc cấu hình MCP server cho Kubernetes thực chất chỉ là khai báo một tiến trình MCP (thường chạy qua npx hoặc binary) trong file config, rồi Cursor sẽ tự spawn tiến trình đó khi Agent mode cần dùng tool.

Bước 1: Chuẩn bị kubeconfig và quyền truy cập

Trước khi đụng vào Cursor, đảm bảo máy bạn đã có kubeconfig (file cấu hình chứa thông tin cluster, credentials, context) hoạt động bình thường:

kubectl config current-context
kubectl get nodes

Nếu hai lệnh trên chạy được, MCP server sẽ dùng đúng context và credentials này — vì hầu hết Kubernetes MCP server hiện nay (ví dụ mcp-server-kubernetes hoặc các server tương tự dựa trên client-go) đọc trực tiếp từ ~/.kube/config hoặc biến môi trường KUBECONFIG, không có lớp xác thực riêng.

Mẹo: Đừng dùng context của cluster production cho context mặc định (current-context) trên máy dev của bạn. Nếu Cursor agent lỡ chạy nhầm lệnh apply/delete, hậu quả sẽ nghiêm trọng hơn nhiều so với chạy nhầm trên staging.

Bước 2: Khai báo MCP server trong .cursor/mcp.json

Cursor đọc cấu hình MCP từ file mcp.json, có thể đặt ở project (.cursor/mcp.json) hoặc global (~/.cursor/mcp.json). Với project Kubernetes, mình khuyên đặt ở cấp project để mỗi repo/mỗi team chỉ trỏ vào đúng cluster liên quan đến project đó.

{
  "mcpServers": {
    "kubernetes": {
      "command": "npx",
      "args": ["-y", "mcp-server-kubernetes"],
      "env": {
        "KUBECONFIG": "/Users/yourname/.kube/config"
      }
    }
  }
}

Nếu bạn dùng nhiều context (dev, staging, prod) và muốn giới hạn agent chỉ thấy một namespace cụ thể, có thể trỏ KUBECONFIG tới một file kubeconfig riêng, đã được scope sẵn bằng RBAC (Role-Based Access Control, kiểm soát quyền theo vai trò) chỉ cho phép đọc/viết trong namespace đó.

Bước 3: Bật MCP server trong Cursor Settings

Sau khi lưu mcp.json, mở Cursor → Settings → MCP, bạn sẽ thấy server kubernetes xuất hiện với trạng thái kết nối. Bật (enable) nó lên, sau đó mở Agent mode (Cmd+I hoặc chat panel với chế độ Agent) — lúc này agent đã có thể "nhìn thấy" các tool do MCP server expose ra, thường gồm: list_pods, get_pod_logs, describe_resource, apply_manifest, list_namespaces, v.v. (tên tool tùy implementation server bạn chọn).

Bạn có thể test nhanh bằng một prompt đơn giản:

Liệt kê tất cả pod đang ở trạng thái CrashLoopBackOff trong namespace "checkout-service".

Nếu agent trả về danh sách pod kèm số lần restart, tool call đã hoạt động đúng.

Mẹo: Sau khi cấu hình xong, luôn thử một lệnh read-only (chỉ đọc) trước, như list_pods hay get_events, để chắc chắn kết nối ổn định trước khi để agent thực hiện bất kỳ lệnh có khả năng thay đổi state của cluster.

Đối chiếu code ứng dụng với hành vi pod thực tế trên Cursor

Đây là phần mình thấy giá trị nhất của Kubernetes MCP trong Cursor: agent có cả context của codebase (vì đang mở trong IDE) và context của cluster runtime (qua MCP), nên nó có thể tự nối hai đầu lại — thứ mà trước đây bạn phải làm bằng tay: đọc log, nhớ dòng code nào throw exception đó, rồi mở file tương ứng.

Ví dụ prompt thực tế

Giả sử service checkout-service đang restart liên tục. Thử prompt sau trong Agent mode, với codebase đã mở trong workspace:

Pod của checkout-service đang bị CrashLoopBackOff. Hãy:
1. Lấy log 100 dòng cuối của pod đó trước lần crash gần nhất.
2. Đối chiếu stack trace hoặc lỗi trong log với source code trong thư mục src/checkout.
3. Chỉ ra dòng code nghi ngờ gây lỗi và giải thích tại sao.
4. Đề xuất hướng fix, nhưng CHƯA sửa code hay apply gì cả.

Agent sẽ gọi tool tương đương get_pod_logs (thường có tham số previous: true để lấy log của container instance trước khi bị restart), sau đó dùng khả năng đọc file trong workspace để grep các exception message, class name, hoặc function name xuất hiện trong log, map ngược về file/dòng code cụ thể.

Một biến thể khác cực hữu ích khi debug config sai:

So sánh các environment variable mà pod "checkout-service-7f9d8" đang thực nhận (describe pod)
với danh sách biến môi trường được đọc trong file src/config/env.ts.
Chỉ ra biến nào bị thiếu hoặc sai tên.

Trường hợp này rất hay gặp: code đọc DATABASE_URL nhưng ConfigMap/Secret lại set DB_URL — nếu tự soi bằng mắt giữa YAML và code TypeScript, dễ bỏ sót. Agent làm việc đối chiếu chuỗi ký tự này nhanh và chính xác hơn con người.

Đối chiếu resource limit với hành vi OOMKilled

Pod "worker-5d7c9" bị OOMKilled. Lấy resource limits hiện tại của container này,
đối chiếu với heap size / memory setting được cấu hình trong Dockerfile hoặc file khởi động của app (ví dụ NODE_OPTIONS, -Xmx).
Giải thích liệu limit trên Kubernetes có đang thấp hơn mức app cần không.

Mẹo: Luôn yêu cầu agent trích dẫn nguồn cụ thể (tên file, số dòng, tên field trong manifest) khi đưa ra kết luận. Nếu agent chỉ nói "có thể do memory limit thấp" mà không chỉ ra field resources.limits.memory cụ thể lấy từ đâu, khả năng cao nó đang suy đoán chứ không thực sự đọc dữ liệu — bạn nên yêu cầu nó gọi lại tool để lấy số liệu thật.

Sửa manifest và validate lại với cluster thật

Sau khi xác định được nguyên nhân, bước tiếp theo là sửa manifest (Deployment, ConfigMap, HPA...) và kiểm tra trước khi áp dụng thật. Đây là chỗ mình luôn nhấn agent phải theo đúng trình tự: sửa file local → dry-run → diff → apply, không bỏ bước nào.

Bước 1: Yêu cầu agent sửa file manifest local trước

Trong file k8s/checkout-service/deployment.yaml, tăng memory limit từ 256Mi lên 512Mi
và memory request từ 128Mi lên 256Mi. Không apply gì cả, chỉ sửa file.

Agent dùng edit tool bình thường của Cursor (không qua MCP) để sửa file YAML trong workspace — bước này an toàn 100% vì chưa đụng gì tới cluster.

Bước 2: Dry-run để kiểm tra manifest hợp lệ

Chạy kubectl apply --dry-run=client -f k8s/checkout-service/deployment.yaml
để kiểm tra manifest có hợp lệ về cú pháp không.

--dry-run=client chỉ validate cú pháp và schema phía client, không gọi API server thật để tính toán ảnh hưởng — nhanh nhưng chỉ bắt được lỗi cấu trúc YAML/field sai tên.

Muốn kiểm tra sâu hơn, dùng --dry-run=server:

Chạy kubectl apply --dry-run=server -f k8s/checkout-service/deployment.yaml
để kiểm tra manifest có được API server chấp nhận không (admission webhook, validation rules...).

--dry-run=server gửi request tới API server thật, chạy qua toàn bộ admission controller (bộ kiểm soát truy cập, ví dụ policy engine như OPA/Kyverno) nhưng không persist thay đổi — bắt được lỗi mà dry-run=client không thấy được, ví dụ vi phạm policy nội bộ về resource quota.

Bước 3: Diff với state hiện tại trên cluster

Chạy kubectl diff -f k8s/checkout-service/deployment.yaml
và giải thích rõ những field nào sẽ thay đổi so với state hiện tại trên cluster.

kubectl diff là bước mình coi là bắt buộc trước mọi apply — nó cho thấy chính xác field nào thay đổi, tránh trường hợp file local đã "trôi" (drift) so với cluster do ai đó từng kubectl edit trực tiếp mà quên đồng bộ lại Git.

Bước 4: Chỉ apply sau khi bạn (con người) xác nhận

Diff trông ổn. Bây giờ hãy apply file này vào cluster.

Đến bước này agent mới thực sự gọi tool apply_manifest (hoặc tương đương) qua MCP để tác động lên cluster thật.

Mẹo: Tạo một custom instruction (rule) trong Cursor — ví dụ file .cursor/rules/k8s-safety.md — quy định agent PHẢI chạy dry-run và diff trước, và PHẢI dừng lại chờ xác nhận rõ ràng bằng lời trước khi gọi bất kỳ tool nào có khả năng apply/delete/scale. Đừng chỉ dặn trong một prompt đơn lẻ — rule ở cấp project sẽ áp dụng cho mọi phiên chat sau này.

Hạn chế và guardrail an toàn khi dùng Kubernetes MCP trong Cursor

Đây là phần quan trọng nhất, và cũng là phần dễ bị bỏ qua nhất khi mọi thứ "chạy được" quá nhanh và quá mượt. Cho một AI agent quyền gọi trực tiếp vào Kubernetes API từ trong IDE là một thay đổi lớn về bề mặt rủi ro (risk surface), không phải chỉ là thêm một tiện ích.

Giới hạn về RBAC — đừng bao giờ dùng service account admin

Kubernetes MCP server dùng đúng quyền của kubeconfig mà nó được cấp — nếu kubeconfig đó gắn với cluster-admin, agent (và bất kỳ prompt injection nào lỡ xảy ra qua log hoặc comment độc hại trong manifest) có quyền làm bất cứ điều gì trên toàn cluster. Nên tạo một ServiceAccount riêng cho mục đích này, với Role/RoleBinding giới hạn namespace và verb cụ thể:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: mcp-agent-role
  namespace: checkout-service
rules:
  - apiGroups: ["", "apps"]
    resources: ["pods", "pods/log", "deployments", "configmaps", "events"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["patch", "update"]

Với setup này, agent có thể đọc mọi thứ và sửa deployment, nhưng không thể xóa namespace, không thể động vào Secret, không thể đụng tới node.

Giới hạn về context window và độ chính xác của log

Log Kubernetes có thể rất dài, và context window (giới hạn lượng văn bản mô hình xử lý một lần) của LLM là có hạn. Khi agent chỉ lấy 100-200 dòng log cuối, nó có thể bỏ lỡ nguyên nhân gốc xảy ra sớm hơn trong log. Mình từng gặp trường hợp agent kết luận sai vì stack trace thật nằm ở dòng 300 nhưng chỉ fetch 100 dòng cuối — luôn double-check bằng cách yêu cầu agent nói rõ nó đã lấy bao nhiêu dòng log và từ thời điểm nào.

Rủi ro khi tool call chạy "âm thầm"

Một số Kubernetes MCP server implementation cho phép agent gọi liên tiếp nhiều tool trong một lượt trả lời (agentic tool calling — mô hình tự quyết định gọi tool nhiều lần liên tiếp) mà không cần xác nhận giữa các bước. Nếu bạn không cấu hình rule chặn, agent có thể tự apply thay đổi mà bạn chưa kịp đọc diff. Cursor cho phép cấu hình mức độ "auto-run" cho tool call — với MCP Kubernetes, mình luôn để ở mode yêu cầu xác nhận thủ công (manual approval) cho mọi tool có verb write (patch/update/delete/apply), chỉ auto-run cho tool chỉ đọc (get/list/watch).

Không có audit trail tự động gắn với người thật

Khi agent gọi Kubernetes API bằng ServiceAccount chung, log audit của cluster sẽ ghi nhận hành động đó dưới tên ServiceAccount, không phải tên bạn — gây khó khăn khi cần truy vết "ai đã sửa gì". Nên bật thêm logging ở tầng Cursor/MCP (một số server có tùy chọn ghi log mọi tool call ra file local) để đối chiếu song song với audit log của cluster khi cần điều tra sự cố.

MCP server có thể là điểm yếu bảo mật mới

MCP server chạy như một tiến trình local có quyền truy cập kubeconfig của bạn. Nếu bạn cài một MCP server từ nguồn không rõ ràng (npm package lạ, fork không kiểm chứng), bạn đang trao credential cluster cho code của người khác. Luôn kiểm tra nguồn gốc package, pin version cụ thể trong mcp.json (đừng dùng @latest), và ưu tiên server có mã nguồn mở, được audit bởi cộng đồng.

Mẹo: Với cluster production, đừng cho Cursor Agent mode quyền apply trực tiếp. Cách an toàn hơn là để agent chỉ đọc (read-only RBAC) và sinh ra Pull Request sửa manifest trong Git repo — pipeline CI/CD (GitOps qua ArgoCD/Flux) sẽ là bên thực sự apply lên cluster, sau khi con người review PR. AI hỗ trợ tư duy và viết code, con người và pipeline đã được kiểm soát mới là bên thực thi.

Tips

Một vài kinh nghiệm tổng hợp sau nhiều lần dùng Kubernetes MCP với Cursor trong công việc thực tế, đáng ghi nhớ khi bạn tự setup:

  • Luôn tách riêng MCP config cho từng cluster/môi trường bằng cách dùng nhiều file kubeconfig, đừng dựa vào việc nhớ đổi kubectl config use-context bằng tay trước khi mở Cursor — dễ quên và dễ apply nhầm môi trường.
  • Viết rule cố định trong .cursor/rules/ yêu cầu agent luôn hiển thị diff và chờ xác nhận trước khi apply — coi đây là quy tắc bắt buộc cho toàn team, không phải tùy chọn cá nhân.
  • Định kỳ review danh sách tool mà MCP server expose ra (thường xem được qua Settings → MCP → tên server → danh sách tools), vì một số bản update server có thể thêm tool mới có quyền rộng hơn bạn tưởng, ví dụ tool xóa namespace.
  • Khi debug production, ưu tiên dùng kubeconfig read-only, chỉ đổi sang kubeconfig có quyền write khi thực sự cần fix và đã có sự đồng thuận từ team — đừng để mặc định context có quyền viết production 24/7 trên máy dev.
  • Kết hợp Kubernetes MCP với MCP khác trong cùng phiên chat (ví dụ MCP cho GitHub) để agent có thể tự tạo branch, sửa manifest, mở PR — giữ nguyên nguyên tắc "AI đề xuất, human + CI/CD quyết định" xuyên suốt toàn bộ quy trình.

Mẹo: Ghi lại một vài prompt "chuẩn" đã dùng thành công (như các ví dụ đối chiếu log-code, đối chiếu resource limit ở trên) vào một file PROMPTS.md trong repo, để cả team dùng lại pattern prompt đã được kiểm chứng, thay vì mỗi người tự mò cách hỏi agent mỗi lần gặp sự cố.

Tiếp Quy trình Thực tế: Phân loại Sự cố & Rollback