Bài 43 — Managed Kubernetes — EKS, GKE, AKS

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

Nếu bạn đã đi qua các bài về container và Kubernetes, hẳn bạn đã nghe câu nói kinh điển trong giới DevOps: "Kubernetes rất mạnh, nhưng vận hành nó thì không dành cho người yếu tim." Câu này không hề phóng đại. Một cụm (cluster) Kubernetes tự dựng (self-hosted) đầy đủ gồm hai phần: control plane (bộ não điều khiển) và worker nodes (nơi chạy ứng dụng). Phần control plane mới là chỗ khiến các đội kỹ thuật đau đầu nhất — nó bao gồm API server, scheduler, controller manager, và đặc biệt là etcd, cơ sở dữ liệu lưu toàn bộ trạng thái của cụm.

Tưởng tượng bạn là kỹ sư duy nhất phụ trách hạ tầng của một startup fintech ở TP.HCM. Một buổi sáng thứ Bảy, etcd của bạn bị hỏng dữ liệu vì đĩa đầy, và bạn không có bản backup gần nhất. Toàn bộ cụm "quên" mất mình đang chạy những gì. Đó là cơn ác mộng có thật. Đây chính là lý do vì sao Managed Kubernetes — dịch vụ Kubernetes được nhà cung cấp cloud quản lý — ra đời và trở thành lựa chọn mặc định cho phần lớn doanh nghiệp ngày nay.

Trong bài này, chúng ta sẽ tập trung vào ba dịch vụ managed Kubernetes lớn nhất: EKS (AWS), GKE (Google Cloud) và AKS (Azure). Bạn sẽ hiểu chính xác "managed" nghĩa là nhà cung cấp làm giúp bạn phần nào, bạn vẫn phải tự lo phần nào, chi phí ra sao, và làm thế nào để chọn đúng dịch vụ cho hoàn cảnh của mình. Đây là kiến thức nền tảng mà bất kỳ ai làm DevOps trên cloud tại Việt Nam cũng cần nắm vững, vì hầu hết các công ty tech đang tuyển đều yêu cầu kinh nghiệm với ít nhất một trong ba nền tảng này.

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

Managed Kubernetes thực chất là gì

Bản chất của managed Kubernetes rất đơn giản: nhà cung cấp cloud sẽ vận hành control plane thay cho bạn. Cụ thể, họ chịu trách nhiệm:

• Chạy và bảo trì API server, scheduler, controller manager với chế độ High Availability (nhiều bản sao ở nhiều vùng khả dụng khác nhau, tránh single point of failure).
• Quản lý etcd: sao lưu tự động, mã hóa, phục hồi khi hỏng.
• Vá lỗi bảo mật (security patch) cho control plane.
• Cung cấp cơ chế nâng cấp phiên bản Kubernetes (version upgrade) an toàn hơn.

Còn bạn — phía khách hàng — vẫn phải chịu trách nhiệm:

• Quản lý worker nodes: chọn loại máy, số lượng, khi nào scale.
• Cấu hình mạng, security group, IAM cho ứng dụng.
• Triển khai và vận hành workload (các Deployment, Service, Ingress...).
• Giám sát (monitoring), logging, và tối ưu chi phí.

Nói cách khác, managed Kubernetes giải phóng bạn khỏi "phần khó nhất và ít giá trị kinh doanh nhất" (vận hành control plane), để bạn dồn sức vào "phần tạo ra giá trị" (chạy ứng dụng). Đây là mô hình trách nhiệm chia sẻ (shared responsibility) rất đặc trưng của cloud.

Chi phí control plane — con số bạn cần nhớ

Một điểm thực tế cần nắm rõ về giá. Phần lớn dịch vụ managed tính phí control plane theo giờ:

• EKS: khoảng 0,10 USD/giờ cho mỗi cluster, tức khoảng 72 USD/tháng cho riêng control plane (chưa tính worker nodes). Từ 2024, AWS còn phân tầng "extended support" cho các phiên bản cũ với giá cao hơn (khoảng 0,60 USD/giờ).
• AKS: control plane miễn phí ở tier tiêu chuẩn (Free tier), chỉ trả tiền cho worker nodes. Nếu muốn cam kết SLA cao hơn (Standard tier với 99,95% uptime), bạn trả thêm khoảng 0,10 USD/giờ/cluster.
• GKE: tính phí quản lý cụm khoảng 0,10 USD/giờ/cluster (~72 USD/tháng), nhưng có một cụm Autopilot hoặc một zonal cluster được miễn phí quản lý mỗi tháng tùy chương trình. GKE cũng có hai chế độ vận hành riêng biệt (xem bên dưới).

