Greenfield EKS: Nên chọn Standard EKS hay EKS Auto Mode cho dự án mới?

Khi bạn bắt đầu xây dựng cụm Amazon EKS đầu tiên và không phải mang theo những năm tháng tích lũy các module Terraform, AMI tùy chỉnh hay chiến lược node bắt buộc từ đội ngũ khác, sự lựa chọn giữa Standard EKS (bạn tự quản lý cách cung cấp và kết nối node) và EKS Auto Mode (AWS vận hành phần lớn việc đó thay bạn) chủ yếu xoay quanh các tùy chọn mặc định: tốc độ và ủy quyền vận hành so với tính minh bạch và kiểm soát chi tiết.

Bài viết này là cẩm nang ra quyết định thực tế cho kịch bản "greenfield" (dự án mới hoàn toàn) — những điểm khác biệt, cách cân nhắc về chi phí và bảo trì, cũng như cách tách biệt mô hình vận hành EKS khỏi các bổ sung (add-ons) tùy chọn mà bạn cài đặt lên trên.

Tổng quan

Hướng dẫn này giúp bạn quyết định cho một cụm cluster mới không bị ràng buộc bởi hệ thống cũ:

• Cái mà Standard EKS và EKS Auto Mode tối ưu hóa trong những tuần và tháng đầu tiên.
• Cách so sánh chi phí ở mức độ cao (control plane, tính toán, phí quản lý Auto Mode và thời gian con người).
• Ai chịu trách nhiệm cho gì (nodes, scaling, ingress/LB), bao gồm danh sách kiểm tra được AWS tài liệu hóa về những gì Auto Mode quản lý như cơ sở hạ tầng tích hợp sẵn.
• Một tiêu chí ngắn gọn để "mặc định chọn Auto Mode" so với "bắt đầu rõ ràng với Managed Node Groups".

Đặt tên cho hai con đường khởi đầu

Cùng một control plane được quản lý; ai sở hữu câu chuyện về node mới là thứ chia cắt các con đường.

So sánh trực tiếp

Tiêu chí	Standard EKS	EKS Auto Mode
Bạn chọn	Cách tạo và mở rộng quy mô node: Managed Node Groups, self-managed nodes, hoặc sau này là Karpenter.	Ít tự kết nối (DIY) hơn; AWS vận hành nhiều hơn về vòng đời + tích hợp.
Mô hình tư duy	"Đây là các instance / ASG của tôi, đường mở rộng quy mô và nâng cấp của tôi".	"Tự động hóa theo kiểu AWS; ít nút điều chỉnh (knobs) hơn, ít lắp ráp hơn".
API bạn sẽ thấy	EC2, MNG, launch templates, cộng với bất kỳ công cụ cung cấp nào bạn chọn.	Các CRD hướng nền tảng như NodePool / NodeClaim, NodeClass, CNINode, các loại liên quan đến LB...

Luồng trách nhiệm

Trong Standard EKS, AWS quản lý Kubernetes API, nhưng bạn chọn chiến lược node (MNG, self-managed, Karpenter) và quản lý Workloads/Pods.

Trong EKS Auto Mode, AWS quản lý Kubernetes API và cả vòng đời node + các tích hợp (theo quan điểm có sẵn), bạn chỉ quản lý Workloads/Pods.

Lưu ý quan trọng: Quan sát, sao lưu, bí mật, RBAC, chính sách mạng, ingress và mesh vẫn là trách nhiệm của bạn trong cả hai chế độ. Việc chọn một chế độ không đồng nghĩa với việc đã sẵn sàng cho môi trường sản xuất (production-ready).

Chi phí thoáng qua

Giá cả có thể thay đổi; hãy luôn đối chiếu với trang giá Amazon EKS. Các con số dưới đây sử dụng mức giá On-Demand tại US West (Oregon) vào thời điểm viết bài cho một kịch bản greenfield nhỏ: một cụm, ba worker nodes (m5a.xlarge).

Ước tính hóa đơn hàng tháng của AWS

Mục	Mức giá	Standard EKS	Auto Mode
Control plane	$0.10 / cluster / hr	~$73	~$73
EC2 instances (3 x m5a.xlarge)	$0.172 / instance / hr	~$377	~$377
Quản lý Auto Mode	$0.02064 / instance / hr	--	~$45
Tổng hóa đơn AWS		~$450	~$495

Trong kịch bản này, Auto Mode thêm khoảng 10-12% vào hóa đơn AWS. Phí quản lý được tính theo giây (tối thiểu một phút) và áp dụng bất kể lựa chọn mua EC2 (On-Demand, Reserved, Savings Plan hay Spot).

