Bài 10 — Container Service — ECS, GKE, AKS

Mở đầu — vì sao bài này quan trọng

Ở bài trước, chúng ta đã hiểu về VM — máy chủ ảo là "viên gạch" hạ tầng cơ bản nhất trên cloud. Nhưng nếu bạn từng deploy một ứng dụng thật, bạn sẽ nhanh chóng gặp một câu hỏi khó chịu: "Tôi có container rồi (đóng gói bằng Docker), giờ chạy nó ở đâu, và ai sẽ trông coi nó chạy cho đúng?"

Bạn có thể tự dựng một con VM, cài Docker, rồi docker run. Nhưng chuyện gì xảy ra khi container chết lúc 2 giờ sáng? Ai khởi động lại nó? Khi lượng truy cập tăng gấp 10 lần vào dịp sale 12/12, ai tự động thêm container mới? Khi bạn deploy phiên bản mới mà không muốn website "sập" một giây nào, ai điều phối việc thay thế từng container một cách mượt mà?

Đó chính xác là công việc của container orchestration — điều phối container. Và ba dịch vụ trọng tâm của bài học hôm nay — ECS (AWS), GKE (Google), AKS (Azure) — là những dịch vụ được quản lý (managed) giúp bạn làm việc đó mà không phải tự tay dựng và vận hành cả một hệ thống điều phối phức tạp.

Đây là một trong những bài quan trọng bậc nhất của khóa học, vì gần như mọi công ty công nghệ hiện đại tại Việt Nam — từ startup fintech đến sàn thương mại điện tử — đều đang chạy hệ thống của họ dưới dạng container trên cloud. Nắm vững phần này, bạn sẽ tự tin bước vào 80% các cuộc phỏng vấn DevOps.

Khái niệm cốt lõi

Container orchestration là gì và tại sao cần "được quản lý"

Hãy tưởng tượng một nhà hàng. Container giống như từng món ăn đã được đóng hộp sẵn, đầy đủ nguyên liệu, chạy giống hệt nhau ở mọi nơi. Nhưng để phục vụ hàng nghìn khách, bạn cần một quản lý bếp — người quyết định nấu bao nhiêu suất, phân bổ suất nào cho bàn nào, thay thế món hỏng, và tăng ca khi đông khách. Container orchestration chính là "người quản lý bếp" đó.

Cụ thể, một hệ thống điều phối container lo giúp bạn:

• Scheduling — quyết định container nào chạy trên máy chủ (node) nào, sao cho tận dụng tài nguyên tốt nhất.
• Self-healing — tự khởi động lại container khi nó chết, thay thế node hỏng.
• Scaling — tự tăng/giảm số lượng container theo tải.
• Rolling update — cập nhật phiên bản mới từng phần, không gây gián đoạn.
• Service discovery & load balancing — giúp các container tìm thấy nhau và phân phối lưu lượng.

Cụm từ "managed" (được quản lý) rất quan trọng. Nó có nghĩa là nhà cung cấp cloud lo phần control plane — bộ não điều khiển — thay bạn: vá lỗi bảo mật, đảm bảo tính sẵn sàng cao, backup cấu hình. Bạn chỉ tập trung vào việc chạy ứng dụng của mình.

Phổ dịch vụ: ECS, GKE, AKS và những người anh em

Điểm mấu chốt cần khắc cốt ghi tâm: GKE và AKS đều dựa trên Kubernetes — một chuẩn mã nguồn mở đã trở thành "ngôn ngữ chung" của ngành. Còn ECS là công nghệ độc quyền của riêng AWS, không phải Kubernetes.

Sự khác biệt này quyết định rất nhiều thứ về sau, nên hãy phân tích kỹ.

ECS — đơn giản, gọn gàng, nhưng "khóa" vào AWS

ECS ra đời trước cả khi Kubernetes phổ biến. Triết lý của nó là: đơn giản hóa tối đa cho những ai đã ở trong hệ sinh thái AWS. Bạn định nghĩa một Task Definition (giống như bản thiết kế mô tả container của bạn: image gì, cần bao nhiêu CPU/RAM, mở cổng nào), rồi tạo một Service để chạy và duy trì số lượng bản sao mong muốn.

ECS có hai chế độ chạy:

• EC2 launch type — bạn tự quản lý cụm máy chủ EC2 làm nơi chứa container. Rẻ hơn nhưng bạn phải lo bảo trì máy.
• Fargate launch type — chế độ "serverless container". Bạn không cần biết đến máy chủ nào cả; chỉ cần khai báo container, AWS tự lo phần hạ tầng. Đây là lựa chọn được yêu thích nhất hiện nay vì nhẹ đầu.