Con số 70–100 USD/tháng cho control plane nghe có vẻ nhỏ, nhưng với một startup chạy 20 microservice tách thành 20 cluster riêng, đó là 1.400–2.000 USD/tháng chỉ riêng phí control plane. Đây là lý do người ta khuyên gộp nhiều workload vào ít cluster hơn, dùng namespace để phân tách thay vì tách cluster.

Ba dịch vụ, ba triết lý khác nhau

EKS (Amazon Elastic Kubernetes Service) thiên về tính linh hoạt và tích hợp sâu với hệ sinh thái AWS (IAM, VPC, ALB). Điểm mạnh là ổn định, thị phần lớn, cộng đồng đông. Điểm yếu là cấu hình ban đầu khá "thủ công" — bạn phải tự dựng nhiều thứ như networking (thường qua công cụ eksctl hoặc Terraform), và trải nghiệm setup không mượt bằng GKE.

GKE (Google Kubernetes Engine) được xem là "chuẩn vàng" về trải nghiệm, vì Google chính là nơi khai sinh Kubernetes. GKE có hai chế độ:

• Standard mode: bạn tự quản lý node pool, giống EKS/AKS.
• Autopilot mode: Google quản lý luôn cả worker nodes — bạn chỉ khai báo pod cần bao nhiêu CPU/RAM, Google lo phần còn lại và tính tiền theo tài nguyên pod thực dùng. Đây là bước tiến gần với "serverless Kubernetes".

AKS (Azure Kubernetes Service) hấp dẫn nhất về giá control plane (miễn phí tier cơ bản) và tích hợp cực mạnh với hệ sinh thái Microsoft (Azure AD/Entra ID, Azure DevOps). Rất phù hợp cho doanh nghiệp đã dùng nhiều sản phẩm Microsoft.

Node group / Node pool — nơi bạn thực sự quản lý

Dù dùng dịch vụ nào, khái niệm bạn làm việc nhiều nhất là node group (EKS gọi vậy) hay node pool (GKE/AKS gọi vậy). Đây là nhóm các máy ảo cùng cấu hình tạo thành các worker node. Một cụm thường có nhiều node pool: ví dụ một pool máy thường cho workload chung, một pool máy có GPU cho AI, một pool máy spot/preemptible (giá rẻ, có thể bị thu hồi) cho các job có thể chịu gián đoạn. Cách bạn tổ chức node pool ảnh hưởng trực tiếp đến chi phí và độ ổn định.

Tình huống thực tế

Tình huống 1: Startup thương mại điện tử chuyển từ self-hosted sang EKS

Một công ty e-commerce tầm trung ở Hà Nội (giả định tên "ChợViệt") ban đầu tự dựng Kubernetes bằng kubeadm trên các VM thuê. Đội DevOps gồm 3 người. Trong 8 tháng, họ gặp 2 sự cố lớn: một lần etcd hỏng do đĩa đầy khiến cụm sập 4 tiếng đúng ngày sale, một lần nâng cấp Kubernetes từ 1.24 lên 1.25 làm hỏng CNI (network plugin) khiến pod không giao tiếp được, mất nửa ngày khắc phục.

Diễn giải: Sau khi tính toán, họ nhận ra 3 kỹ sư đang dành khoảng 30% thời gian chỉ để "giữ cho cụm sống", thay vì làm tính năng. Họ chuyển sang EKS. Chi phí control plane tăng thêm khoảng 72 USD/tháng, nhưng đổi lại AWS lo toàn bộ HA của control plane và etcd backup. Việc nâng cấp phiên bản giờ chỉ là vài cú click với node group được thay thế cuốn chiếu (rolling replacement).

Bài học rút ra: Đừng tính chi phí managed Kubernetes chỉ bằng con số hóa đơn cloud. Hãy tính cả chi phí cơ hội của kỹ sư. 72 USD/tháng rẻ hơn rất nhiều so với việc một kỹ sư giỏi phải thức đêm cứu etcd.

Tình huống 2: Đội ngũ nhỏ chọn GKE Autopilot để khỏi lo node

Một nhóm 4 người xây dựng ứng dụng SaaS quản lý phòng khám, phục vụ thị trường Đông Nam Á. Họ không có ai chuyên sâu về hạ tầng — tất cả đều là developer. Họ chọn GKE Autopilot.

Diễn giải: Với Autopilot, họ không phải nghĩ về "cần bao nhiêu node, loại máy gì, khi nào scale node". Họ chỉ khai báo mỗi microservice cần bao nhiêu CPU/RAM, và Google tự cấp phát tài nguyên, tự scale, tự vá node. Chi phí được tính theo tài nguyên pod thực dùng (requested resources), nên khi ít traffic ban đêm, hóa đơn tự giảm. Trong tháng đầu, hóa đơn compute khoảng 340 USD — hơi cao hơn Standard mode một chút nếu tính trên cùng workload, nhưng họ tiết kiệm được thời gian không phải tinh chỉnh node.

