Tài liệu tháng 7/2026 của CNCF lập luận rằng Kubernetes đã trở thành nền tảng hội tụ tự nhiên cho cả microservices và AI agents. Sau một năm triển khai AI agents trong môi trường production, tôi nghĩ họ đúng — nhưng với những lý do sâu sắc hơn sự tiện lợi về infrastructure.
Lập luận không chỉ đơn giản là Kubernetes có thể chạy AI agents. Mà là agents cần chính xác những đảm bảo đã làm Kubernetes trở nên không thể thiếu cho microservices: service discovery, health checks, scaling có kiểm soát, isolation giới hạn blast radius, và hành vi có thể quan sát được. Và agents cần một điều mà microservices không cần cấp thiết: kiểm soát truy cập tool đáng tin cậy.
Tại Sao Agents Khó Hơn Microservices
Microservice là xác định. Với đầu vào X, nó tạo ra đầu ra Y. Nó thất bại theo những cách có thể dự đoán. Bạn có thể unit test, integration test và theo dõi tỷ lệ lỗi của nó.
AI agent là phi xác định. Nó suy luận, rồi hành động. “Hành động” có thể nghĩa là gọi database của bạn, invoke API bên ngoài, ghi file vào shared storage, hoặc kích hoạt agent khác. Tập hợp hành động chỉ bị giới hạn bởi những tool bạn đã cấp quyền truy cập — và agent quyết định công cụ nào gọi và theo thứ tự nào.
Tính phi xác định này không phải là bug. Đó là điều làm cho agents hữu ích. Nhưng nó thay đổi cơ bản hợp đồng vận hành. Bạn không thể test một agent vào sự an toàn. Bạn phải ràng buộc môi trường của nó để ngay cả hành vi không thể đoán trước cũng nằm trong giới hạn chấp nhận được.
Đó là công việc mà Kubernetes làm tốt hơn bất cứ thứ gì khác trong hệ sinh thái.
Bốn Kubernetes Primitive Quan Trọng Cho Agents
1. Namespace Isolation
Mỗi agent có namespace riêng. Đây là kiểm soát blast radius chính của bạn. Một agent hoạt động sai — dù do prompt injection attack, lỗi model, hay tool loop không kiểm soát — không thể ảnh hưởng đến workload ở namespace khác trừ khi bạn đã cho phép tường minh.
Trong thực tế điều này nghĩa là:
- Một namespace mỗi loại agent (ví dụ:
ns-research-agent,ns-code-agent) - Network policy chỉ whitelist các endpoint egress cần thiết
- Resource quota để một agent không thể làm cạn kiệt CPU/memory của agent khác
Hãy nghĩ về nó như việc cho mỗi agent một sandbox riêng. Chúng có thể chơi trong sandbox của mình. Chúng không thể với tay vào của bạn.
2. RBAC Cho Quyền Hạn Tool
Đây là nơi Kubernetes tỏa sáng đặc biệt cho agents. Trong thế giới microservices, RBAC kiểm soát service có thể làm gì trong Kubernetes API. Với agents, bạn mở rộng model đó để kiểm soát tool nào agent có thể invoke.
Pattern: bọc mỗi danh mục tool như một Kubernetes service. Service account của agent chỉ có quyền tiếp cận các service nhất định. Kubernetes API server thực thi những quyền đó ở tầng network — không có lượng prompt manipulation nào có thể cấp cho agent quyền mà service account của nó không có.
Một agent chỉ nên đọc từ CRM và ghi vào ticketing system sẽ không đột nhiên quyết định xóa records từ database của bạn — ngay cả khi prompt injection bảo nó làm vậy — vì service account của nó không có route đến database service.
3. HPA Cho Agent Scaling
Horizontal Pod Autoscaling ánh xạ tự nhiên vào các pattern workload agent. Agents dưới tải (nhiều task đồng thời) cần nhiều instance hơn. Agents nhàn rỗi (đang chờ phê duyệt của con người) cần ít hơn.
Điểm mấu chốt: scale theo độ sâu queue, không phải CPU. Một agent pod ở 5% CPU vẫn có thể có 200 task đang chờ. CPU-based HPA sẽ để những task đó chờ đợi trong khi pods ngồi không. Queue-depth-based HPA (qua KEDA) scale pods tương xứng với công việc thực sự đang chờ.
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: research-agent-scaler
namespace: ns-research-agent
spec:
scaleTargetRef:
name: research-agent
minReplicaCount: 1
maxReplicaCount: 20
triggers:
- type: rabbitmq
metadata:
queueName: research-tasks
queueLength: "5"Điều này nói với KEDA: thêm một pod cho mỗi 5 task trong queue, tối đa 20 pod.
4. Liveness và Readiness Probes
Agents có thể bị kẹt. Chúng có thể vào vòng lặp suy luận, chờ vô thời hạn các phản hồi tool bên ngoài, hoặc cạn kiệt context window. Không có probes, agent pod bị kẹt tiêu thụ resources và nhận công việc mới mà nó không thể hoàn thành.
Định nghĩa readiness probe kiểm tra endpoint trạng thái nội bộ của agent. Nếu agent báo cáo đang xử lý quá nhiều task đồng thời hoặc heartbeat cuối cùng của nó quá lâu, Kubernetes xóa nó khỏi load balancer. Liveness probes khởi động lại pods hoàn toàn không phản hồi.
Ví Dụ Triển Khai Agent .NET/C#
Đây là một Kubernetes manifest tối giản cho AI agent dựa trên .NET với resource limits và security context đúng chuẩn:
apiVersion: apps/v1
kind: Deployment
metadata:
name: document-agent
namespace: ns-document-agent
spec:
replicas: 2
selector:
matchLabels:
app: document-agent
template:
metadata:
labels:
app: document-agent
spec:
serviceAccountName: document-agent-sa
securityContext:
runAsNonRoot: true
runAsUser: 1000
readOnlyRootFilesystem: true
containers:
- name: agent
image: your-registry/document-agent:latest
resources:
requests:
memory: "512Mi"
cpu: "250m"
limits:
memory: "2Gi"
cpu: "1000m"
env:
- name: ANTHROPIC_API_KEY
valueFrom:
secretKeyRef:
name: ai-credentials
key: anthropic-key
livenessProbe:
httpGet:
path: /health/live
port: 8080
initialDelaySeconds: 30
periodSeconds: 10
readinessProbe:
httpGet:
path: /health/ready
port: 8080
initialDelaySeconds: 10
periodSeconds: 5readOnlyRootFilesystem: true quan trọng — nó ngăn agent ghi vào disk ngoài các volume được mount tường minh. Kết hợp với runAsNonRoot: true để đảm bảo process agent không thể leo thang đặc quyền ngay cả khi bị compromise.
Làm Cho Agents Đáng Tin Cậy: Tầng Policy
Kubernetes cung cấp cho bạn plumbing. Policy enforcement mang lại cho bạn đảm bảo.
OPA/Gatekeeper Cho Chính Sách Hành Vi Agent
Open Policy Agent với Gatekeeper cho phép bạn thực thi các ràng buộc hành vi ở tầng Kubernetes API. Với agents, bạn có thể viết các policy như:
- “Agents trong namespace
researchkhông được tạo pods” (ngăn agent tạo sub-agent không được phép) - “Tất cả agent pods phải có resource limits” (ngăn tiêu thụ resource không kiểm soát)
- “Service accounts của agent không được có cluster-admin bindings” (ngăn leo thang đặc quyền)
Các policy này chạy như admission webhooks — chúng đánh giá trước khi bất kỳ resource nào được tạo hoặc sửa đổi. Không có hành động agent nào có thể bypass chúng.
Network Policies Cho Kiểm Soát Truy Cập Tool
Định nghĩa các quy tắc egress tường minh cho mỗi agent namespace:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: document-agent-egress
namespace: ns-document-agent
spec:
podSelector:
matchLabels:
app: document-agent
policyTypes:
- Egress
egress:
- to:
- namespaceSelector:
matchLabels:
name: document-store
ports:
- port: 5432 # Chỉ PostgreSQL
- to:
- ipBlock:
cidr: 0.0.0.0/0
except:
- 10.0.0.0/8 # Không có internal network trừ tường minh
ports:
- port: 443 # Chỉ HTTPS đến external APIsDocument agent có thể tiếp cận database PostgreSQL và external HTTPS endpoints. Nó không thể tiếp cận bất kỳ internal service nào khác. Điều này được thực thi bởi CNI plugin — không có code agent hay prompt injection nào có thể override nó.
Audit Logging Cho Compliance
Bật Kubernetes audit logging cho các agent namespace. Mọi API call mà agent thực hiện — tạo pod, truy cập secret, gọi ConfigMap — tạo ra một audit event. Route những thứ này đến SIEM của bạn.
Với các ngành được quản lý, audit trail này chứng minh compliance: bạn có thể hiển thị chính xác mỗi agent đã truy cập gì, khi nào, và dưới thẩm quyền của ai. Đó là tư thế bảo mật khác về cơ bản so với “chúng ta đã review code và trông ổn”.
Stack Observability
Chạy agents trên Kubernetes nghĩa là bạn kế thừa tooling observability của hệ sinh thái:
- Prometheus + Grafana: agent throughput, task latency, tỷ lệ lỗi, độ sâu queue
- Jaeger/Tempo: distributed traces qua chuỗi agent → tool → agent
- Loki: log aggregation có cấu trúc với context agent (task ID, tool được gọi, kết quả)
- AlertManager: bắn cảnh báo khi agents vượt ngưỡng token budget, tần suất tool call, hoặc tỷ lệ lỗi
Các metrics quan trọng cần theo dõi cho agents không tồn tại với microservices:
- Tốc độ tiêu thụ token: agents có đang dùng token hiệu quả không?
- Tần suất tool call mỗi task: đột biến cho thấy vòng lặp suy luận
- Tỷ lệ hoàn thành task vs. tỷ lệ từ bỏ: agents thường xuyên từ bỏ task báo hiệu lỗi tool hoặc vấn đề chất lượng prompt
- Cross-agent call graphs: agent nào đang gọi agent nào? Phụ thuộc vòng tròn xuất hiện ở đây.
Tại Sao Điều Này Quan Trọng Hơn Chỉ Infrastructure
CNCF đóng khung Kubernetes như một nền tảng hội tụ, và tôi nghĩ cách đóng khung đó hoàn toàn đúng. Chúng ta đã dành một thập kỷ xây dựng kỷ luật vận hành xung quanh microservices trên Kubernetes. Kỷ luật đó — cách chúng ta xử lý rollouts, cách chúng ta quản lý secrets, cách chúng ta thực thi policies, cách chúng ta quan sát hành vi — có thể chuyển trực tiếp sang agents.
Thay thế là AI agents chạy như các daemon tùy chỉnh với các permission model đặc biệt, scaling tự quản lý, và logging chỉ tồn tại nếu developer nghĩ đến việc thêm nó. Đó là nơi hầu hết các team đang ở ngày hôm nay. Và đó là lý do tại sao các sự cố “AI agent hoạt động điên loạn” tiếp tục xảy ra.
Kubernetes không làm cho agents của bạn thông minh hơn. Nó làm cho môi trường của chúng đáng tin cậy. Sự phân biệt đó là điều tách biệt hệ thống AI production với một demo.
Khi đánh giá liệu một AI agent deployment có sẵn sàng production không, tôi giờ đây hỏi: hành vi của agent này có chấp nhận được nếu model đưa ra quyết định tệ nhất hợp lý tại mỗi bước không? Nếu câu trả lời phụ thuộc vào “model có thể sẽ làm điều đúng”, bạn không có hệ thống đáng tin cậy. Bạn có một canh bạc lạc quan.
Kubernetes, với namespace isolation, RBAC, network policies và audit logging đúng chuẩn, cho phép bạn trả lời có bất kể model quyết định gì. Đó là kỷ luật infrastructure làm cho hệ thống AI agentic an toàn để vận hành ở quy mô lớn.