Answer-first: Mở rộng quy mô các MCP server trong Kubernetes đòi hỏi phải tách biệt state (trạng thái) của JSON-RPC khỏi các kết nối bền bỉ (persistent connections) bằng cách sử dụng các websocket gateway, triển khai các stateless MCP worker replica với HPA, và sử dụng Redis cho distributed context caching (bộ nhớ đệm ngữ cảnh phân tán). Kiến trúc này ngăn chặn tình trạng cạn kiệt kết nối (connection exhaustion) khi hàng trăm AI agent truy vấn context đồng thời.
Model Context Protocol (MCP) đã trở thành tiêu chuẩn thực tế (de facto standard) để phơi bày dữ liệu doanh nghiệp (enterprise data) cho các AI agent. Đặc tả transport của nó định nghĩa stdio và Streamable HTTP (với tuỳ chọn SSE) như là các mô hình kết nối — và đây chính xác là nơi bắt nguồn những khó khăn trong việc scaling Kubernetes được đề cập dưới đây. Tuy nhiên, việc chạy một MCP server cục bộ (local) duy nhất hoàn toàn khác biệt so với việc phục vụ hàng ngàn request LLM đồng thời trong một môi trường microservices phân tán.
Tech Radar này đề cập đến các production pattern để chạy các fleet MCP server có throughput cao trên Kubernetes.
1. Nút thắt cổ chai của các Persistent Connection
Answer-first: Các bản implement tiêu chuẩn của MCP dựa trên các kết nối stdio hoặc SSE bền bỉ (persistent), tạo ra các nút thắt cổ chai mang tính stateful trong Kubernetes. Load balancer thường gặp khó khăn trong việc định tuyến (route) các luồng SSE sống thọ (long-lived streams) một cách đồng đều, gây ra tình trạng sử dụng pod CPU không đồng đều và cản trở autoscaling.
Khi hàng ngàn AI agent kết nối tới một cụm MCP server, việc giữ các kết nối mở vô thời hạn làm cạn kiệt các resource của cluster ingress. Kubernetes Horizontal Pod Autoscaler (HPA) dựa vào các metric về CPU/Memory, nhưng các idle SSE connection (kết nối SSE nhàn rỗi) kéo dài sẽ làm sai lệch các metric này, ngăn cản các hoạt động scale-down và làm lãng phí ngân sách compute.
Để giải quyết vấn đề này, các nền tảng (platform team) cần phải trừu tượng hóa transport layer khỏi MCP business logic bằng cách sử dụng các Gateway pattern chuyên biệt.
2. Kiến trúc Decoupled MCP Gateway
Answer-first: Một WebSocket/SSE Gateway chuyên biệt sẽ xử lý các connection từ client trong khi định tuyến các stateless JSON-RPC qua HTTP/gRPC tới các MCP worker pod ở backend. Điều này cho phép mở rộng quy mô (scaling) độc lập giữa connection layer (tầng kết nối) và phần compute thực tế cho việc truy xuất ngữ cảnh (context-retrieval).
Biểu đồ kiến trúc dưới đây minh họa cách một Kubernetes ingress định tuyến traffic của agent qua một Gateway stateful xuống các deployment MCP worker stateless.
graph TD
A[AI Agents] -->|"SSE / WebSockets"| B[Ingress NGINX]
B --> C[MCP Gateway Cluster]
C -->|"gRPC JSON-RPC"| D[MCP Worker Pod 1]
C -->|"gRPC JSON-RPC"| E[MCP Worker Pod N]
D --> F[("Vector DB / Enterprise API")]
E --> F
Bằng cách giới thiệu một Gateway cluster, các backend MCP worker sẽ hoàn toàn duy trì được tính stateless. Nếu một MCP worker bị crash trong khi đang fetch dữ liệu, Gateway có thể ngay lập tức retry (thử lại) payload JSON-RPC với một worker khỏe mạnh khác mà không làm đứt (break) kết nối SSE của client.
3. Distributed Context Caching (Bộ nhớ đệm ngữ cảnh phân tán)
Answer-first: Các truy vấn agent giống hệt nhau (identical) cho các static enterprise context sẽ làm lãng phí database I/O. Việc implement semantic caching (bộ đệm ngữ nghĩa) tại MCP worker layer bằng cách sử dụng Redis sẽ làm giảm đáng kể độ trễ truy xuất (retrieval latency) và bảo vệ các downstream API khỏi các rate limit.
Các hệ thống Agentic thường xuyên hỏi các câu hỏi lặp đi lặp lại trong quá trình suy luận chain-of-thought. Việc caching (lưu trữ đệm) các payload MCP tool call chính xác trong Redis đảm bảo các phản hồi dưới mức mili-giây (sub-millisecond) cho các request context bị lặp lại. Đối với dynamic data, việc implement TTL-based expiration (hết hạn dựa trên thời gian sống) đảm bảo các agent không thao tác trên các thông tin đã cũ (stale information).
Câu hỏi thường gặp (FAQ)
Q1: Tại sao không đơn giản là sử dụng session affinity của Kubernetes Service cho MCP?
Mặc dù session affinity (sticky session) định tuyến một client tới cùng một pod, nó lại làm trầm trọng thêm sự phân bổ tải (load distribution) không đồng đều. Một pod đơn lẻ có thể bị kẹt trong việc phục vụ các agent có nhu cầu truy xuất dữ liệu nặng trong khi các pod khác lại nhàn rỗi (idle). Một decoupled gateway với các stateless worker đảm bảo việc định tuyến round-robin hoặc least-connection ở cấp độ compute.
Q2: Một decoupled gateway xử lý các MCP resource subscription như thế nào?
Gateway duy trì một mapping của các agent subscription trong một distributed cache (như Redis). Khi một MCP worker phát hiện sự thay đổi tài nguyên (resource change), nó sẽ publish một event (sự kiện) tới một kênh Redis Pub/Sub. Gateway sẽ consume (tiêu thụ) event này và đẩy thông báo xuống qua kết nối SSE đang active (hoạt động) tương ứng cho agent.
Q3: Đâu là metric Kubernetes HPA được khuyến nghị cho các MCP worker?
Việc sử dụng CPU thường là một lagging indicator (chỉ số phản ánh chậm) đối với các tác vụ truy xuất context mang tính I/O-bound. Khuyến nghị là nên cấu hình các custom metric dựa trên số lượng các request JSON-RPC đang active (in flight) trên mỗi pod (sử dụng các Prometheus metric được scrape từ các worker). Điều này cho phép HPA scale out (mở rộng theo chiều ngang) một cách chủ động trước khi xảy ra các đợt tăng vọt (spike) về độ trễ.