Ưu điểm lớn nhất của ECS là đường cong học tập thấp và tích hợp cực chặt với các dịch vụ AWS khác (IAM, ALB, CloudWatch). Nhược điểm: bạn bị vendor lock-in — nếu sau này muốn chuyển sang Google Cloud hay Azure, kiến thức và cấu hình ECS gần như không dùng lại được.

GKE — "vua Kubernetes" và mức độ tự động hóa cao nhất

Kubernetes vốn do chính Google phát triển và mở mã nguồn, nên không ngạc nhiên khi GKE thường được đánh giá là dịch vụ Kubernetes được quản lý trưởng thành và tự động hóa tốt nhất.

GKE có hai chế độ vận hành:

• Standard — bạn kiểm soát cấu hình node pool (nhóm máy chủ), phù hợp khi cần tùy chỉnh sâu.
• Autopilot — Google lo toàn bộ node; bạn chỉ khai báo workload (pod), và trả tiền theo tài nguyên pod thực sự dùng. Rất giống triết lý "chỉ lo ứng dụng".

Với GKE, bạn làm việc bằng các khái niệm Kubernetes chuẩn: Pod (đơn vị nhỏ nhất chứa một hoặc vài container), Deployment (quản lý số bản sao và rolling update), Service (điểm truy cập ổn định), Ingress (định tuyến HTTP từ bên ngoài vào).

AKS — Kubernetes cho thế giới doanh nghiệp Microsoft

AKS về mặt kỹ thuật rất giống GKE vì cùng chạy Kubernetes chuẩn. Điểm mạnh riêng của AKS là tích hợp sâu với hệ sinh thái Microsoft: Azure Active Directory (nay là Entra ID) cho phân quyền, Azure DevOps cho CI/CD, và các công cụ giám sát của Azure. Với những doanh nghiệp Việt Nam vốn đã dùng nhiều sản phẩm Microsoft (Office 365, Windows Server), AKS là con đường tự nhiên.

Một điểm dễ chịu: AKS không tính phí cho control plane ở tầng tiêu chuẩn — bạn chỉ trả tiền cho các node worker. Đây từng là lợi thế cạnh tranh so với EKS của AWS (vốn tính phí control plane theo giờ).

ECS hay Kubernetes? Khung quyết định

Đây là câu hỏi kinh điển. Hãy dùng khung tư duy đơn giản:

• Nếu bạn chỉ dùng AWS, đội nhỏ, muốn nhanh và ít việc vận hành → ECS (Fargate).
• Nếu bạn cần tính di động (không muốn lệ thuộc một nhà cung cấp), có nhu cầu phức tạp (nhiều service, service mesh, cấu hình tinh vi), hoặc đội ngũ đã có kỹ năng Kubernetes → GKE / AKS / EKS.
• Kubernetes có sức mạnh và độ linh hoạt vượt trội, nhưng "đổi lại" bằng độ phức tạp cao hơn hẳn.

Tình huống thực tế

Ví dụ 1 — Startup fintech Sài Gòn chọn ECS Fargate để đi nhanh

Một startup ví điện tử tại TP.HCM (gọi là "PayFast", 12 kỹ sư) cần lên sản phẩm trong 4 tháng. Họ đã dùng AWS cho database (RDS) và lưu trữ (S3). Đội DevOps chỉ có... 1 người rưỡi.

Ban đầu, họ cân nhắc EKS (Kubernetes trên AWS) vì "ai cũng nói Kubernetes là chuẩn". Nhưng sau hai tuần vật lộn với YAML, Ingress controller và cấu hình mạng, họ nhận ra: đội quá nhỏ để nuôi một cụm Kubernetes. Họ chuyển sang ECS Fargate.

Kết quả: mỗi microservice (auth, wallet, notification) trở thành một ECS Service với Task Definition đơn giản. Fargate lo hạ tầng, họ không phải vá server. Chi phí hạ tầng khoảng 900 USD/tháng cho giai đoạn đầu, và quan trọng hơn — người DevOps duy nhất có thể ngủ ngon vì ECS tự khởi động lại container chết và tự scale khi có cao điểm giao dịch buổi tối.

Bài học: Với đội nhỏ đã "cắm rễ" trong AWS, ECS Fargate giúp bạn ra thị trường nhanh hơn. Đừng chọn Kubernetes chỉ vì nó "thời thượng" — hãy chọn theo năng lực đội ngũ.

Ví dụ 2 — Sàn thương mại điện tử chọn GKE vì cần scale và tính di động

