Chương 47. Kubernetes

Ở chương 45, ta nói về Docker và container.

Ở chương 46, ta nói về CI/CD.

Chương này nói về Kubernetes.

Kubernetes thường được nhắc như một thứ rất "chuẩn công ty lớn".

Nhưng để hiểu đúng, đừng bắt đầu bằng thuật ngữ.

Hãy bắt đầu bằng vấn đề:

Tôi có nhiều container.
Tôi muốn chạy chúng trên nhiều máy.
Nếu container chết thì tự chạy lại.
Nếu deploy version mới thì rollout dần.
Nếu traffic tăng thì scale thêm.
Nếu service A gọi service B thì có địa chỉ ổn định.
Nếu một máy chết thì workload chuyển chỗ khác.

Đó là bài toán orchestration.

Thông điệp chính của chương:

> Kubernetes là nền tảng điều phối container. Nó giúp chạy, scale, restart, route và deploy container trên cụm máy. Nhưng Kubernetes không thay thế hiểu biết về app, database, queue, security, monitoring, hay migration.

---

47.1. Ví dụ dễ hiểu: quản lý một đội bếp lớn

Một bếp nhỏ có một đầu bếp.

Bạn chỉ cần nói:

Nấu món này.

Nhưng một bếp lớn có nhiều người:

  • Ai đứng bếp nóng?
  • Ai làm món lạnh?
  • Ai thay người nghỉ?
  • Nếu một bếp hỏng thì chuyển món sang đâu?
  • Nếu khách đông thì thêm người ở quầy nào?
  • Nếu đổi menu thì đổi từng quầy hay đổi một lúc?

Bạn cần một người/quy trình điều phối.

Kubernetes cũng vậy.

Nó không viết app thay bạn.

Nó điều phối việc chạy app.

---

47.2. Orchestration là gì?

Orchestration là điều phối nhiều container/service.

Nó trả lời:

  • Container này chạy ở máy nào?
  • Nếu chết thì restart không?
  • Chạy bao nhiêu bản sao?
  • Bản nào đang healthy?
  • Service này gọi service kia bằng tên gì?
  • Deploy version mới thế nào?
  • Config/secret đưa vào container ra sao?
  • Resource CPU/RAM chia thế nào?
  • App public ra internet thế nào?

Nếu chỉ chạy một container trên một server, bạn có thể chưa cần orchestration phức tạp.

Nhưng khi số container, service, worker, môi trường tăng lên, orchestration bắt đầu có giá trị.

---

47.3. Kubernetes giải quyết gì?

Kubernetes, thường viết là K8s, giúp:

  • Chạy container trên cluster.
  • Restart container khi lỗi.
  • Scale số replicas.
  • Rolling deploy.
  • Service discovery.
  • Load balance nội bộ.
  • Config và secret injection.
  • Health check.
  • Resource request/limit.
  • Job/CronJob.
  • Namespace.
  • Ingress.
  • Volume integration.

Nói ngắn:

Kubernetes là hệ điều hành cho một cụm máy chạy container.

Đó là cách nói hình tượng.

Nó quản lý nhiều node như một nền tảng chung để chạy workload.

---

47.4. Kubernetes không giải quyết gì?

Kubernetes không tự giải quyết:

  • Query database chậm.
  • Schema migration sai.
  • Worker concurrency tính sai.
  • Queue retry không idempotent.
  • App giữ state trong RAM.
  • File upload lưu trong container.
  • Permission bug.
  • Secret bị log.
  • AI API timeout.
  • Chi phí cloud tăng.
  • Không có monitoring tốt.

Nếu app thiết kế sai, đưa lên Kubernetes chỉ làm app sai chạy trong Kubernetes.

Kubernetes là platform.

Không phải thuốc chữa kiến trúc.

---

47.5. Cluster là gì?

Cluster là một cụm máy do Kubernetes quản lý.

Một cluster có:

  • Control plane.
  • Worker nodes.

Control plane quyết định:

Workload nào nên chạy ở đâu?
Trạng thái mong muốn là gì?
Cluster hiện tại ra sao?

