Tag Archives: EKS

Tạo cụm EKS theo cách đơn giản

EKS thường là nơi nhiều người gặp Kubernetes trên AWS lần đầu tiên. Video của TechWorld with Nana đi theo hướng rất thực tế: không sa đà vào triết lý, mà tập trung trả lời một câu hỏi đơn giản hơn nhiều, đó là làm sao tạo một Kubernetes cluster trên Amazon EKS theo cách dễ tiếp cận nhất.

Bài viết này tóm lược lại ý chính của video bằng tiếng Việt, đồng thời bổ sung thêm góc nhìn vận hành để người mới không lầm tưởng rằng tạo được cluster là đã hoàn thành phần khó nhất.

Bạn sẽ học được gì

  • EKS là gì và phù hợp với tình huống nào
  • một flow tạo cluster EKS đơn giản thường gồm những bước nào
  • phần nào là AWS giúp bạn, phần nào bạn vẫn phải tự lo
  • những lỗi tư duy thường gặp khi mới dùng EKS
  • các bài nên đọc tiếp để nối sang kiến trúc container trên AWS

EKS thực chất là gì

Amazon EKS là dịch vụ managed Kubernetes của AWS. Cũng giống các managed service khác, EKS giúp bạn bỏ bớt gánh nặng dựng control plane và tích hợp Kubernetes với hệ sinh thái AWS tốt hơn. Điều hấp dẫn nhất của EKS không chỉ là tạo cluster nhanh, mà là kết nối được với IAM, VPC, load balancer, autoscaling và các dịch vụ khác trong cùng nền tảng.

Với team đã dùng AWS sẵn, điều này giúp hành trình vào Kubernetes mượt hơn nhiều so với việc tự dựng cụm trên EC2 từ đầu.

Một flow tạo EKS dễ hiểu

Nếu bỏ qua chi tiết nhỏ của từng câu lệnh, flow đơn giản để tạo EKS thường gồm:

  • chuẩn bị tài khoản, region và quyền truy cập phù hợp
  • tạo cluster EKS
  • gắn worker node hoặc node group
  • cấu hình `kubectl` để kết nối tới cluster
  • triển khai ứng dụng thử nghiệm để xác minh môi trường hoạt động

Điểm quan trọng ở đây là cluster chỉ thật sự hữu ích khi có node để chạy workload. Nhiều người mới nhìn thấy cluster tạo thành công trong console và nghĩ mọi thứ đã sẵn sàng, nhưng nếu chưa có node group hợp lệ thì bạn vẫn chưa chạy được ứng dụng thực tế.

EKS giúp gì và không giúp gì

EKS giúp bạn đỡ phần control plane, tích hợp bảo mật theo cách quen thuộc của AWS, và tận dụng được nhiều dịch vụ xung quanh. Nhưng nó không tự động giải quyết toàn bộ bài toán nền tảng ứng dụng.

Bạn vẫn cần lo:

  • chiến lược node và autoscaling
  • thiết kế network và IAM cho workload
  • quy trình CI/CD để đưa image vào cluster
  • giám sát log, metric và alert
  • kiểm soát chi phí khi môi trường mở rộng

Đây là lý do EKS phù hợp với tư duy platform engineering hoặc DevOps trưởng thành hơn là tư duy “bấm nút xong là có production”.

Vì sao EKS hấp dẫn với team AWS

EKS đặc biệt hấp dẫn khi hệ thống của bạn đã dùng VPC, IAM, CloudWatch, ECR hoặc các dịch vụ hạ tầng khác trên AWS. Khi đó, Kubernetes không phải một đảo tách biệt mà trở thành một phần của hệ sinh thái đang dùng.

Với người mới, đây là lợi thế lớn vì bạn không phải học lại mọi thứ từ đầu. Nhưng mặt trái là bạn cũng phải hiểu thêm nhiều khái niệm AWS hơn một cluster Kubernetes chung chung.

Những sai lầm thường gặp

  • chỉ tập trung tạo cluster mà quên thiết kế node group hợp lý
  • không kiểm soát IAM nên quyền quá rộng hoặc quá rối
  • không dự trù chi phí cho worker node, load balancer và storage
  • đưa workload lên EKS trước khi có logging và monitoring cơ bản

Nếu mới học, cách tốt nhất là bắt đầu từ một cụm nhỏ, một ứng dụng demo đơn giản, sau đó mới mở rộng dần các lớp như ingress, autoscaling và observability.

Tóm tắt nhanh

  • EKS là managed Kubernetes service của AWS.
  • Nó giúp bạn tăng tốc phần dựng cluster và tích hợp tốt hơn với hệ sinh thái AWS.
  • Tạo được cluster chưa phải là xong, vì node, bảo mật, deploy và giám sát vẫn là phần việc lớn.
  • EKS đặc biệt phù hợp khi team đã có nền tảng AWS từ trước.

Đọc tiếp

Nguồn tham khảo

Các lựa chọn container trên AWS

Khi bước vào hệ sinh thái container trên AWS, người mới rất dễ bị ngợp vì quá nhiều tên dịch vụ xuất hiện cùng lúc: ECS, EKS, Fargate, ECR. Video của TechWorld with Nana làm rất tốt một việc quan trọng, đó là đặt các mảnh ghép này cạnh nhau để thấy chúng không phải các công cụ hoàn toàn tách biệt, mà là các lựa chọn giải quyết những phần khác nhau của bài toán container.

