Chạy AI agent trên Kubernetes với kagent và Agent Substrate
CNCF giới thiệu kiến trúc kết hợp kagent và Agent Substrate để chạy AI agent trên Kubernetes với Worker Pod, Actor theo phiên, snapshot và các lớp cô lập gVisor/microVM.
Một AI agent có thể nắm đầu ra mô hình, thông tin xác thực và quyền gọi tool. Vì vậy, chỉ chạy agent trong một container chưa tự động tạo ra một môi trường đủ kiểm soát cho production.
Theo bài viết của CNCF, kiến trúc kết hợp kagent và Agent Substrate hướng đến ba yêu cầu khi vận hành agentic workload: cô lập, bảo mật và khả năng mở rộng.
Container chưa chắc đã là sandbox đủ mạnh
Container tạo ra một mức độ tách biệt, nhưng bài viết lưu ý sandbox ở mức này có thể vẫn quá “phẳng”. Nếu ingress và egress mở rộng, workload vẫn có thể gửi traffic đi nơi khác; nếu không có cơ chế thực thi policy, phạm vi hoạt động của agent khó được kiểm soát.
Với AI agent, sandbox cần giải quyết nhiều điểm cùng lúc:
Không để code agent không tin cậy thoát sang môi trường host hoặc ảnh hưởng hạ tầng nền.
Thu hẹp blast radius của harness khi có sự cố.
Đặt agent đang nắm model output, credential có thể có và các tool call trong một biên cô lập.
Lưu snapshot để agent có thể tiếp tục từ trạng thái trước đó.
Tách biệt routing giữa nhiều agent trong môi trường multi-tenant.
Bài viết cũng nêu rằng việc cô lập agent cần kết hợp lớp phần mềm, phần cứng và policy enforcement trên đường đi của traffic đến đích, chẳng hạn tại AI Gateway.
kagent và Agent Substrate chia vai ra sao?
Trong kiến trúc được mô tả, kagent là runtime cho các agent được khai báo bằng cấu hình hoặc agent do người dùng mang vào (BYO). Bài viết nhắc đến các framework như LangGraph và ADK.
Agent Substrate là nền tảng sandbox bên dưới. Agent chạy trong các Worker, vốn là các Pod Kubernetes. Các agent được điều phối dưới dạng Actor, do ateapi — control plane của Agent Substrate — quản lý.
Kiến trúc sử dụng hai lớp cô lập:
| Tầng | Cơ chế | Mô tả trong bài viết |
|---|---|---|
| Phần mềm | gVisor | Workload chạy trong user space với app kernel riêng tên Sentry, nơi chặn và xử lý system call |
| Phần cứng | microVM | Guest OS/VM sử dụng các extension ảo hóa phần cứng trên CPU vật lý |
Điểm đáng chú ý là Pod vẫn là đơn vị triển khai quen thuộc của Kubernetes, trong khi boundary thực thi agent được bổ sung bằng các cơ chế cô lập khác ngoài việc dùng chung kernel container thông thường.
Khai báo Harness và AgentTemplate
Bài viết minh họa cách tạo agent theo kiểu declarative sau khi cài đặt Agent Substrate và kagent.
Trong mô hình này:
Harness là Actor hoặc agent thực thi.
AgentTemplate là cấu hình có thể tái sử dụng cho các agent.
Harness có thể đại diện cho những agent như Codex, Claude Code hoặc BYO agent.
Ví dụ CRD được bài viết đưa ra:
bash
kubectl apply -f - <<EOF
apiVersion: kagent.dev/v1alpha3
kind: Harness
metadata:
name: kagent
namespace: kagent
spec:
kagent: {}
workload:
image: PATHTOYOURAGENTIMAGE
substrate:
workerPoolRef:
name: kagent-default
snapshotPolicy:
location: gs://ate-snapshots-PATHTOYOURSNAPSHOTS
allowedAgentTemplates:
selector:
matchLabels:
kagent.dev/harness: kagent
---
apiVersion: kagent.dev/v1alpha3
kind: AgentTemplate
metadata:
name: assistant
namespace: kagent
labels:
kagent.dev/harness: kagent
spec:
modelConfig:
name: default-model-config
description: A substrate-backed assistant used to verify this main build.
systemPrompt: You are a helpful assistant running on kagent.
EOF
Trong cấu hình này, workerPoolRef tham chiếu WorkerPool mà Harness sử dụng. snapshotPolicy.location chỉ vị trí snapshot, còn allowedAgentTemplates chọn các template được phép dùng Harness đó.
Theo bài viết, Helm chart của kagent mặc định tạo một WorkerPool với hai Worker Pod thông qua thiết lập substrateWorkerPool.create=true.
Actor được tạo theo session
Agent Substrate không nhất thiết giữ Actor chạy liên tục khi không có phiên hoạt động. Bài viết cho biết Actor chỉ chạy khi có session đang hoạt động.
Khi chưa có session, giao diện Substrate có thể hiển thị không có Actor đang chạy. Khi người dùng mở một session mới, một Actor được tạo. Khi session hoàn tất, Actor được dừng. Nếu tiếp tục dùng session hiện tại, hệ thống không tạo Actor mới cho mỗi prompt.
Bài viết minh họa trạng thái giao diện thay đổi từ 0/8 sang 0/9, rồi 0/10 khi mở thêm session. Ý chính là việc tạo Actor gắn với session mới, thay vì mọi lần gửi yêu cầu đến agent.
Cách làm này đặt lifecycle của agent gần với lifecycle phiên làm việc, thay vì duy trì một tập agent luôn chạy chỉ để chờ request.
Có thể tạo agent từ UI
Ngoài CRD, bài viết cũng mô tả luồng tạo agent trong giao diện kagent:
Mở khu vực Agents.
Chọn + New template để định nghĩa template.
Vào phần + New Harness.
Cấu hình namespace triển khai Actor/agent, tên, runtime adapter và vị trí image.
kagent vì thế cung cấp giao diện và cách khai báo quen thuộc hơn để tương tác với agent chạy qua Agent Substrate, thay vì chỉ gọi Actor theo cách lập trình.
Những thành phần cần nhìn cùng nhau
Điểm chính của kiến trúc không chỉ là thêm một runtime vào Kubernetes. Nó gom các khái niệm quan trọng khi chạy agent vào các đối tượng rõ ràng:
Worker Pod cho nơi agent thực thi;
Actor cho agent theo session;
Harness và AgentTemplate cho cấu hình triển khai;
Snapshot cho trạng thái;
các lớp cô lập gVisor và microVM;
policy enforcement và routing cho traffic của agent.
Với đội platform, đây là một khung tham chiếu hữu ích: khi đưa AI agent vào cluster, hãy đánh giá cả nơi agent chạy, cách session được tạo, nơi trạng thái được lưu và đường đi của traffic — thay vì chỉ xem agent như một container khác.