Bài học rút ra: Với đội nhỏ, thiếu chuyên gia hạ tầng, mô hình "càng ít thứ để quản lý càng tốt" thường thắng về tổng chi phí sở hữu (TCO), dù đơn giá tính toán có thể nhỉnh hơn. Autopilot đánh đổi một chút chi phí lấy sự an tâm.

Tình huống 3: Doanh nghiệp lớn dùng AKS vì đã "cắm rễ" vào Microsoft

Một tập đoàn bán lẻ có hệ thống ERP chạy trên nền Microsoft, dùng Active Directory cho toàn bộ nhân viên, và đội dev quen với Azure DevOps. Khi hiện đại hóa ứng dụng web, họ chọn AKS.

Diễn giải: Lựa chọn này không phải vì AKS "tốt nhất về kỹ thuật", mà vì tích hợp. Nhân viên đăng nhập vào cụm bằng chính tài khoản Entra ID (Azure AD) sẵn có; phân quyền RBAC nối thẳng với nhóm AD. Pipeline CI/CD trên Azure DevOps deploy lên AKS chỉ với vài dòng cấu hình. Control plane miễn phí ở tier cơ bản giúp họ tiết kiệm khi chạy nhiều cụm cho các môi trường dev/staging/prod tách biệt.

Bài học rút ra: Việc chọn nhà cung cấp managed Kubernetes hiếm khi là quyết định thuần kỹ thuật. Hệ sinh thái sẵn có, kỹ năng của đội, và tích hợp identity thường quan trọng hơn vài phần trăm hiệu năng. Hãy chọn nền tảng "hợp với dòng chảy hiện tại của tổ chức".

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

Dưới đây là quy trình chung để dựng và chạy một cụm managed Kubernetes, minh họa với EKS (các bước tương tự cho GKE/AKS, chỉ khác tên công cụ).

• Chuẩn bị điều kiện tiên quyết. Cài đặt kubectl (công cụ dòng lệnh của Kubernetes) và CLI của nhà cung cấp (aws cho EKS, gcloud cho GKE, az cho AKS). Với EKS, cài thêm eksctl để đơn giản hóa việc tạo cụm.

• Thiết kế mạng trước. Quyết định cụm sẽ nằm trong VPC nào, dùng những subnet nào, ở mấy vùng khả dụng (Availability Zone). Nguyên tắc: đặt node ở tối thiểu 2–3 AZ để đảm bảo tính sẵn sàng cao. Đây là bước hay bị bỏ qua nhưng quyết định độ ổn định về sau.

• Tạo control plane. Với eksctl, chỉ cần một câu lệnh khai báo tên cụm, vùng, và phiên bản Kubernetes. Nhà cung cấp sẽ dựng control plane HA trong vài phút đến khoảng 15 phút. Bạn không đụng gì đến etcd — đó là điểm mấu chốt của "managed".

• Tạo node pool / node group. Khai báo loại instance (ví dụ t3.large), số node tối thiểu/tối đa, và bật auto-scaling. Cân nhắc tạo thêm một pool dùng máy spot cho workload chịu được gián đoạn để tiết kiệm 60–90% chi phí compute.

• Kết nối kubectl vào cụm. Chạy lệnh cập nhật kubeconfig (ví dụ aws eks update-kubeconfig). Sau đó kubectl get nodes để xác nhận các node đã "Ready".

• Cài các thành phần nền tảng. Thường gồm: Ingress controller (hoặc dùng ALB Controller của AWS), cert-manager cho HTTPS, và một giải pháp giám sát. Nhiều nhóm dùng Helm để cài các thành phần này.

• Triển khai ứng dụng. Viết manifest (Deployment, Service, Ingress) hoặc dùng Helm chart, rồi kubectl apply. Kiểm tra pod chạy ổn với kubectl get pods.

• Thiết lập quy trình nâng cấp. Lên lịch nâng cấp phiên bản Kubernetes định kỳ (mỗi phiên bản chỉ được hỗ trợ khoảng 12–14 tháng). Nâng control plane trước, rồi cuốn chiếu thay thế node.

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

Lỗi 1: Tách quá nhiều cluster. Nhiều nhóm tạo mỗi microservice một cluster "cho sạch sẽ". Kết quả là hóa đơn control plane phình to và việc vận hành nhân lên. Mẹo: dùng namespace và RBAC để phân tách trong một cụm, chỉ tách cluster khi có yêu cầu cô lập thật sự (ví dụ prod và dev, hoặc yêu cầu tuân thủ).

