·

Kubernetes MCP Là Gì?

Tìm hiểu Kubernetes MCP là gì và cách nó giúp AI agent kiểm tra và quản lý cluster, pod và deployment.

Nếu bạn đã từng ngồi debug một pod (đơn vị chạy container nhỏ nhất trong Kubernetes) bị CrashLoopBackOff lúc 11 giờ đêm, bạn sẽ hiểu ngay giá trị của việc có một AI agent (tác nhân AI) biết cách tự chạy kubectl describe, đọc log, và tổng hợp nguyên nhân gốc rễ trong vài giây thay vì bạn phải gõ hàng chục lệnh. Đó chính xác là những gì Kubernetes MCP mang lại.

MCP (Model Context Protocol) là giao thức mở do Anthropic công bố, cho phép LLM (large language model) gọi vào các "tool" (công cụ) bên ngoài theo một chuẩn thống nhất, thay vì mỗi hệ thống phải viết integration riêng lẻ. Kubernetes MCP, hiểu đơn giản, là một MCP server đóng vai trò cầu nối giữa AI agent và cluster Kubernetes của bạn — nó expose các thao tác như list pod, xem log, mô tả deployment, apply manifest... dưới dạng tool calling (gọi công cụ) mà AI agent có thể sử dụng trong quá trình suy luận.

Về bản chất, Kubernetes MCP server không phát minh ra năng lực mới — nó bọc lại các API call mà kubectl vẫn dùng (thông qua client-go hoặc gọi trực tiếp Kubernetes API server), rồi expose theo schema mà MCP client (ví dụ Claude Desktop, Claude Code, hoặc agent tự viết) hiểu được. Điểm khác biệt là AI agent giờ có thể tự quyết định: "tôi cần xem log của pod nào, ở namespace nào, filter theo container nào" — dựa trên ngữ cảnh cuộc trò chuyện, không cần bạn gõ lệnh tay.

Với kỹ sư mid-level/senior, giá trị thực tế nằm ở ba nhóm use case chính:

  • Triage nhanh incident: hỏi agent "vì sao service payment-api đang trả 503", agent tự list pod, check event, đọc log, và trả về root cause kèm bằng chứng cụ thể.
  • Onboarding/khảo sát cluster: kỹ sư mới join team có thể hỏi "namespace staging đang chạy những service nào, resource limit ra sao" mà không cần nhớ hết cú pháp kubectl.
  • Tự động hóa vận hành có kiểm soát: agent đề xuất hoặc thực thi các thay đổi nhỏ (scale replica, restart deployment) trong phạm vi quyền được cấp rõ ràng.

Bài này sẽ đi từ tool nào Kubernetes MCP cung cấp, cách setup kubeconfig/context/namespace, ranh giới giữa việc AI chỉ đọc và AI được sửa, cho tới cách thiết kế RBAC (Role-Based Access Control — kiểm soát truy cập theo vai trò) least-privilege để AI agent không trở thành điểm rủi ro trên production.

Core Kubernetes MCP Tools: Pod, Deployment, Service, Event, và Log

Phần lớn Kubernetes MCP server phổ biến hiện nay (ví dụ mcp-server-kubernetes của Flux159, hoặc các implementation tương tự dựa trên client-go) đều xoay quanh một bộ tool lõi tương ứng với các resource type quan trọng nhất trong vận hành hằng ngày.

Pod là đơn vị nhỏ nhất, đại diện cho một hoặc nhiều container đang chạy. Tool thường có dạng kubectl_get (hoặc list_pods), describe_pod, và get_pod_logs. Đây là bộ ba mà AI agent dùng nhiều nhất vì hầu hết sự cố đều bắt đầu từ việc "pod có chạy không, tại sao restart, log nói gì".

Deployment quản lý ReplicaSet và version rollout. Tool tương ứng cho phép agent xem spec.replicas, status.availableReplicas, revision history — rất hữu ích khi cần trả lời "deployment này đang rollout dở hay đã hoàn tất".

Service map traffic tới pod qua label selector. Khi agent được hỏi "vì sao request không tới được pod", nó cần đọc Service để kiểm tra selector có khớp label của pod không — một lỗi cấu hình cực kỳ phổ biến trong thực tế mà kỹ sư mới thường bỏ qua.