Worker node là máy chạy container thật.

Ví dụ:

Cluster
  node-1
  node-2
  node-3

Bạn nói với Kubernetes:

Tôi muốn chạy 3 bản API.

Kubernetes quyết định đặt chúng lên node nào.

---

47.6. Node là gì?

Node là máy trong cluster.

Node có thể là:

  • VM.
  • Bare metal server.
  • Cloud instance.

Node chạy:

  • Container runtime.
  • Kubelet.
  • Network components.
  • Pods.

Nếu node chết, Kubernetes có thể tạo pod thay thế trên node khác, nếu còn capacity và workload được cấu hình đúng.

Nhưng nếu dữ liệu quan trọng nằm local trên node đó, vẫn có thể mất hoặc khó phục hồi.

Vì vậy app vẫn cần storage thiết kế đúng.

---

47.7. Pod là gì?

Pod là đơn vị nhỏ nhất Kubernetes chạy.

Pod chứa một hoặc nhiều container.

Thường một pod chứa một app container chính.

Ví dụ:

api pod:
  container api

worker pod:
  container worker

Pod có IP riêng trong cluster.

Container trong cùng pod chia sẻ network namespace.

Nói dễ hiểu:

> Pod là cái hộp Kubernetes đặt lên node để chạy container.

Trong đa số app web, hãy nghĩ:

Một pod = một bản chạy của app/worker.

---

47.8. Vì sao không gọi thẳng pod?

Pod có thể chết và được tạo lại.

Khi tạo lại, IP pod có thể đổi.

Vì vậy không nên để service khác gọi thẳng IP pod.

Ta cần một địa chỉ ổn định.

Đó là Kubernetes Service.

---

47.9. Service là gì?

Kubernetes Service cung cấp địa chỉ ổn định để truy cập một nhóm pod.

Ví dụ:

api-service

trỏ đến các pod có label:

app=api

Luồng:

Client nội bộ gọi api-service
-> Kubernetes route tới một api pod healthy

Service giúp service discovery và load balancing nội bộ.

Pod có thể đổi.

Service name vẫn ổn định.

---

47.10. Deployment là gì?

Deployment mô tả trạng thái mong muốn cho một nhóm pod chạy app.

Ví dụ:

Tôi muốn API chạy 3 replicas.
Dùng image synvia-api:abc123.
Rolling update khi đổi image.

Kubernetes cố giữ trạng thái đó.

Nếu một pod chết:

Deployment tạo pod mới.

Nếu bạn đổi image:

Deployment rollout version mới.

Deployment rất phù hợp cho app stateless như web API.

---

47.11. Replica là gì?

Replica là một bản chạy giống nhau của pod.

Ví dụ:

api replicas = 3

nghĩa là có 3 pod API.

Load balancer/service có thể chia traffic vào chúng.

Nếu một pod chết, Kubernetes tạo pod khác để trở lại 3.

Nhưng nhớ:

3 API replicas không làm database nhanh hơn.
3 API replicas không làm Gemini API nhanh hơn.
3 API replicas không xử lý worker queue nhanh hơn nếu worker vẫn ít.

Scale đúng tầng vẫn quan trọng.

---

47.12. StatefulSet là gì?

StatefulSet dùng cho workload có state và identity ổn định hơn.

Ví dụ:

  • Database cluster.
  • Kafka.
  • Elasticsearch.
  • Stateful systems.

StatefulSet phức tạp hơn Deployment.

Với app web thông thường, API/worker thường dùng Deployment.

Database production không nên tự chạy trên Kubernetes nếu team chưa có năng lực vận hành stateful workload.

Managed database thường thực dụng hơn.

Kubernetes chạy stateful được.

Nhưng "chạy được" khác "vận hành tốt".

---

47.13. Job và CronJob

Job chạy một việc rồi kết thúc.

Ví dụ:

Run database migration.
Backfill data.
Generate one-time report.

CronJob chạy định kỳ.

Ví dụ:

Mỗi đêm dọn file tạm.
Mỗi giờ aggregate analytics.
Mỗi ngày gửi report.

Job/CronJob hữu ích.

Nhưng với queue worker dài hạn, thường dùng Deployment chạy worker process.

Ví dụ:

celery-worker Deployment replicas=5

---

47.14. Namespace là gì?

Namespace là cách chia tài nguyên trong cluster.

Ví dụ:

dev
staging
production
monitoring

Hoặc:

team-a
team-b
platform

Namespace giúp:

  • Tổ chức tài nguyên.
  • Phân quyền.
  • Giới hạn resource.
  • Tách môi trường ở mức tương đối.

Nhưng namespace không phải security boundary tuyệt đối.

Không nên đặt dữ liệu cực nhạy vào cùng cluster chỉ vì khác namespace rồi nghĩ là đủ.

---

47.15. ConfigMap và Secret

ConfigMap chứa config không nhạy cảm.

Ví dụ:

LOG_LEVEL
FEATURE_FLAG_DEFAULT
PUBLIC_API_BASE

Secret chứa dữ liệu nhạy cảm hơn.

Ví dụ:

DATABASE_URL
JWT_SECRET
AI_PROVIDER_KEY

Kubernetes Secret không tự động là một vault hoàn hảo.

Cần hiểu:

  • Secret được lưu ở đâu.
  • Có encryption at rest không.
  • Ai có quyền đọc.
  • Có bị mount vào pod không cần thiết không.
  • Có bị log không.

Với production nghiêm túc, có thể tích hợp external secret manager.

---

47.16. Ingress là gì?

Ingress định nghĩa cách traffic HTTP từ ngoài vào service trong cluster.

Luồng:

Internet
-> Load balancer
-> Ingress controller
-> Kubernetes Service
-> Pods

Ingress có thể route theo host/path:

app.example.com -> frontend service
api.example.com -> api service

Ingress controller có thể là:

  • Nginx Ingress.
  • Traefik.
  • HAProxy.
  • Envoy/Gateway API implementations.
  • Cloud provider controller.

Ingress là phần rất quan trọng để public app ra ngoài.

Cấu hình sai có thể gây lỗi routing, TLS, timeout, body size, WebSocket.

---

47.17. Kubernetes Service khác API Gateway

Kubernetes Service là service discovery/load balancing nội bộ cho pod.

API Gateway là cửa API ở tầng cao hơn, thường xử lý:

  • Auth.
  • Rate limit.
  • API key.
  • Route public.
  • Aggregation.

Ingress/Gateway có thể làm một phần API gateway nếu cấu hình/plugin đủ.

Nhưng đừng trộn khái niệm:

Kubernetes Service:
  làm địa chỉ ổn định cho pods.

API Gateway:
  quản lý chính sách API/client-facing.

---

47.18. Readiness và liveness probe

Kubernetes dùng probes để biết pod khỏe không.

Liveness probe:

App còn sống không?
Nếu fail, restart pod.

Readiness probe:

App sẵn sàng nhận traffic không?
Nếu fail, không gửi traffic vào pod.

Ví dụ:

Pod start xong process.
Nhưng chưa warm up hoặc chưa connect dependency.
Readiness fail.
Service chưa route traffic.

Probe sai có thể gây thảm họa.

Nếu liveness quá nhạy, pod bị restart liên tục dù chỉ chậm tạm thời.

Nếu readiness quá lỏng, traffic vào pod chưa sẵn sàng.

---

47.19. Requests và limits

Kubernetes cần biết pod cần bao nhiêu tài nguyên.

Request:

Tài nguyên pod cần để scheduler đặt lên node.

Limit:

Tài nguyên tối đa pod được dùng.

Ví dụ:

api:
  request: 500m CPU, 512Mi RAM
  limit: 1 CPU, 1Gi RAM

Nếu không set request/limit, cluster khó schedule và dễ bị một workload ăn quá nhiều tài nguyên.

Nếu set quá thấp, app bị throttle/OOMKilled.

Resource config cần đo và điều chỉnh.