Cảnh báo về hỗ trợ mở rộng (Extended Support). Nếu bạn để phiên bản Kubernetes trôi qua thời hạn hỗ trợ tiêu chuẩn (14 tháng), phí cụm sẽ nhảy vọt lên $0.60 / hr (~$438 / tháng). Hãy lập kế hoạch nâng cấp bất kể chế độ nào bạn chọn.

Những gì hóa đơn không hiển thị

Chi phí ẩn	Standard EKS	EKS Auto Mode
Thời gian kỹ sư xây dựng tự động hóa node, biểu đồ Helm cho controller LB, sổ tay nâng cấp	Cao hơn — bạn xây dựng và duy trì phần "keo dán"	Thấp hơn — AWS cung cấp sẵn phần keo đó
Chi phí sự cố khi node hoạt động sai, AMI trôi hay scaling bị kẹt	Bạn chịu trách nhiệm debug từ đầu đến cuối	Chia sẻ với AWS; ít đòn bẩy hơn nhưng cũng ít bộ phận chuyển động do bạn viết ra
Dung lượng nhàn rỗi từ việc cung cấp dư (over-provision)	Rủi ro nếu bạn đặt giới hạn scaling lỏng lẻo	Rủi ro nếu mặc định của Auto Mode quá hào phóng với workload của bạn

Kết luận: Phí quản lý ~$45 / tháng trong ví dụ này tương đương khoảng một giờ chi phí tải của một kỹ sư nền tảng. Nếu Auto Mode giúp tiết kiệm nhiều hơn thế nhờ giảm bớt công việc vặt mỗi tháng, nó tự hoàn vốn. Nếu đội của bạn đã có tự động hóa vững chắc và hiếm khi can thiệp vào node, Standard sẽ giữ hóa đơn gọn gàng hơn.

Ai vận hành cái gì — và cảm giác năm đầu tiên như thế nào

Sự lựa chọn thể hiện ở sự phân chia lao động: ai giữ cho nodes, scaling, và lưu lượng vào cụm khỏe mạnh. Đó là thứ lấp đầy lịch trình của bạn trong tháng thứ sáu đến thứ mười hai — lập kế hoạch nâng cấp và biểu đồ Helm ở một phía, thay đổi nền tảng AWS và các trường hợp hỗ trợ ở phía kia — không phải là một huy hiệu "chế độ" trừu tượng.

Công việc thuộc về ai?

Lĩnh vực	Standard EKS (greenfield điển hình)	EKS Auto Mode
Nodes và Scaling	Bạn chọn cơ chế — Managed Node Groups, self-managed nodes, hoặc Karpenter — và bạn sở hữu việc nâng cấp, hành vi, và tinh chỉnh dung lượng.	AWS cung cấp trải nghiệm node và scaling tích hợp hơn; bạn căn chỉnh với các đối tượng và thực hành Kubernetes mà AWS tài liệu hóa cho Auto Mode thay vì tự lắp ráp stack đó.
Ingress và Load Balancers	Các đội thường cài đặt và vận hành thứ gì đó như AWS Load Balancer Controller — nâng cấp biểu đồ, tính tương thích với phiên bản cụm mới, sự cố khi nhãn hoặc chú thích (annotations) bị sai lệch.	Nhiều phần tích hợp đó do AWS vận hành trong Auto Mode, vì vậy bạn thường tốn ít thời gian hơn để chăm sóc phần đó — vẫn cần đọc ghi chú phát hành AWS khi nền tảng thay đổi.

Checklist cơ sở hạ tầng được quản lý bởi Auto Mode

AWS mô tả các thành phần này là năng lực tích hợp sẵn của cụm, không phải là các tiện ích bổ sung riêng biệt trong bảng điều khiển EKS mà bạn tự cài đặt và phiên bản hóa.

Tính toán và Nodes:

• Các instance EC2 data-plane (các biến thể dựa trên Bottlerocket): lựa chọn AMI, OS bị khóa (SELinux enforcing, root chỉ đọc), không có SSH hoặc SSM trực tiếp vào nodes.
• Bảo mật và vòng đời: vá lỗi và nâng cấp với sự gián đoạn tối thiểu; tuổi thọ node tối đa (mặc định lên đến 21 ngày) để nodes được thay thế thường xuyên.
• Workload tăng tốc: các trình điều khiển kernel và plugin liên quan đến GPU (ví dụ: NVIDIA và AWS Neuron).
• Spot: xử lý thông báo gián đoạn Spot và tín hiệu sức khỏe instance EC2.

Mở rộng quy mô (Scaling):

• Tự động mở rộng kiểu Karpenter: phản ứng với các Pods không thể lập lịch (unschedulable), thêm dung lượng và loại bỏ hoặc hợp nhất nodes khi nhu cầu giảm.

