Deploy trên Kubernetes: Scaling agent fleet — Khi một container không đủ

Khi agent của bạn xử lý được 10 cuộc hội thoại đồng thời, Docker Compose vẫn là bạn tốt. Nhưng khi con số đó là 10.000, và bạn cần deploy đồng loạt 50 cấu hình khác nhau lên 2000 cluster — đó là lúc Kubernetes trở thành bài toán sống còn. Đây không chỉ là chuyện "scale container", mà là cách quản lý một fleet agent phân tán như một hệ thống thống nhất, đảm bảo trạng thái (conversation history, vector memory) không bị mất giữa các vòng đời pod.

Vấn đề

Bạn đã chạy agent trên laptop với docker-compose up. Mọi thứ ổn. Nhưng khi đưa vào production, bạn nhận ra agent AI khác biệt căn bản so với web app truyền thống: chúng là stateful. Một agent không chỉ là container vô tính — nó mang theo conversation history, checkpoints của các tác vụ dở dang, và vector memory có thể nặng hàng GB.

Với 10-20 instance, bạn có thể chạy 20 lệnh kubectl apply thủ công. Nhưng khi số lượng cluster tăng lên 500, 1000, 2000:

• Configuration drift: Mỗi cluster dần trở thành "snowflake" — cấu hình lệch nhau vài dòng YAML, version image khác nhau, biến môi trường thiếu sót.
• Imperative bottleneck: kubectl apply tuần tự tới từng cluster là O(N) — bạn phải quản lý kết nối tới hàng nghìn endpoint, không có audit trail, không rollback tập trung.
• etcd cardinality explosion: Mỗi bundle cấu hình nhân với số cluster tạo ra hàng trăm nghìn Custom Resource. Ở quy mô 2000 cluster × 50 bundles = 100.000 object, kubectl get chậm tới 20 giây.
• Autoscaling đơn điệu: Horizontal Pod Autoscaler (HPA) truyền thống dựa trên CPU/RAM, nhưng agent cần scale theo "độ nặng" của reasoning (token throughput, queue depth của tool calls, latency của MCP server) — métrix không tầm thường.

Ý tưởng cốt lõi

Bản chất là chuyển từ imperative (ra lệnh từng bước) sang declarative reconciliation (GitOps) — và từ singleton sang fleet. Thay vì nói "chạy container này trên node đó", bạn mô tả trạng thái mong muốn trong Git: "Tất cả cluster có label region=asia phải chạy agent version v2.1 với 3 replicas". Fleet Controller tự động kéo cấu hình và điều chỉnh thực tế cho khớp lý thuyết — pull-based, không cần mở firewall inbound.

Kiến trúc 4 lớp cho Agent Fleet

1. GitOps Control Plane Git repository là single source of truth. Mỗi commit là audit trail tự nhiên. Fleet controllers (như SUSE Fleet) chạy trên management cluster, watch Git repo qua webhook, rồi reconcile xuống các downstream cluster (workload clusters) qua agent nhẹ cài sẵn trên mỗi cluster.

2. Bundle Targeting & Label Selectors Thay vì script lặp for i in clusters, bạn định nghĩa Bundle — tập hợp manifest/Helm chart — và gán target qua label selectors (giống Service selector trong K8s).

# Fleet Bundle example cho GoClaw agent
apiVersion: fleet.cattle.io/v1alpha1
kind: Bundle
metadata:
  name: goclaw-agent-fleet
spec:
  resources:
  - content: |
      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: goclaw-agent
      spec:
        replicas: 3
        template:
          spec:
            containers:
            - name: agent
              image: troisinh/goclaw:v2.1
              env:
              - name: SOUL_MD_PATH
                value: /config/soul.md
              volumeMounts:
              - name: agent-memory
                mountPath: /data
            volumes:
            - name: agent-memory
              persistentVolumeClaim:
                claimTemplate: agent-pvc
  targetClusters:
  - matchLabels:
      region: asia
      tier: production

Kết quả thực tế từ SUSE Fleet: 50 bundles triển khai tới 500 cluster chỉ trong 90 giây — và 2000 cluster trong 7 phút (với 48 vCPU/96GB RAM cho controller).

3. Agent Supervision (DaemonSet Pattern) Với monitoring và logging, bạn không chỉ chạy 1 container agent. New Relic Fleet Control và Elastic Agent pattern dùng DaemonSet — một supervisor agent chạy trên mỗi node, quản lý lifecycle của các sub-agent (OTel collector, Fluent Bit, hoặc chính GoClaw agent), báo cáo health về trung tâm. Điều này tách biệt "quản lý" (control) khỏi "thực thi" (data plane).