---

47.20. OOMKilled là gì?

OOMKilled nghĩa là pod bị kill vì dùng quá memory limit.

Ví dụ:

Worker xử lý file lớn.
RAM vượt limit.
Container bị kill.
Job retry.
Lại bị kill.

Khi thấy OOMKilled, đừng chỉ tăng RAM mù quáng.

Hỏi:

  • Có memory leak không?
  • File có quá lớn không?
  • Worker concurrency quá cao không?
  • Có stream thay vì load toàn bộ vào RAM được không?
  • Limit có quá thấp không?

Kubernetes cho ta tín hiệu.

Ta vẫn phải hiểu app.

---

47.21. Horizontal Pod Autoscaler

HPA tự tăng/giảm số pod dựa trên metric.

Ví dụ:

CPU > 70%
-> tăng API replicas.

HPA hữu ích cho web/API traffic.

Nhưng với worker queue, autoscale tốt hơn có thể dựa trên:

Queue length.
Queue wait time.
Jobs per second.

Nếu chỉ scale worker theo CPU, có thể không đúng.

Ví dụ worker đang chờ AI API nên CPU thấp, nhưng queue backlog cao.

HPA theo CPU sẽ không scale.

Metric phải phù hợp workload.

---

47.22. Kubernetes không tự biết bottleneck

Kubernetes có thể scale pod.

Nhưng nó không tự biết:

Gemini quota chỉ 100 RPM.
Database connection gần max.
Queue retry đang tăng.
Worker giữ transaction quá lâu.

Nếu autoscale worker quá mạnh, có thể:

  • Đập vào database.
  • Vượt quota AI.
  • Tăng retry.
  • Tăng chi phí.

Autoscaling cần guardrail:

  • Max replicas.
  • Rate limit.
  • Queue priority.
  • External API quota.
  • Connection pool.
  • Cost alert.

Kubernetes scale container.

Bạn vẫn phải scale hệ thống.

---

47.23. Rolling update trong Kubernetes

Deployment hỗ trợ rolling update.

Khi đổi image:

Kubernetes tạo pod mới.
Chờ pod mới ready.
Giảm pod cũ.
Lặp lại.

Điều này giúp deploy ít downtime hơn.

Nhưng vẫn cần:

  • Readiness probe đúng.
  • Graceful shutdown.
  • Backward-compatible schema.
  • Worker job compatibility.
  • Không xóa asset/config cũ quá sớm.

Kubernetes rollout tốt không cứu được migration phá code cũ.

CI/CD và migration vẫn quan trọng.

---

47.24. Rollback trong Kubernetes

Kubernetes có thể rollback Deployment về revision trước.

Ví dụ:

kubectl rollout undo deployment/api

Nhưng rollback pod/image không rollback:

  • Database schema.
  • Dữ liệu đã ghi.
  • Job payload đã tạo.
  • External side effect.
  • Cache/CDN.
  • ConfigMap/Secret nếu đã đổi.

Vì vậy rollback vẫn cần plan.

Đừng nghĩ Kubernetes rollback là nút thời gian quay lại toàn hệ thống.

---

47.25. Graceful shutdown trong Kubernetes

Khi pod bị terminate, Kubernetes gửi signal và chờ một thời gian.

App nên:

  • Ngừng nhận request mới.
  • Hoàn tất request đang chạy nếu có thể.
  • Đóng connection.
  • Worker xử lý ack/requeue đúng.

Nếu app không xử lý shutdown:

  • Request bị cắt.
  • Job bị mất hoặc retry sai.
  • User thấy lỗi trong deploy.

Kubernetes cung cấp cơ chế.

App phải hợp tác.

---

47.26. PodDisruptionBudget

PodDisruptionBudget, PDB, giúp giới hạn số pod có thể bị gián đoạn cùng lúc.

Ví dụ:

API có 5 replicas.
Luôn cần ít nhất 3 available.

PDB hữu ích khi:

  • Node maintenance.
  • Cluster upgrade.
  • Voluntary disruption.