Bài viết này viết lại các ý chính theo cách ngắn gọn, rõ ràng và thực dụng hơn cho người học DevOps bằng tiếng Việt.

Bạn sẽ học được gì

  • ECR, ECS, EKS và Fargate khác nhau ở điểm nào
  • dịch vụ nào quản lý image, dịch vụ nào quản lý workload
  • khi nào nên dùng ECS thay vì EKS
  • vai trò của Fargate trong mô hình serverless cho container
  • cách ghép các dịch vụ này vào một flow triển khai thực tế

Bức tranh lớn trước khi đi vào từng dịch vụ

Trước tiên cần tách bài toán container trên AWS thành hai lớp. Lớp thứ nhất là nơi bạn lưu image. Lớp thứ hai là nơi bạn chạy workload. Nhiều người mới học lẫn hai lớp này với nhau nên cảm thấy mọi thứ rối hơn mức cần thiết.

ECR nằm ở lớp lưu trữ image. ECS và EKS nằm ở lớp điều phối workload. Fargate là cách chạy workload mà bạn không phải trực tiếp quản lý server cho phần compute đó.

ECR: nơi lưu image

ECR là Elastic Container Registry. Hãy nghĩ đơn giản đây là kho chứa image Docker hoặc OCI image trong hệ sinh thái AWS. Khi bạn build một image cho ứng dụng, ECR là nơi rất tự nhiên để đẩy image lên trước khi cho ECS hoặc EKS kéo về chạy.

Nếu team đã dùng AWS nhiều, ECR thường là lựa chọn thuận tay vì quyền truy cập, tích hợp và quy trình đẩy image có thể gắn chặt với pipeline sẵn có.

ECS: điều phối container theo cách đơn giản hơn

ECS là Elastic Container Service. So với EKS, ECS thường dễ tiếp cận hơn cho team chỉ muốn chạy container trên AWS mà chưa cần sức mạnh và độ linh hoạt của Kubernetes. Bạn không phải học toàn bộ mô hình object của Kubernetes, nhưng vẫn có một hệ thống điều phối để chạy, scale và cập nhật container.

Điểm mạnh của ECS là gần với hệ sinh thái AWS, ít khái niệm hơn, và thường phù hợp với team muốn đi nhanh. Điểm đổi lại là ECS ít portable hơn Kubernetes nếu sau này bạn muốn đa cloud hoặc chuyển nền tảng.

EKS: khi bạn cần Kubernetes

EKS là lựa chọn khi bạn muốn chuẩn Kubernetes, cần một mô hình orchestration phổ biến hơn trong thị trường, hoặc muốn nền tảng dễ gắn với tooling Kubernetes rộng lớn hơn. EKS mạnh hơn về mặt tiêu chuẩn và hệ sinh thái, nhưng cũng đòi hỏi nhiều kiến thức hơn.

Nếu bài toán của bạn là “chạy container ổn, đơn giản, nhanh trên AWS”, ECS có thể đủ. Nếu bài toán là “xây nền tảng Kubernetes nghiêm túc”, EKS mới là câu trả lời hợp lý hơn.

Fargate: lớp compute ít phải quản server

Fargate không phải registry và cũng không phải một orchestrator độc lập như ECS hay EKS. Nó là mô hình compute để chạy container mà bạn không phải quản EC2 instance ở mức thông thường. Điều này giúp giảm phần việc quản lý máy chủ, vá hệ điều hành và một số tác vụ vận hành hạ tầng.

Fargate rất hấp dẫn cho những workload vừa và nhỏ, workload theo sự kiện hoặc team muốn giảm mạnh phần vận hành node. Tuy nhiên nó không phải lúc nào cũng rẻ hoặc phù hợp cho mọi kiểu tải lớn.

Một cách ghép dễ nhớ

  • ECR để lưu image
  • ECS hoặc EKS để điều phối workload
  • Fargate để cung cấp compute mà bạn ít phải lo server hơn

Ví dụ, một team có thể build image, đẩy lên ECR, sau đó chạy ứng dụng qua ECS trên Fargate. Một team khác có thể đẩy image lên ECR rồi deploy qua EKS vì họ cần Kubernetes.

Những sai lầm thường gặp

  • nghĩ rằng ECS, EKS, Fargate và ECR là bốn dịch vụ cạnh tranh trực tiếp với nhau
  • chọn EKS chỉ vì thấy Kubernetes đang phổ biến mà chưa rõ nhu cầu thật
  • chọn Fargate nhưng không theo dõi chi phí khi workload tăng đều
  • không tách rõ nơi lưu image với nơi chạy container

Tóm tắt nhanh

  • ECR là nơi lưu image container.
  • ECS và EKS là hai cách điều phối workload container trên AWS.
  • Fargate là mô hình compute ít phải quản server hơn.
  • Lựa chọn đúng phụ thuộc vào độ phức tạp, nhu cầu tiêu chuẩn hóa và khả năng vận hành của team.

Đọc tiếp

Nguồn tham khảo