Event là nguồn thông tin bị đánh giá thấp nhất nhưng lại chứa manh mối chẩn đoán tốt nhất: FailedScheduling, BackOff, Unhealthy... Một AI agent giỏi triage luôn gọi get_events trước khi đọc log, vì event cho biết Kubernetes control plane đang "nghĩ gì" về resource đó.

Log thì khỏi phải nói — nhưng điểm cần lưu ý là hầu hết Kubernetes MCP server hỗ trợ tham số tailLines, previous (log của lần restart trước), và container (khi pod có nhiều container). Prompt thực tế bạn có thể gửi cho agent:

Pod "checkout-service-7d9f6b8c9-xk2lp" trong namespace "production"
đang restart liên tục. Hãy describe pod này, lấy 100 dòng log gần nhất
(bao gồm log của lần crash trước — previous container), và cho tôi biết
nguyên nhân khả năng cao nhất.

Cấu hình MCP client để agent có quyền truy cập các tool này thường trông như sau (ví dụ với Claude Desktop, file claude_desktop_config.json):

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

Mẹo: Khi mới làm quen, hãy yêu cầu agent liệt kê chính xác tool nào nó có quyền gọi (list tools available) trước khi giao việc thật. Nhiều MCP server chỉ enable một tập con tool theo mặc định (thường là read-only), và biết trước ranh giới này giúp bạn viết prompt sát với năng lực thực tế thay vì đoán mò.

Setup Kubernetes MCP: Kubeconfig, Context, Namespace, và Phạm Vi RBAC

Kubernetes MCP server không tự có quyền gì cả — nó thừa hưởng đúng quyền của identity (danh tính) được cấu hình trong kubeconfig mà nó đang dùng để kết nối cluster. Đây là điểm nhiều người mới dùng MCP hiểu sai: họ nghĩ MCP server có một cơ chế bảo mật riêng, nhưng thực chất nó chỉ là một client gọi Kubernetes API — an toàn hay không phụ thuộc 100% vào kubeconfig và RBAC phía sau.

Bước đầu tiên là xác định kubeconfig nào MCP server sẽ dùng. Kiểm tra context hiện tại:

kubectl config current-context
kubectl config get-contexts

Nếu máy bạn có nhiều cluster (dev, staging, production), đừng bao giờ để MCP server dùng context ngầm định trỏ tới production trong lúc bạn đang test. Cách an toàn là tạo một kubeconfig riêng, tối giản, chỉ chứa context cần thiết:

kubectl config view --minify --context=staging-cluster --flatten > ~/.kube/mcp-staging-config

Sau đó chỉ định rõ file này trong config MCP server, thay vì để nó fallback về ~/.kube/config mặc định:

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

Về namespace, nhiều Kubernetes MCP server hỗ trợ biến môi trường hoặc tham số để giới hạn namespace mặc định (ví dụ K8S_NAMESPACE=staging), nhưng đừng nhầm đây là cơ chế bảo mật — nó chỉ là default gợi ý cho tool call, agent vẫn có thể gọi tool với namespace khác nếu credential cho phép. Giới hạn thật sự phải nằm ở RBAC (sẽ nói kỹ ở mục sau), không phải ở tầng application config.

Một pattern mình khuyên dùng trong team thực tế: tạo ServiceAccount riêng cho AI agent, không tái sử dụng ServiceAccount hay user account của kỹ sư:

kubectl create serviceaccount ai-agent-readonly -n mcp-system
kubectl create token ai-agent-readonly -n mcp-system --duration=8h

Token này sinh ra có thời hạn (8 giờ ở ví dụ trên), giúp giảm rủi ro nếu credential bị lộ trong log hay session của agent. Đưa token này vào kubeconfig riêng cho MCP thay vì dùng chứng chỉ admin cá nhân.

Mẹo: Đặt tên context/kubeconfig có prefix rõ ràng như mcp- hoặc ai-agent- để khi bạn (hoặc đồng nghiệp) nhìn vào danh sách context, biết ngay đâu là kênh dành cho AI agent — tránh nhầm lẫn khi debug hoặc audit sau này.