Một sàn TMĐT tầm trung ở Đông Nam Á (giả định "ShopSEA", ~2 triệu người dùng) chạy hàng chục microservice: tìm kiếm, giỏ hàng, thanh toán, khuyến nghị sản phẩm. Đội kỹ thuật 60 người, đã quen Kubernetes.

Họ chọn GKE Standard. Lý do:

• Vào các đợt flash sale, lượng truy cập tăng vọt gấp 8–10 lần trong vài phút. GKE với Horizontal Pod Autoscaler tự nhân bản pod của service "giỏ hàng" từ 20 lên 180 chỉ trong khoảng 2 phút.
• Họ dùng service mesh (Istio) để quản lý lưu lượng giữa các service — thứ mà ECS làm không tiện.
• Ban lãnh đạo lo ngại lệ thuộc một nhà cung cấp, nên chọn Kubernetes để giữ khả năng chuyển sang cloud khác nếu cần đàm phán giá.

Cái giá phải trả: họ phải nuôi một đội Platform 4 người chuyên lo cụm GKE, cùng chi phí học tập đáng kể. Nhưng với quy mô đó, sự linh hoạt của Kubernetes hoàn toàn xứng đáng.

Bài học: Ở quy mô lớn, nhiều service, có nhu cầu autoscale mạnh và muốn tránh vendor lock-in, Kubernetes được quản lý (GKE/AKS/EKS) là lựa chọn đúng — miễn là bạn đủ người để vận hành.

Ví dụ 3 — Doanh nghiệp truyền thống dùng AKS vì đã "sống" trong Microsoft

Một tổng công ty bảo hiểm tại Hà Nội đang hiện đại hóa hệ thống. Toàn bộ nhân viên dùng Microsoft 365, hệ thống nội bộ chạy trên Windows Server và .NET, việc phân quyền dựa trên Azure Active Directory.

Khi container hóa ứng dụng tính phí bảo hiểm, họ chọn AKS gần như tự động. Lý do: nhân viên đăng nhập cụm bằng chính tài khoản Entra ID sẵn có (không cần dựng hệ thống phân quyền riêng), pipeline CI/CD chạy trên Azure DevOps, và giám sát bằng Azure Monitor — tất cả "ăn khớp" trong một cổng quản trị duy nhất. Việc không mất phí control plane cũng giúp phòng tài chính dễ duyệt ngân sách.

Bài học: Việc chọn dịch vụ container không chỉ là kỹ thuật thuần túy. Hệ sinh thái sẵn có, kỹ năng đội ngũ, và mối quan hệ với nhà cung cấp đều là yếu tố quyết định. AKS tỏa sáng khi tổ chức đã đầu tư sâu vào Microsoft.

Hướng dẫn từng bước

Dưới đây là quy trình khái quát để đưa một ứng dụng container hóa lên dịch vụ managed, minh họa bằng ECS Fargate (đơn giản nhất để bắt đầu). Tư duy tương tự áp dụng cho GKE/AKS.

• Đóng gói ứng dụng thành container image. Viết Dockerfile, build image, và đẩy lên một registry (ví dụ Amazon ECR). Đây là điều kiện tiên quyết cho mọi dịch vụ container.

• Định nghĩa "bản thiết kế" workload. Trên ECS, tạo Task Definition khai báo: image nào, cần bao nhiêu vCPU/bộ nhớ, biến môi trường, cổng container. (Trên Kubernetes, đây tương đương file Deployment YAML mô tả pod và số bản sao.)

• Tạo cụm/tài nguyên chạy. Với Fargate, chỉ cần tạo một ECS Cluster (không cần khai báo máy chủ). Với GKE/AKS, bạn tạo cluster và (nếu là chế độ Standard) khai báo node pool.

• Tạo Service để duy trì trạng thái mong muốn. Khai báo "tôi muốn luôn có 3 bản sao chạy". Orchestrator sẽ đảm bảo con số này — bản nào chết sẽ được thay thế.

• Gắn load balancer để nhận lưu lượng. Nối service với một Application Load Balancer (ECS) hoặc Ingress/Service LoadBalancer (Kubernetes) để người dùng bên ngoài truy cập được.

• Cấu hình autoscaling. Đặt quy tắc: khi CPU vượt 70%, tự thêm bản sao. Đây là bước biến hệ thống thành "co giãn tự động".

• Kết nối giám sát và log. Bật CloudWatch (ECS) / Cloud Monitoring (GKE) / Azure Monitor (AKS) để theo dõi sức khỏe và gom log.