4. MAS Autoscaling (Multi-Agent Systems) Thay vì HPA đơn giản dựa trên CPU, bạn triển khai các "scaling agent" như sidecar — sử dụng Reinforcement Learning (A2C) quan sát metric đặc thù (độ trễ tool call, độ sâu hàng đợi MCP request, token throughput) và điều chỉnh replica count. Đây là autoscaling "có tri thức" thay vì phản ứng theo tải CPU.

5. Stateful Agent Orchestration Vì agent có memory (SQLite, Redis, volume), bạn dùng Headless Service + PVC template trong StatefulSet để đảm bảo:

• Sticky identity: Pod-0 luôn mount cùng PVC chứa conversation history, dù bị reschedule sang node khác.
• Ordered deployment: Scale up/down có trật tự, tránh mất state giữa chừng khi terminate.

"À, chỉ vậy thôi": Bạn không quản lý 2000 cluster như 2000 cá thể. Bạn quản lý 1 Git repo, và hệ thống tự làm phần còn lại — giống như Terraform nhưng cho trạng thái runtime. State của agent (conversation) được externalize vào PVC/Redis, còn code là immutable image được GitOps reconcile.

Tại sao nó hoạt động

Pull-based vs Push: Push (kubectl apply) yêu cầu kết nối outbound từ control plane tới từng cluster, mở rủi ro bảo mật và khó xuyên qua NAT/firewall. Pull-based (Fleet Agent kéo config) chỉ cần outbound HTTPS từ cluster — an toàn hơn, dễ audit, và tự nhiên hỗ trợ air-gapped environments (chỉ cần mirror Git repo).

etcd là bottleneck, không phải CPU: Đây là insight then chốt. Kubernetes API server lưu mọi thứ vào etcd. Khi bạn tạo 1 BundleDeployment CRD cho mỗi cặp (bundle, cluster), bạn tạo O(N×M) objects. Ở 100.000 objects, etcd listing trở thành bottleneck — giải thích tại sao 2000 cluster mất 7 phút trong khi 500 cluster chỉ mất 90 giây. Giải pháp là sharding hoặc giảm cardinality (dùng aggregated APIs).

MAS Autoscaling thay vì KPA: Knative Pod Autoscaler (KPA) giả định request là stateless và đồng nhất. Agent workload thì ngược lại: một request có thể cần 30s reasoning (CoT dài), request khác chỉ cần 500ms (RAG lookup). Multi-agent sidecars học được pattern này và scale dự đoán (predictive) dựa trên "độ phức tạp" đầu vào thay vì chỉ reactive theo CPU.

Ý nghĩa thực tế

Benchmark thực tế (SUSE Fleet, New Relic):

• 500 clusters cập nhật 50 bundles: 90 giây
• 2000 clusters: 7 phút (với 48 vCPU/96GB RAM cho Fleet Controller)
• etcd latency: 20 giây khi vượt 100.000 objects (cảnh báo bottleneck sớm)

Ai đang dùng:

• SUSE/Rancher: Quản lý 10.000+ edge cluster (EV charging stations, retail POS) qua Fleet.
• New Relic: Fleet Control cho 100.000+ agent giám sát với lifecycle tập trung.
• Tencent/OpenClaw ecosystem: Zalo OA integration với K8s backend hỗ trợ quy mô WeChat (1B+ users).

Hạn chế — những gì K8s không giải quyết:

• Blast radius: Một GitRepo misconfigured (ví dụ: image tag sai) propagate toàn bộ fleet trong 90 giây. Cần canary deployment (Flagger) để giảm thiểu.
• Stateful complexity: Agent với conversation memory cần sticky session hoặc external Redis/Postgres. Fleet quản lý stateless tốt hơn stateful — bạn phải tự orchestrate PVC và backup (xem bài Disaster Recovery).
• MAS overhead: Dùng RL agent cho autoscaling thêm tính toán ~5-10% CPU — không đáng cho workload đơn giản chỉ cần scale theo CPU.
• Giới hạn vật lý: etcd không thể sharding dễ dàng — giới hạn cứng ~100.000 CRD trước khi cần kiến trúc lại thành nhiều management cluster.

Đào sâu hơn

Tài liệu chính thức:

• Kubernetes Documentation - StatefulSets — Cơ bản về workload stateful trên K8s.
• SUSE Fleet Documentation — GitOps at scale cho cluster fleet.
• New Relic Fleet Control — Quản lý agent lifecycle tập trung.

Bài liên quan TroiSinh:

Cùng cụm (Production Deploy):

Đọc tiếp:

Tài liệu mở rộng:

• Paper: "Streamlining Resilient Kubernetes Autoscaling with Multi-Agent Systems via Automated Online Digital Twin" (2025) — Nghiên cứu MAS autoscaling cho K8s.
• GitHub: SUSE Fleet — Open source GitOps fleet management.
• Blog: Fleet Management at Scale - SUSE Engineering — Kết quả benchmark 500→2000 clusters chi tiết.