Khi nào Docker Compose không còn đủ? Chuyển sang Kubernetes hoặc Docker Swarm
Docker Compose khi nào không còn đủ? So sánh Kubernetes và Docker Swarm về multi-host, self-healing, scaling, rolling update, networking, secrets và lộ trình migration production.
ShanverseUpdated 10 min read— viewsLoading views
Docker
Docker Compose
Kubernetes
Docker Compose thực sự giải quyết điều gì?
Compose biến một tập lệnh chạy container thành cấu hình khai báo:
Nó phù hợp cho:
Local development và integration test.
Demo, staging nhỏ hoặc internal tool.
Một ứng dụng nhỏ/vừa chạy trên một VPS.
Stack có downtime chấp nhận được và scale theo chiều dọc.
Team muốn vận hành đơn giản, backup rõ ràng và ít moving parts.
Một VPS với Compose, reverse proxy, healthcheck, backup, monitoring và deploy theo Image digest có thể phục vụ production ổn định. Số container không phải tiêu chí duy nhất để chuyển sang Kubernetes.
Tín hiệu Compose bắt đầu không còn đủ
Comments
1. Một host trở thành single point of failure
Nếu VPS hỏng, mọi container trên đó cùng biến mất. restart: unless-stopped có thể khởi động lại process trên host còn sống, nhưng không thể chuyển workload sang máy khác.
Bạn cần orchestrator khi mục tiêu là:
Node chết nhưng service vẫn chạy ở node khác.
Bảo trì host mà không dừng toàn hệ thống.
Phân tán replica qua nhiều availability zone hoặc failure domain.
2. Cần scheduling trên nhiều node
Compose không có scheduler cluster để quyết định workload chạy ở đâu dựa trên CPU, memory, label, affinity hoặc topology.
3. Cần rolling update và rollback có kiểm soát
docker compose up -d thay container nhưng không tự tạo chiến lược production đầy đủ cho nhiều node, traffic draining, surge capacity hoặc availability budget.
4. Scale thủ công gây quá tải vận hành
Compose có thể tăng replica trong một số trường hợp, nhưng vẫn bị giới hạn bởi một host và không có autoscaling metrics-based hoàn chỉnh. Khi traffic biến động mạnh, orchestrator có thể điều chỉnh replica hoặc capacity theo policy.
5. Networking và service discovery phức tạp
Nhiều service, nhiều team và nhiều environment thường cần:
Service discovery xuyên node.
Load balancing nội bộ.
Network policy theo least privilege.
Ingress/gateway quản lý domain, TLS và routing tập trung.
6. Cần governance cho nhiều team
RBAC, namespace, quota, policy, audit và workload identity trở nên quan trọng khi một cluster phục vụ nhiều team hoặc nhiều ứng dụng.
7. Mức độ tự động hóa vượt khỏi shell script
Nếu deploy script chứa hàng loạt logic để chọn host, kiểm tra replica, drain traffic, retry, rollback và tự sửa lỗi, bạn đang tự xây một orchestrator chưa hoàn chỉnh.
Khi nào chưa nên chuyển?
Đừng chọn Kubernetes chỉ vì:
Có 5–10 container.
Muốn “chuẩn DevOps”.
Thấy doanh nghiệp lớn đều dùng K8s.
Muốn giải quyết application bug bằng hạ tầng.
Tiếp tục dùng Compose khi:
Một host đủ capacity và downtime có thể chấp nhận.
Team nhỏ, không có người vận hành cluster.
Chi phí và độ đơn giản quan trọng hơn autoscaling.
Workload chủ yếu stateful và chưa có chiến lược storage/backup tốt.
Monitoring, CI/CD và recovery hiện tại còn chưa ổn định.
Container orchestration bổ sung những gì?
Mermaid
Loading diagram…
Orchestrator liên tục so sánh desired state với actual state:
Replica thiếu → tạo replica mới.
Container lỗi → thay thế.
Node chết → schedule workload sang node còn sống.
Version đổi → rollout theo policy.
Health chưa đạt → chưa đưa vào traffic.
Kubernetes và Docker Swarm: khác nhau cốt lõi
Chọn Docker Swarm khi nào?
Swarm hợp lý khi:
Team đã quen Compose và muốn ít khái niệm mới.
Cluster nhỏ, topology đơn giản.
Cần multi-host, service discovery, secrets và rolling update cơ bản.
Không cần ecosystem Kubernetes, operators hoặc policy phức tạp.
Chấp nhận scale theo thao tác hoặc automation tự xây.
Swarm được tích hợp trong Docker Engine:
Manager duy trì cluster state; worker chạy task. Production cần số manager lẻ—thường 3 hoặc 5—để duy trì quorum. Không expose manager API ra Internet.
Từ Compose sang Swarm Stack
Ví dụ stack.yml:
Tạo secret và deploy:
Khác biệt cần lưu ý với Compose
docker stack deploy dùng Image đã build; không nên phụ thuộc vào build:.
Mỗi node phải pull được Image từ Registry.
depends_on không phải cơ chế readiness phân tán; application cần retry dependency.
Bind mount yêu cầu path tồn tại nhất quán trên node, nên dễ gây lỗi scheduling.
Local volume gắn với node; muốn workload di chuyển cần shared/distributed storage hoặc external service.
Một số field của Compose không có cùng semantics trong Swarm; phải test bằng stack thực tế.
Update và rollback Swarm
Rollback container version không rollback schema database.
Chọn Kubernetes khi nào?
Kubernetes phù hợp khi:
Có nhiều service, team hoặc environment.
Cần managed cluster trên EKS, GKE, AKS hoặc nền tảng tương đương.
Cần autoscaling, policy, RBAC, workload identity và network control.
Muốn GitOps, service mesh, operators hoặc ecosystem cloud-native.
Hệ thống cần chạy lâu dài và platform team có khả năng vận hành.
Chi phí chính là complexity: control plane, networking, storage, upgrades, observability, manifests, security policy và incident response.
Mapping từ Compose sang Kubernetes
Manifest Kubernetes tối thiểu
readinessProbe quyết định Pod có nhận traffic hay không; livenessProbe cho phép restart container bị kẹt; startupProbe bảo vệ app khởi động chậm. Không dùng cùng một phép kiểm tra sâu cho mọi probe.
Những thứ converter không thể tự quyết định
Công cụ như Kompose có thể tạo manifest khởi đầu, nhưng không hiểu:
SLO và downtime budget.
Storage class/failure domain.
Security boundary và network policy.
Requests/limits thực tế.
Migration database.
Pod disruption budget.
Ingress, TLS, DNS và observability chuẩn tổ chức.
Dùng converter để bootstrap, không coi output là production-ready.
State và database là phần khó nhất
Container stateless di chuyển khá dễ; dữ liệu thì không.
Trước migration:
Ưu tiên managed PostgreSQL/Redis/Object Storage khi phù hợp.
Xác định RPO/RTO và kiểm thử restore.
Không giả định local volume sẽ đi theo container sang node khác.
Kiểm tra access mode, topology và snapshot của storage class.
Tách database migration thành Job/one-off task có lock.
Thiết kế migration backward-compatible theo expand/contract.
Lộ trình chuyển đổi an toàn
Giai đoạn 1: làm sạch Compose hiện tại
Image immutable, deploy theo digest.
App stateless; file người dùng đưa vào object storage.
Health endpoint tách startup/readiness/liveness semantics.
Config và secret nằm ngoài Image.
Log ra stdout/stderr.
Graceful shutdown khi nhận SIGTERM.
Resource usage được đo trước khi đặt limits.
Giai đoạn 2: chọn target theo nhu cầu
Cần multi-host đơn giản → đánh giá Swarm.
Cần ecosystem, governance và managed service dài hạn → Kubernetes.
Chỉ cần host mạnh hơn → có thể vẫn dùng Compose và vertical scaling.
Giai đoạn 3: dựng non-production cluster
Deploy một stateless service trước.
Tạo CI/CD hoặc GitOps promotion theo digest.
Test node failure, rollout, rollback và secret rotation.
Đo latency, CPU/memory và thời gian recovery.
Giai đoạn 4: chạy song song
Mermaid
Loading diagram…
Bắt đầu traffic nhỏ, so sánh metrics/logs, rồi tăng dần. Tránh big-bang migration nếu hệ thống quan trọng.
Giai đoạn 5: cutover và decommission
Freeze thay đổi hạ tầng trong cửa sổ cutover.
Backup và xác minh restore point.
Chuyển traffic với rollback window rõ ràng.
Giữ Compose environment trong thời gian ngắn nếu dữ liệu cho phép rollback.
Decommission credential, DNS, volume và host cũ có kiểm soát.
CI/CD thay đổi ra sao?
Compose pipeline:
Swarm pipeline:
Kubernetes pipeline:
Tách build khỏi deploy. Không cấp cluster-admin cho CI nếu chỉ cần update một workload. Với Kubernetes, ưu tiên short-lived identity/OIDC và RBAC theo namespace.
Anti-pattern khi migration
Copy Compose sang YAML mới mà không thay đổi application readiness.
Đưa database vào cluster trước khi có storage/backup expertise.
Dùng latest thay digest.
Không đặt requests khiến scheduler thiếu dữ liệu.
Đặt limits tùy ý gây throttling/OOM.
Liveness probe kiểm tra dependency bên ngoài, tạo restart storm.
Cho mọi service gọi nhau vì thiếu NetworkPolicy.
Cấp CI quyền cluster-admin.
Cài quá nhiều add-on trước khi chạy workload đầu tiên.
Chuyển cả hệ thống một lần và không có đường rollback.
Ma trận quyết định nhanh
Checklist trước khi rời Compose
Có requirement cụ thể mà Compose không đáp ứng.
Team định lượng được availability, RPO và RTO.
Image immutable và có private Registry.
Application stateless hoặc state đã được externalize.
1build → push → update manifest/Helm digest2→ GitOps/controller apply → rollout status → smoke test
Codeplain text
1Compose → đơn giản, một host, ownership rõ2Swarm → bước chuyển nhẹ sang multi-host orchestration3Kubernetes → nền tảng mạnh cho scale, governance và ecosystem
Hướng dẫn Live Reload và Hot Reload với Docker Compose cho Node.js, TypeScript, Vite và Next.js: bind mounts, Compose Watch, node_modules, polling, quyền file và debug.
Hướng dẫn Docker Compose cho Node.js với hai cấu hình docker-compose.yml hoàn chỉnh: PostgreSQL và MongoDB, kèm healthcheck, service discovery, volume, bảo mật và debug.