Không phải app nhỏ cần ngay.

Nhưng với service quan trọng, PDB giúp tránh mất quá nhiều replicas cùng lúc.

---

47.27. Kubernetes và database

Có thể chạy database trong Kubernetes.

Nhưng production database cần:

  • Persistent volume.
  • Backup/restore.
  • Replication.
  • Upgrade.
  • Monitoring.
  • Storage performance.
  • Failover.
  • Operator nếu có.

Nếu team chưa mạnh vận hành database, managed database thường tốt hơn.

Kubernetes rất hợp chạy stateless app và worker.

Stateful workload cần thận trọng hơn nhiều.

Đừng chạy PostgreSQL production trong Kubernetes chỉ vì "mọi thứ phải container hóa".

---

47.28. PersistentVolume

PersistentVolume là storage bền hơn pod.

Pod chết, volume vẫn có thể còn.

Dùng cho:

  • Stateful workload.
  • Database.
  • File cần persist trên cluster.

Nhưng với file user upload, object storage vẫn thường tốt hơn.

PersistentVolume gắn với cluster/cloud storage.

Object storage phù hợp hơn cho:

  • File upload.
  • Report.
  • Avatar.
  • Submission artifact.
  • Static media.

Đừng dùng volume local của pod như nơi giữ file quan trọng nếu app cần scale nhiều node.

---

47.29. Helm và manifest

Kubernetes resource thường được mô tả bằng YAML manifest.

Ví dụ:

  • Deployment.
  • Service.
  • Ingress.
  • ConfigMap.
  • Secret.

Khi nhiều manifest, cần công cụ quản lý.

Helm là package manager/template tool phổ biến cho Kubernetes.

Kustomize cũng hay dùng.

Nhưng YAML/template có thể trở nên rối.

Nguyên tắc:

Cấu hình càng quan trọng, càng cần review, version control, và deploy qua pipeline.

Đừng sửa tay production cluster tùy hứng rồi quên.

---

47.30. Kubernetes security cơ bản

Một số điểm cần biết:

  • RBAC: ai được làm gì trong cluster.
  • Namespace: tổ chức tài nguyên.
  • NetworkPolicy: pod nào gọi pod nào.
  • Secret management.
  • Service account.
  • Pod security context.
  • Image pull policy.
  • Admission controller.
  • LimitRange/ResourceQuota.

Nếu ai cũng có cluster-admin, rủi ro rất lớn.

Nếu pod chạy với quyền quá cao, rủi ro tăng.

Nếu service account có quyền đọc secret toàn cluster, một pod bị hack có thể lan rộng.

Kubernetes cần bảo mật riêng.

Không tự an toàn mặc định trong mọi setup.

---

47.31. ServiceAccount

ServiceAccount là identity cho pod khi gọi Kubernetes API hoặc cloud integration.

Ví dụ:

api pod dùng service account api-sa.
worker pod dùng worker-sa.

Không nên để mọi pod dùng một service account quyền rộng.

Với cloud, service account có thể liên kết workload identity để truy cập:

  • Object storage.
  • Secret manager.
  • Pub/Sub/SQS.
  • Cloud APIs.

Least privilege vẫn áp dụng.

Worker chấm bài không cần quyền quản trị cluster.

API app không cần quyền đọc mọi secret.

---

47.32. NetworkPolicy trong Kubernetes

Mặc định nhiều cluster cho pod nói chuyện khá thoải mái.

NetworkPolicy giúp giới hạn:

api pod được gọi db proxy.
worker pod được gọi queue.
frontend pod không được gọi database.

Điều này giảm rủi ro lateral movement.

Nhưng NetworkPolicy cần network plugin hỗ trợ.

Và cấu hình sai có thể chặn traffic hợp lệ.

Nên bắt đầu với các boundary rõ:

  • Database.
  • Redis/queue.
  • Internal admin service.
  • Sandbox.

Không nhất thiết viết policy cực chi tiết từ ngày đầu.

---

47.33. Observability trong Kubernetes