Lỗi 2: Quên nâng cấp phiên bản đến khi bị ép. Kubernetes chỉ hỗ trợ mỗi phiên bản khoảng hơn một năm. Để quá hạn, bạn bị đẩy vào "extended support" đắt đỏ (EKS) hoặc bị buộc nâng cấp gấp. Mẹo: coi việc nâng cấp là công việc định kỳ mỗi quý, không phải "khi nào rảnh".

Lỗi 3: Không đặt resource requests/limits cho pod. Trên Autopilot, việc này quyết định thẳng hóa đơn; trên Standard, nó ảnh hưởng scheduler đặt pod ở đâu và có gây "node đói tài nguyên" không. Mẹo: luôn khai báo requests hợp lý dựa trên đo đạc thực tế.

Lỗi 4: Dùng toàn máy on-demand. Đây là cách đốt tiền nhanh nhất. Mẹo: kết hợp máy on-demand cho workload cốt lõi và máy spot/preemptible cho workload stateless, có thể chịu gián đoạn (batch job, worker xử lý hàng đợi).

Lỗi 5: Bỏ qua IAM/identity ngay từ đầu. Việc cấp quyền cho pod truy cập tài nguyên cloud (như S3, Cloud Storage) nếu làm sai sẽ tạo lỗ hổng bảo mật. Mẹo: dùng cơ chế gắn danh tính riêng cho từng service (IRSA trên EKS, Workload Identity trên GKE, Workload Identity trên AKS) thay vì gắn quyền rộng cho cả node.

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

• So sánh giá. Lập một bảng tính cho kịch bản: bạn chạy 3 cluster (dev, staging, prod), mỗi cluster có 3 worker node loại phổ thông. Tính riêng phần chi phí control plane hàng tháng cho EKS, GKE Standard và AKS (Free tier). Nhận xét: nếu chỉ xét control plane, nền tảng nào rẻ nhất và vì sao?

• Vẽ sơ đồ trách nhiệm. Với một cụm managed bất kỳ, hãy liệt kê 8 hạng mục vận hành (etcd backup, vá control plane, chọn loại node, scale node, cấu hình mạng ứng dụng, nâng cấp phiên bản, monitoring, IAM cho pod) và đánh dấu mỗi hạng mục do nhà cung cấp hay bạn phụ trách.

• Ra quyết định. Cho ba tổ chức: (a) startup 4 người không có chuyên gia hạ tầng; (b) công ty đã dùng toàn bộ hệ sinh thái Microsoft; (c) đội DevOps giàu kinh nghiệm muốn kiểm soát tối đa và tối ưu chi phí. Hãy chọn EKS, GKE (Standard hay Autopilot?) hay AKS cho từng tổ chức và giải thích lý do trong 2–3 câu mỗi trường hợp.

• (Nâng cao) Nếu có tài khoản cloud, hãy dùng eksctl (hoặc gcloud/az) tạo một cụm nhỏ 2 node, deploy một ứng dụng web đơn giản, rồi xóa cụm ngay sau khi thử để tránh phát sinh chi phí. Ghi lại thời gian dựng control plane thực tế.

Tóm tắt

Managed Kubernetes tồn tại để giải quyết đúng một nỗi đau lớn: vận hành control plane (etcd backup, HA, nâng cấp phiên bản) vừa khó, vừa dễ gây sự cố, lại không tạo ra giá trị kinh doanh trực tiếp. Ba dịch vụ lớn — EKS, GKE, AKS — đều lo phần control plane cho bạn với chi phí thường trong khoảng 70–100 USD/tháng/cluster (AKS tier cơ bản còn miễn phí), đổi lại bạn tập trung vào worker node và ứng dụng.

Điểm khác biệt cốt lõi: EKS linh hoạt và tích hợp sâu AWS nhưng setup thủ công hơn; GKE có trải nghiệm mượt nhất và chế độ Autopilot gần như serverless; AKS rẻ về control plane và tích hợp tuyệt vời với hệ sinh thái Microsoft. Việc chọn nền tảng thường phụ thuộc vào hệ sinh thái sẵn có, kỹ năng của đội và nhu cầu identity — không thuần túy là kỹ thuật.

Cuối cùng, hãy nhớ những nguyên tắc vận hành: gộp workload vào ít cluster bằng namespace, nâng cấp phiên bản định kỳ, đặt resource requests đúng, tận dụng máy spot cho workload chịu gián đoạn, và cấu hình identity cho pod ngay từ đầu. Nắm vững những điều này, bạn đã có nền tảng đủ vững để tự tin vận hành Kubernetes trên bất kỳ đám mây nào.