Cân bằng tải (Load Balancing):

• Elastic Load Balancing gắn với các đối tượng Kubernetes Service và Ingress: cung cấp và quản lý tài nguyên ALB và NLB và mở rộng quy mô chúng theo nhu cầu của cụm.

Mạng lưới (Networking):

• Mạng Pod và Service, bao gồm IPv4/IPv6 và sử dụng các CIDR phụ khi cần cho không gian IP Pod.
• Thực thi chính sách mạng (network policy) cho Pods.
• DNS của cụm (DNS cục bộ cho cụm).

Lưu trữ (Storage):

• Lưu trữ khối lớp EBS CSI dưới dạng năng lực được quản lý.
• Mặc định lưu trữ tạm thời (ephemeral storage) trên nodes (loại volume, kích thước, mã hóa và hành vi dọn dẹp khi chấm dứt).

Danh tính (Identity):

• EKS Pod Identity: bạn không tự cài đặt EKS Pod Identity Agent trên các cụm Auto Mode (AWS tài liệu hóa rằng nó không cần thiết trong mô hình này).

Không chế độ nào mang lại "sản xuất trong một hộp". Các chỉ số, xoay vòng bí mật, mesh, động cơ chính sách, sao lưu và các toán tử cụ thể theo doanh nghiệp vẫn là vòng đời phần mềm của bạn trừ khi bạn áp dụng các dịch vụ được quản lý riêng biệt.

Tiêu chí ra quyết định (Greenfield, không gánh nặng)

Hãy nghiêng về EKS Auto Mode khi:

• Đội ngũ nhỏ và ưu tiên là triển khai một nền tảng container tiêu chuẩn nhanh chóng.
• Workloads là các container Linux tiêu chuẩn mà không có yêu cầu kernel, sysctl hoặc AMI tùy chỉnh kỳ lạ hiện tại.
• Bạn thoải mái áp dụng các API theo kiểu AWS cho nodes và tích hợp trong giai đoạn tăng trưởng tiếp theo.
• Bạn thích có ít bộ phận chuyển động hơn mà bạn phải vá và tinh chỉnh trong năm đầu tiên.

Hãy nghiêng về Standard EKS (thường bắt đầu với Managed Node Groups) khi:

• Bạn muốn tính minh bạch tối đa vào từng lớp cho mục đích đào tạo, nền tảng tuân thủ hoặc kỷ luật đa đám mây.
• Bạn đã biết mình cần các họ instance cụ thể, lựa chọn mua hoặc giới hạn chi phí nghiêm ngặt được mã hóa rõ ràng từ ngày đầu tiên.
• Bạn kỳ vọng chuẩn hóa một câu chuyện cung cấp node nội bộ hoặc cộng đồng (ví dụ: Karpenter bạn kiểm soát hoàn toàn) và muốn học mô hình đó mà không có một lớp quản lý bổ sung.

Gợi ý mặc định cho một đội ngũ sản phẩm greenfield thực sự: Nếu rủi ro chính của bạn là giao hàng chậm và quá tải vận hành, EKS Auto Mode thường là mặc định khởi đầu tốt hơn; nếu rủi ro chính của bạn là hiểu và sở hữu mọi phụ thuộc vì lý do quy định hoặc nghề nghiệp, Standard EKS với Managed Node Groups là con đường học tập rõ ràng. Bạn có thể xem xét lại lựa chọn sau khi đội ngũ có lưu lượng truy cập sản xuất thực tế và các chỉ số.

Khắc phục sự cố: Những hiểu lầm phổ biến

• "Auto Mode là Kubernetes hơn." Nó là nhiều tự động hóa được quản lý bởi AWS hơn được hiển thị qua các API Kubernetes, không phải là tập hợp của mọi tiện ích bổ sung tùy chọn.
• "Standard thì rẻ hơn." Các mục hóa đơn có thể thấp hơn; tổng chi phí có thể không thấp hơn một khi bạn tính đến thời gian kỹ sư và sự cố cho một đội ngũ nhỏ.
• "Chúng tôi đã chọn một chế độ, nên chúng tôi an toàn và có thể quan sát." RBAC, chính sách mạng, bí mật, kiểm toán và giám sát vẫn là lựa chọn thiết kế của bạn.
• "Cụm Standard của chúng tôi có nhiều bộ phận hơn, nên nó phải tốt hơn." Thường đó là nhiều phần mềm tùy chọn bạn đã thêm vào — không phải bằng chứng cho thấy Standard đánh bại Auto Mode.

Tài liệu tham khảo

• What is Amazon EKS?
• Amazon EKS pricing
• EKS Auto Mode
• Learn how EKS Auto Mode works
• Amazon EKS best practices
• Managed node groups
• Karpenter