Kubernetes tạo nhiều lớp cần quan sát:

  • Pod status.
  • Restart count.
  • CPU/RAM.
  • OOMKilled.
  • Node pressure.
  • Deployment rollout.
  • Ingress latency.
  • Service errors.
  • Logs.
  • Metrics.
  • Events.

Nếu không có observability, Kubernetes rất khó debug.

Bạn sẽ thấy:

App lỗi.
Nhưng lỗi ở app, pod, node, ingress, service, DNS, secret, config hay network?

Kubernetes làm được nhiều thứ.

Nhưng cũng thêm nhiều nơi có thể lỗi.

---

47.34. Managed Kubernetes hay tự dựng?

Managed Kubernetes:

  • GKE.
  • EKS.
  • AKS.
  • DigitalOcean Kubernetes.
  • Civo.
  • Scaleway.

Ưu điểm:

  • Control plane được quản lý.
  • Tích hợp cloud.
  • Upgrade dễ hơn.
  • Ít gánh nặng vận hành hơn tự dựng.

Nhược điểm:

  • Vẫn phải quản worker nodes, networking, manifests, security, cost.
  • Chi phí và độ phức tạp vẫn có.

Tự dựng Kubernetes thường không nên cho team nhỏ nếu không có lý do rất rõ.

Managed K8s đã đủ phức tạp rồi.

---

47.35. Khi nào Kubernetes đáng dùng?

Kubernetes đáng cân nhắc khi:

  • Có nhiều service/container.
  • Cần scale nhiều workload.
  • Cần rolling deploy/rollback chuẩn.
  • Nhiều team deploy độc lập.
  • Cần platform chung.
  • Có workload web + worker + cron + internal service.
  • Cần portability giữa cloud/on-prem.
  • Team có năng lực vận hành.
  • Hệ thống đủ lớn để chi phí complexity đáng giá.

Kubernetes rất mạnh khi bạn có nhiều container cần điều phối nghiêm túc.

---

47.36. Khi nào Kubernetes là quá nặng?

Kubernetes có thể quá nặng khi:

  • Chỉ có một app nhỏ.
  • Một backend + database managed là đủ.
  • Team rất nhỏ.
  • Chưa có người vận hành cluster.
  • Traffic chưa lớn.
  • Deploy platform đơn giản đã đủ.
  • Bạn chưa có monitoring/backup/CI/CD cơ bản.

Lúc này các lựa chọn khác có thể tốt hơn:

  • Render.
  • Railway.
  • Fly.io.
  • Heroku.
  • Cloud Run.
  • ECS/Fargate.
  • Docker Compose trên một VM có backup/monitoring.
  • App Platform của cloud provider.

Không dùng Kubernetes không có nghĩa là kém chuyên nghiệp.

Chọn đúng mức phức tạp mới là chuyên nghiệp.

---

47.37. Kubernetes so với PaaS

PaaS như Heroku/Render/Railway/Cloud Run thường che nhiều chi tiết vận hành.

Bạn chỉ cần:

Deploy app.
Set env.
Scale instance.
Connect managed DB.

Kubernetes cho nhiều quyền kiểm soát hơn.

Nhưng bạn chịu nhiều trách nhiệm hơn.

PaaS hợp khi:

  • Team nhỏ.
  • Muốn ship nhanh.
  • App chưa quá phức tạp.
  • Không muốn quản cluster.

Kubernetes hợp khi:

  • Nhu cầu tùy biến/scale/platform lớn hơn.
  • Có nhiều workload.
  • Team đủ vận hành.

---

47.38. Kubernetes và cost

Kubernetes có thể làm chi phí khó nhìn nếu không quản lý.

Chi phí gồm:

  • Worker nodes.
  • Load balancer.
  • Storage volumes.
  • Network.
  • Logging/monitoring.
  • Idle capacity.
  • Overprovisioning.

Nếu request/limit set sai, cluster có thể:

  • Thiếu tài nguyên.
  • Hoặc thừa node tốn tiền.

Autoscaling giúp, nhưng cần cấu hình.

Kubernetes không tự làm cloud rẻ hơn.