AI Có Thể Tự Động Hóa Gì: Triage Read-Only So Với Thao Tác Mutating

Ranh giới quan trọng nhất khi triển khai Kubernetes MCP là phân biệt rõ hai nhóm tool: read-only (chỉ đọc — get, list, describe, logs) và mutating (có thay đổi state — apply, delete, scale, restart, exec). Về mặt kỹ thuật, MCP không tự ép AI agent tuân theo ranh giới này — bạn phải thiết kế nó bằng RBAC và bằng cách chọn tool nào để expose.

Nhóm read-only là nơi AI agent tạo giá trị rõ ràng nhất mà rủi ro thấp nhất:

  • Chẩn đoán sự cố: describe pod, đọc event, đọc log, so sánh resource request/limit với usage thực tế.
  • Audit cấu hình: rà soát Deployment có thiếu readinessProbe, Service có selector không khớp label, ConfigMap có key bị deprecated.
  • Trả lời câu hỏi vận hành: "namespace nào đang có nhiều pod Pending nhất", "deployment nào chưa rollout restart sau khi image mới được push".

Ví dụ prompt triage thực tế, kết hợp nhiều tool trong một yêu cầu:

Trong namespace "production", hãy:
1. List tất cả pod không ở trạng thái Running
2. Với mỗi pod đó, lấy event gần nhất
3. Tổng hợp thành bảng: tên pod, trạng thái, nguyên nhân theo event,
   và đề xuất bước xử lý tiếp theo (nhưng KHÔNG thực hiện bất kỳ
   thay đổi nào, chỉ báo cáo)

Câu "KHÔNG thực hiện bất kỳ thay đổi nào" trong prompt là một lớp phòng vệ bổ sung tốt, nhưng đừng coi đó là biện pháp bảo mật chính — nó chỉ là hướng dẫn hành vi cho LLM, mô hình vẫn có thể "quên" nếu tool mutating có sẵn trong context. Biện pháp chính vẫn phải là không cấp quyền mutating ở tầng RBAC/ServiceAccount cho các use case triage.

Nhóm mutating (scale deployment, rollout restart, delete pod, kubectl exec) là nơi cần cực kỳ cẩn trọng. Rủi ro không nằm ở việc AI "cố ý" phá hoại, mà ở hallucination (mô hình bịa thông tin) hoặc hiểu sai ngữ cảnh — ví dụ agent đọc nhầm tên pod tương tự giữa staging và production rồi chạy delete pod nhầm namespace. Với các thao tác này, khuyến nghị thực chiến là:

  • Chỉ cho phép ở namespace non-production, hoặc
  • Yêu cầu agent generate ra command/manifest để con người review và tự tay chạy kubectl apply -f (pattern "propose, human approve, execute"), hoặc
  • Nếu cho thực thi tự động, bắt buộc phải có dry-run trước (kubectl apply --dry-run=server) và log đầy đủ mọi tool call.

Mẹo: Thiết kế hai MCP server config riêng biệt — một chỉ có tool read-only cho các câu hỏi hằng ngày, một có thêm tool mutating chỉ dùng khi bạn chủ động bật lên cho một task cụ thể. Đừng để một config "full quyền" chạy thường trực trong Claude Desktop hay IDE của bạn.

Least-Privilege RBAC Cho AI Agent Chạm Vào Production Cluster

Đây là phần mà nhiều bài hướng dẫn Kubernetes MCP trên mạng bỏ qua hoặc chỉ nói sơ sài, nhưng theo kinh nghiệm triển khai thực tế, đây lại là phần quyết định việc bạn có nên cho AI agent chạm vào production hay không.

Nguyên tắc least-privilege (đặc quyền tối thiểu) áp dụng cho AI agent giống hoàn toàn nguyên tắc áp dụng cho CI/CD pipeline hay service account của ứng dụng: cấp đúng — và chỉ đúng — những verb/resource cần thiết, không hơn.