• Thiết lập triển khai an toàn. Cấu hình rolling update (hoặc blue/green) để deploy phiên bản mới mà không gây gián đoạn dịch vụ.

Lỗi thường gặp & mẹo

• Chọn Kubernetes chỉ vì "trend". Đây là sai lầm phổ biến nhất của các startup Việt Nam. Kubernetes rất mạnh nhưng "ngốn" nhân lực vận hành. Nếu đội bạn dưới 15 người và chỉ dùng AWS, hãy nghiêm túc cân nhắc ECS Fargate trước.

• Quên đặt resource limits (CPU/RAM). Nếu không giới hạn, một container "ăn" hết tài nguyên có thể làm chết cả node, kéo theo các container khác. Luôn khai báo request và limit rõ ràng.

• Bỏ qua health check. Nếu không cấu hình health check đúng, orchestrator không biết container của bạn "sống nhưng bị treo" (ví dụ ứng dụng vẫn chạy nhưng không phản hồi request). Hãy phân biệt liveness (còn sống không) và readiness (đã sẵn sàng nhận traffic chưa).

• Xem nhẹ chi phí Fargate ở quy mô lớn. Fargate rất tiện nhưng đơn giá cao hơn tự quản lý EC2. Ở tải ổn định và lớn, chạy ECS trên EC2 hoặc GKE Standard có thể rẻ hơn đáng kể.

• Không tách môi trường. Đừng chạy chung dev/staging/production trong một cluster mà không cô lập (namespace, tài khoản riêng). Sự cố ở dev có thể lan sang production.

• Mẹo vàng: Hãy giữ ứng dụng của bạn stateless (không lưu trạng thái cục bộ trong container). Dữ liệu cần lưu nên đẩy ra database, object storage hay cache bên ngoài. Container có thể bị giết và tạo lại bất cứ lúc nào — đây là nguyên tắc sống còn của thế giới container.

Bài tập thực hành

• So sánh và quyết định. Cho ba bối cảnh: (a) startup 8 người dùng AWS làm app giao đồ ăn; (b) tập đoàn 500 nhân viên dùng Microsoft 365 làm hệ thống nội bộ; (c) công ty game 100 kỹ sư cần chạy trên nhiều cloud để tránh lệ thuộc. Hãy chọn ECS, GKE hay AKS cho từng bối cảnh và viết 2–3 câu lý giải.

• Vẽ sơ đồ khái niệm. Vẽ tay (hoặc dùng công cụ vẽ) mối quan hệ giữa: Cluster → Service → Task/Pod → Container, và chỉ ra load balancer đứng ở đâu.

• Ánh xạ thuật ngữ. Lập bảng đối chiếu ba cột: khái niệm ECS (Task, Service) tương ứng với khái niệm Kubernetes (Pod, Deployment/Service). Điều này giúp bạn di chuyển giữa các nền tảng dễ dàng.

• Tình huống sự cố. Container của bạn liên tục khởi động rồi chết (restart loop). Hãy liệt kê 4 nguyên nhân khả dĩ và cách kiểm tra từng nguyên nhân (gợi ý: xem log, kiểm tra health check, resource limit, biến môi trường thiếu).

• Ước tính chi phí (nâng cao). Giả sử bạn chạy 5 container, mỗi container 0.5 vCPU và 1GB RAM, hoạt động 24/7. Hãy tra bảng giá Fargate hiện tại và ước tính chi phí tháng, rồi so sánh với việc tự chạy trên một EC2 instance đủ lớn.

Tóm tắt

• Container orchestration giải quyết bài toán chạy và trông coi container ở quy mô lớn: scheduling, self-healing, scaling, rolling update.
• ECS là orchestrator độc quyền của AWS — đơn giản, học nhanh, tích hợp chặt với AWS, nhưng lock-in. Chế độ Fargate giúp chạy container không cần quản lý máy chủ.
• GKE (Google) và AKS (Azure) đều dựa trên Kubernetes — chuẩn mở, linh hoạt, di động, nhưng phức tạp và tốn nhân lực vận hành. EKS là bản Kubernetes tương ứng của AWS.
• Khung quyết định: đội nhỏ + chỉ AWS → ECS Fargate; quy mô lớn, nhiều service, cần tính di động → Kubernetes (GKE/AKS/EKS); đã sống trong hệ sinh thái Microsoft → AKS.
• Việc chọn dịch vụ phụ thuộc vào kỹ năng đội ngũ, hệ sinh thái sẵn có và quy mô — không chỉ là kỹ thuật thuần túy. Và dù chọn gì, hãy luôn thiết kế ứng dụng stateless để tận dụng tối đa sức mạnh của container.