Nó có thể rẻ hơn hoặc đắt hơn tùy vận hành.

---

47.39. AI Judge: có cần Kubernetes ngay không?

AI Judge giai đoạn đầu có thể chưa cần Kubernetes.

Cấu trúc đơn giản hơn:

Managed PostgreSQL
Managed Redis/RabbitMQ/SQS
Object storage
API trên PaaS/VM/Cloud Run/ECS
Worker trên PaaS/VM/Cloud Run/ECS
CI/CD
Monitoring

Điều quan trọng hơn Kubernetes lúc đầu:

  • Queue/worker đúng.
  • Idempotency.
  • File storage đúng.
  • Database transaction ngắn.
  • Rate limit/quota AI.
  • Monitoring job/queue/cost.
  • Safe deploy.

Nếu chưa có những thứ này, Kubernetes không cứu được.

---

47.40. AI Judge: khi Kubernetes có ích

Kubernetes có thể hữu ích khi AI Judge lớn hơn:

Nhiều API services.
Nhiều worker pools.
Grading worker riêng theo model/priority.
Sandbox execution pool.
Admin/internal services.
Cron jobs.
Nhiều tenant lớn.
Autoscaling theo queue.
Nhiều team deploy.

Ví dụ workload:

api Deployment
teacher-dashboard-bff Deployment
grading-worker Deployment
export-worker Deployment
sandbox-runner Deployment/Job
analytics-consumer Deployment
cleanup CronJob

Kubernetes giúp điều phối nhiều workload này.

Nhưng vẫn cần thiết kế app đúng.

---

47.41. AI Judge: scale worker trong Kubernetes

Worker chấm bài không nên chỉ scale theo CPU.

Vì worker có thể:

Chờ AI API.
CPU thấp.
Queue backlog cao.

Metric tốt hơn:

  • Queue length.
  • Oldest job age.
  • Jobs completed per minute.
  • AI provider rate limit.
  • Error/retry rate.

Autoscale worker cần giới hạn:

max replicas dựa trên quota AI/database capacity.

Nếu quota Gemini 100 RPM, chạy 500 worker có thể chỉ tạo rate limit và retry storm.

Kubernetes cho công cụ scale.

Bạn phải đưa vào metric và giới hạn đúng.

---

47.42. AI Judge: sandbox trong Kubernetes

Nếu chạy code user, Kubernetes có thể giúp tạo isolated jobs/pods.

Nhưng cần cực kỳ cẩn thận:

  • Không mount secret.
  • Không dùng service account quyền rộng.
  • NetworkPolicy chặn network nếu cần.
  • CPU/memory/time limit.
  • Read-only filesystem nếu phù hợp.
  • Cleanup pod/job.
  • Không mount Docker socket.
  • Không cho privileged container nếu không cần.

Sandbox là vùng security sâu.

Kubernetes primitive giúp, nhưng không tự đảm bảo an toàn.

Thiết kế sandbox sai trong Kubernetes vẫn nguy hiểm.

---

47.43. AI Judge: deploy API và worker

Trong Kubernetes:

api Deployment
worker Deployment

có thể dùng cùng image nhưng command khác.

Deploy API:

  • Readiness probe.
  • Rolling update.
  • Graceful shutdown.

Deploy worker:

  • Không nhận web traffic.
  • Graceful shutdown job.
  • Ack/requeue đúng.
  • Payload backward-compatible.
  • Concurrency phù hợp.

Không nên coi worker giống API chỉ vì đều là pod.

Workload khác nhau cần deploy strategy khác nhau.

---

47.44. Những lỗi Kubernetes phổ biến

Lỗi 1:

Dùng Kubernetes khi app nhỏ và team chưa có năng lực vận hành.

Lỗi 2:

Không set requests/limits.

Lỗi 3:

Readiness/liveness probe sai làm pod restart hoặc nhận traffic sai lúc.

Lỗi 4:

Chạy database production trong cluster nhưng không có backup/restore/monitoring nghiêm túc.

Lỗi 5:

