Part 12 · Kubernetes · 12.1.05

Workload Controllers: Deployment, StatefulSet, DaemonSet, Job và CronJob

Controller giữ actual state tiến về desired state. Chọn controller theo identity, placement và completion semantics; đừng dùng Deployment cho mọi workload, và đừng nhầm rollout “Complete” với business SLI đã an toàn.

1. Controllers

Kubernetes controller chạy reconciliation loop: quan sát trạng thái hiện tại, so với desired state trong API object rồi tạo, cập nhật hoặc xóa resource để thu hẹp chênh lệch. Với workload, controller thường quản lý Pod gián tiếp và tiếp tục thay thế Pod bị mất theo policy của object.

Mental model: controller là vòng lặp điều khiển, không phải một lần chạy “deploy”. Nếu bạn xóa một Pod thuộc Deployment/ReplicaSet, controller có thể tạo Pod khác để khôi phục replica count.

2. Controller types

Controller	Phù hợp	Semantic cần nhớ	Không tự giải quyết
Deployment	Stateless replicated application	Quản lý ReplicaSet, rolling update, rollback Pod template	Stable Pod identity, application-level HA, DB migration rollback
StatefulSet	Workload cần stable identity/storage/ordered behavior	Ordinal identity, stable network/storage association, ordered semantics khi cấu hình tương ứng	Quorum/replication correctness của database
DaemonSet	Một Pod trên mỗi eligible node, ví dụ agent/logging/CNI helper	Placement theo node eligibility; tự thêm Pod khi node phù hợp xuất hiện	Global singleton hoặc business sharding
Job	Finite work cần đạt completion	Retry/recreate Pod cho đến khi đạt completion/failure policy	Exactly-once side effect
CronJob	Scheduled Jobs	Tạo Job theo schedule; có concurrency/deadline/timezone policy	Strict wall-clock execution exactly once

Controller chỉ cung cấp orchestration semantics. Một StatefulSet không biến application stateful thành HA nếu application, replication protocol hoặc storage không hỗ trợ failover đúng cách.

3. Rolling update

Deployment dùng Pod template hash để tạo ReplicaSet revision. Khi template đổi, controller scale ReplicaSet mới lên và ReplicaSet cũ xuống. Hai knob quan trọng là maxSurge và maxUnavailable; cùng với readiness, minReadySeconds, termination grace và capacity cluster, chúng quyết định availability thực tế trong rollout.

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 1
    maxUnavailable: 0
minReadySeconds: 10
revisionHistoryLimit: 10

maxSurge: cho phép số Pod tạm thời vượt desired replicas để tạo headroom cho bản mới.
maxUnavailable: giới hạn số Pod có thể unavailable trong rollout; đặt 0 thường cần đủ surge capacity.
Readiness: chỉ nên true khi instance thực sự có thể nhận traffic với dependency quan trọng đã sẵn sàng.
minReadySeconds: giúp tránh việc Pod vừa Ready tức thời đã được tính là stable quá sớm.
revisionHistoryLimit: giữ ReplicaSet cũ cho rollback; đặt 0 loại khả năng rollback Deployment bằng history.

Failure window: rollout có thể “tiến triển” trong khi error rate business tăng, nếu readiness quá nông hoặc traffic chỉ chạm một số path. Controller completion không thay thế canary, SLI, synthetic check và quan sát downstream.

4. Zero downtime

“Zero downtime” là property end-to-end, không phải một flag của Deployment. Nó cần đủ capacity surge, readiness đúng, endpoint propagation/draining, shutdown graceful, application/schema backward-compatible và rollout policy phù hợp.

Failure mode	Biểu hiện	Mitigation / signal cần xem
Thiếu surge capacity	Pod mới Pending, rollout đứng hoặc phải hạ Pod cũ trước	Node allocatable, Pending reason, scheduler events, quota
Readiness sai	Traffic vào Pod chưa warm-up hoặc dependency chưa usable	Probe latency, endpoint count, 5xx, startup/readiness transitions
Termination quá nhanh	Connection bị reset, request đang chạy mất	Graceful TERM, preStop khi cần, drain duration, in-flight request count
Schema/app không tương thích	Old/new version chạy song song nhưng fail	Expand/contract migration, compatible API/event schema
Single replica	Dễ có gap dù rollout config “đẹp”	Replicas, topology spread, SLO requirement và maintenance plan

PodDisruptionBudget (PDB) chủ yếu giới hạn voluntary disruptions do cluster administration. Đừng xem PDB là cơ chế điều khiển Deployment rolling update. Với workload có quorum, budget cần phản ánh số replica tối thiểu thực sự cần để hệ thống còn hoạt động.

5. Jobs

Job dành cho finite work. Pod của Job có thể được retry hoặc thậm chí cùng chương trình có thể được khởi động hơn một lần trong một số tình huống, vì vậy task và external side effect cần idempotent hoặc có deduplication/reconciliation.

Dùng backoffLimit để giới hạn retry; với Indexed Job có thể có policy theo index.
Dùng activeDeadlineSeconds nếu cần time bound cho toàn Job.
podFailurePolicy cho phép phân biệt lỗi nên retry, bỏ qua hoặc fail Job.
Khi debug, lưu log tập trung; Pod failed có thể bị thay thế và history có thể được cleanup.

CronJob

CronJob tạo Job theo schedule. Cần quyết định concurrencyPolicy (Allow, Forbid hoặc Replace), startingDeadlineSeconds, history limits và timeZone. Scheduling là approximate: có trường hợp Job có thể được tạo hai lần hoặc không được tạo, nên task vẫn cần idempotency.

Operational rule: monitor không chỉ trạng thái Succeeded/Failed mà cả job age, missed schedule, retry count, execution duration, queue/backlog ngoài Kubernetes và side-effect reconciliation.

6. Rollback

Rollback Deployment chỉ đưa Pod template về revision trước. Nó không tự rollback database schema/data, message đã publish, email đã gửi, payment/external API side effect hoặc Config/Secret bên ngoài revision đó.

Giữ image digest, manifest/config version và rollout history có thể truy vết.
Dùng migration theo hướng forward/backward compatible; ưu tiên expand → deploy → contract thay vì migration phá vỡ tức thời.
Định nghĩa trigger rollback bằng SLI: error rate, latency, saturation, crash/restart, business conversion hoặc synthetic check.
Nếu rollback app không thể đảo side effect, chuẩn bị forward-fix, compensation và reconciliation runbook.
Sau rollback, xác minh cả Kubernetes state và business evidence; không dừng ở việc Pod lại Ready.

7. Production checklist

Controller phù hợp với identity, placement và completion semantics.
Requests/limits và cluster capacity có headroom cho surge và một failure domain.
Readiness/startup/liveness probe có trách nhiệm rõ; không dùng liveness để che dependency outage dài.
ServiceAccount/RBAC theo least privilege; image digest/scanning/policy phù hợp threat model.
Metrics/alerts có rollout progress, unavailable replicas, Pending, restart/crash, error rate và latency.
Job/CronJob idempotent hoặc có deduplication; missed schedule và retry có bounded impact.
Rollback/recovery bao gồm data/schema/external effect, không chỉ Pod template.

Tài liệu tham khảo: Workload Controllers · Deployments · StatefulSets · DaemonSet · Jobs · CronJob · PodDisruptionBudget