Bắt đầu bằng một ClusterRole read-only, giới hạn ở các resource cần cho triage:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: ai-agent-readonly
rules:
  - apiGroups: [""]
    resources: ["pods", "pods/log", "events", "services", "configmaps"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["apps"]
    resources: ["deployments", "replicasets"]
    verbs: ["get", "list", "watch"]

Lưu ý mình cố tình loại secrets khỏi danh sách resource — kể cả với verb get/list. Đây là lỗi RBAC phổ biến nhất khi setup AI agent: nhiều người copy ClusterRole view built-in của Kubernetes (vốn cho phép đọc hầu hết resource, bao gồm metadata của Secret) mà không nhận ra AI agent có thể vô tình "đọc" nội dung nhạy cảm qua log hoặc qua việc describe resource tham chiếu Secret. Luôn tự viết Role tối giản, không dùng ClusterRole built-in quá rộng.

Nếu bạn cần agent hỗ trợ scale hoặc restart trong namespace staging, tách riêng một RoleBinding có scope namespace, không phải ClusterRoleBinding toàn cluster:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: ai-agent-operator
  namespace: staging
rules:
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "patch"]
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "delete"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: ai-agent-operator-binding
  namespace: staging
subjects:
  - kind: ServiceAccount
    name: ai-agent-operator
    namespace: mcp-system
roleRef:
  kind: Role
  name: ai-agent-operator
  apiGroup: rbac.authorization.k8s.io

Verb patch (thay vì update) cho deployment là lựa chọn có chủ đích: nó đủ để agent thực hiện kubectl scale hoặc kubectl set image, nhưng field manager và audit trail vẫn ghi rõ ai/cái gì đã patch, dễ trace hơn khi review sau incident.

Với production, khuyến nghị cá nhân sau khi triển khai nhiều hệ thống tương tự: không cấp verb mutating nào cho AI agent trên production namespace ở giai đoạn đầu. Chạy read-only ClusterRole ít nhất vài tháng, xem log audit của Kubernetes API server (--audit-log-path) để hiểu chính xác pattern gọi tool của agent, rồi mới xem xét mở rộng có kiểm soát, từng resource một.

Mẹo: Bật Kubernetes audit log và lọc riêng theo username của ServiceAccount dùng cho AI agent (ví dụ system:serviceaccount:mcp-system:ai-agent-readonly). Đây là cách rẻ nhất để phát hiện agent đang gọi tool bất thường — như liên tục list secrets dù bạn không cấp quyền — trước khi nó trở thành sự cố bảo mật thật.

Mẹo Thực Chiến Khi Triển Khai Kubernetes MCP

Tổng hợp lại một vài kinh nghiệm nên nhớ khi bạn bắt đầu đưa Kubernetes MCP vào workflow thật, không chỉ dừng ở demo:

  • Luôn test trên cluster không quan trọng trước. Dựng một cluster local bằng kind hoặc minikube, chạy vài workload giả, và thử toàn bộ tool set trước khi trỏ MCP server vào bất kỳ cluster có dữ liệu thật.
  • Version pin MCP server. Các MCP server cho Kubernetes vẫn đang phát triển nhanh, tool schema có thể đổi giữa version. Pin version cụ thể trong npx -y package@version để tránh agent bất ngờ có thêm/mất tool sau một lần update ngầm.
  • Theo dõi token/context cost. Log của pod có thể rất dài — nếu không giới hạn tailLines, một lần gọi tool có thể nuốt hết context window (cửa sổ ngữ cảnh) của phiên làm việc. Luôn set mặc định tailLines hợp lý (50-200 dòng) trừ khi thật sự cần full log.
  • Đừng để agent tự chọn context ngầm định. Luôn chỉ định rõ namespace và context trong prompt, đừng dựa vào default của kubeconfig — một câu hỏi mơ hồ như "restart cái pod bị lỗi đó" trên cluster multi-namespace là công thức cho sự cố.

Mẹo: Ghi lại toàn bộ log tool call của MCP server (nhiều implementation hỗ trợ --verbose hoặc biến môi trường log level) và review định kỳ, giống như bạn review access log của một service account CI/CD — vì về bản chất, AI agent đang đóng đúng vai trò đó trong cluster của bạn.

Tiếp Kubernetes MCP với Claude Code CLI and VS Code