Secret trong cluster ai cũng đọc được.

Lỗi 6:

Không có NetworkPolicy, service nào cũng gọi được service nào.

Lỗi 7:

Autoscale worker theo CPU trong khi bottleneck là queue/AI quota.

Lỗi 8:

Rollback Deployment nhưng quên schema/data đã đổi.

Lỗi 9:

Không monitor pod restart/OOMKilled.

Lỗi 10:

Nghĩ Kubernetes thay thế CI/CD, observability, hoặc kiến trúc app.

---

47.45. Checklist trước khi dùng Kubernetes

Hỏi:

  • Vấn đề thật là gì?
  • Có bao nhiêu service/container?
  • PaaS/Cloud Run/ECS/Compose có đủ không?
  • Team có ai vận hành Kubernetes không?
  • Monitoring/logging đã sẵn chưa?
  • CI/CD deploy manifest/image thế nào?
  • Secret management ra sao?
  • Database dùng managed hay tự chạy?
  • App có stateless đủ để scale không?
  • Readiness/liveness probe là gì?
  • Request/limit đặt thế nào?
  • Worker autoscale theo metric nào?
  • NetworkPolicy có cần không?
  • Chi phí cluster có đáng không?
  • Nếu cluster lỗi, ai xử lý?

Nếu chưa trả lời được, Kubernetes có thể đang đến quá sớm.

---

47.46. Bảng chọn nhanh

| Tình huống | Cách nghĩ thường hợp | |---|---| | Một app nhỏ, team nhỏ | PaaS/VM/Cloud Run/Compose có thể đủ | | Nhiều container cần điều phối | Kubernetes đáng cân nhắc | | Cần rolling deploy/scale nhiều workload | Kubernetes hữu ích | | Chưa có monitoring/CI/CD cơ bản | Đừng vội Kubernetes | | Database production | Managed DB thường thực dụng hơn tự chạy trong K8s | | Worker queue backlog | Autoscale theo queue metric, không chỉ CPU | | File user upload | Object storage, không phụ thuộc pod filesystem | | Chạy code user | Sandbox/pod security/network policy rất chặt | | Nhiều team/platform chung | Kubernetes có thể rất mạnh | | Team không có vận hành cluster | Managed platform có thể tốt hơn |

---

47.47. Tóm tắt bằng AI Judge

Với AI Judge, Kubernetes có thể giúp khi hệ thống có:

Nhiều API services.
Nhiều worker pools.
Sandbox runners.
Cron jobs.
Autoscaling.
Rolling deploy.
Service discovery.
Resource isolation.

Nhưng Kubernetes không thay thế:

Queue design.
Worker idempotency.
AI quota/rate limit.
Database optimization.
Object storage.
Permission.
Monitoring queue/job/cost.
Safe migration.
Secret management.

Giai đoạn đầu, AI Judge có thể đi rất xa với managed services và platform đơn giản hơn.

Kubernetes đáng dùng khi độ phức tạp vận hành của nhiều container lớn hơn độ phức tạp mà Kubernetes mang vào.

---

47.48. Kết luận của chương

Kubernetes là công cụ rất mạnh để điều phối container.

Nó giúp chạy pod, tạo service ổn định, rollout deployment, restart khi lỗi, scale replicas, inject config/secret, chạy job/cronjob, và quản lý workload trên cluster.

Nhưng Kubernetes cũng là một hệ thống phức tạp cần vận hành.

Nó không tự sửa app stateful sai, migration nguy hiểm, database không backup, worker retry lỗi, file lưu sai chỗ, hay thiếu observability.

Thông điệp cần nhớ:

> Kubernetes giải quyết orchestration. Nó không thay thế tư duy kiến trúc, vận hành, bảo mật và reliability.

Ở chương tiếp theo, ta sẽ nói về managed service hay tự host: khi nào nên tự dựng để tiết kiệm/kiểm soát, khi nào nên mua dịch vụ managed để giảm rủi ro, và vì sao database/queue/object storage thường đáng cân nhắc managed rất sớm.