EKS: Cũng là kubernetes, nhưng nó lạ lắm.

Hello mọi người, hôm nay, chúng ta sẽ cùng nhau đi vào tìm hiểu một hòn đá tảng trong làng DevOps – EKS nhé.

Trước tiên thì nói một cách đơn giản, EKS không so sánh được với Kubernetes, vì Kubernetes nó là một platform rồi, còn EKS thì chỉ là một Service sử dụng Kubernetes thôi. Tuy nhiên thì vì nó cũng có vài điểm khác biệt dành cho một người từ K8S thuần sử dụng thì phải lưu ý.

Managed Control Plane

Ai đã từng học hay làm việc với K8S rồi, thì chắc là đã từng nghe đến khái niệm control plane. Trong K8S, control plane là các node, làm nhiệm vụ quản lý và điều khiển các Node, Pod và là nơi có thể “tiếp nhận” luồng điều khiển. Thế nhưng mà EKS, nó lại quản lý luôn cái control plane giúp mình các bạn ạ. Thế có nghĩa là sao ? Thế có nghĩa là để truy cập tới cluster và điều khiển các thành phần, chúng ta phải dùng phương án khác chứ không có dùng Control Plane được.

Mô hình một hệ thống EKS:

Tại đây, chúng ta không nhìn thấy control plane xuất hiện ở đâu cả, các thành phần EKS điều khiển mà chúng ta có thể nhìn thấy chỉ là EKS Worker Node. Vì EKS quản lý hết control plane, nên chúng ta có thể sử dụng EKS Console trên giao diện AWS để truy cập vào, sau đó xem xét các thông tin/thành phần. 

Mặc dù giao diện của EKS trên Console có thể xem các thành phần, nhưng mà lại không tiện cho việc sử dụng, vì để chạy hay thao tác trên cluster thì chúng ta phải thao tác với cluster bằng các câu lệnh hoặc bằng API.

Để bắt đầu làm việc với cluster, chúng ta sẽ cần Connect tới cluster. Đối với EKS, thì đơn giản nhất là chúng ta sử dụng kubectl kết hợp với AWS CLI, và chạy lệnh update kube-config là được:

Chúng ta cài đặt kubectl và AWS CLI, sau đó sử dụng lệnh

aws eks –region <region-name> update-kubeconfig –name <cluster-name>

Sau khi chạy lệnh này, file ~/.kube/config sẽ được cập nhật để chúng ta sử dụng cluster. Và các bạn có thể sử dụng kubectl cho EKS cluster bình thường.

Người bình thường (người làm k8s trên on prem) thường hơi bối rối khi mới tiếp xúc với EKS lần đầu, vì nó quen mà sao lạ thế. Thực thì ra thì vẫn là nó, chỉ có đôi chút khác nhau thôi.

Tạo cluster mà không nhìn thấy, không có quyền.

Đây là một lỗi tương đối phổ biến ở trên EKS, vấn đề thường là do sự khác biệt về hiểu biết khi sử dụng Kubernetes và EKS. Đối với EKS, khi khởi tạo cluster, chủ thể IAM khởi tạo cluster sẽ là đối tượng có quyền full access vào cluster. 

Ví dụ, nếu bạn khởi tạo cluster trên giao diện của Console, thì tài khoản đang đăng nhập để khởi tạo Console sẽ có quyền truy cập và thao tác với Cluster. Còn nếu bạn khởi tạo cluster bằng eksctl nằm trên một instance đã được gắn role nào đó, thì role đó sẽ được quyền truy cập và thao tác với Cluster. Lúc này, rắc rối mới bắt đầu xuất hiện.

Nếu chúng ta tạo EKS bằng AWS Console, thì tài khoản của chúng ta có quyền đấy, nhưng chúng ta sẽ hơi lú lú chẳng biết truy cập kiểu gì. Thực tình là mình cũng chưa nghĩ ra cách gì để cấp quyền hay truy xuất vào cluster nếu khởi tạo bằng Console. Nếu AWS mà cho mình cái command line kết nối trực tiếp vào cluster luôn ở trên Console thì ngon. Nhưng AWS say No, tạo cluster xong, chúng ta vẫn phải mò vào chủ thể IAM nào vừa tạo để chúng ta còn cấp quyền vì hiện chỉ có duy nhất chủ thể đó nhìn thấy. Ai mà tạo bằng tài khoản root, thì lại lóc cóc đi cấp quyền access key để vào tài khoản root, thao tác trên đó, xong lại xóa Access key đi cho đúng best practice.

Trong doc của AWS nói phần này chưa được rõ ràng lắm, nên mọi người có thể sẽ dễ bị nhầm, chúng ta muốn access bằng host đang sử dụng role/user nào, thì nên tạo bằng role/user đó nhé, kiểu gì cũng cần access vào cluster để còn phân quyền.

Quyền ở đây là phân quyền kép tức là sẽ bao gồm cả quyền của IAM role/user và Role/ClusterRole nằm trong Cluster. IAM role/user cho phép access vào kubernetes và nhìn thấy các resource. Nhưng người dùng kubernetes thì muốn mỗi user/role chỉ nhìn thấy một namespace thôi. Chúng ta sẽ cần tạo các role/cluster role trong cluster trước, bind với một group (kubernetes group), sau đó thêm một IAM user/role và map sang group tương ứng trong kubernetes. 

Mọi người làm kubernetes đã quen với việc thiết lập Role/RoleBinding/ClusterRole/ClusterRoleBinding rồi, nhưng trên EKS, chúng ta sẽ cần thiết lập thêm cả IAM user nữa nhé.

Quản lý compute resource.

Điểm nữa khác biệt giữa EKS và Kubernetes self manage cluster là Node Group. Node Group là một khái niệm của EKS, thể hiện các instance nằm trong một Auto Scaling Group (ASG) nào đó.

EKS có 3 loại compute resource trong EKS gồm:

• Self managed node: Cái này nếu mọi người đọc ở đâu đó thì sẽ bị lẫn vì bản thân cái self managed node này lại có 2 loại. Kiểu đơn giản thì là một cái node từ EC2 instance, được join vào trong cluster thôi. Tuy nhiên là thường nếu ở trên cloud EKS thì rất ít người sử dụng thuần một vài node cụ thể, trừ khi join vào một vài hệ thống nằm dưới on prem thì người ta sẽ dùng AWS Outpost hoặc AWS EKS Anywhere để join thủ công vào cluster. Trên cloud phổ biến nhất sẽ dùng self managed node group. Self managed node group thì về mặt node, nó không khác gì một EC2 instance hay 1 node nào đó thông thường, chỉ có điều nó nằm trong 1 Auto Scaling Group (ASG). Và lưu ý là EKS KHÔNG quản lý ASG này. Để chúng ta phân biệt với một loại thứ 2:
• EKS managed node group: Đây cũng là một loại node group trong một ASG nào đó, nhưng ASG này được quản lý bởi EKS. Loại compute resource này có một vài tính năng tương đối là ổn đối như taint cả mấy nodes trong node group, chỉnh sửa, update bootstrap script, quản lý số lượng node theo % bị fail, … Một vài tính năng trong số này có thể sử dụng với self managed node group. Tuy nhiên điểm trừ của nó là bị giới hạn một số loại AMI nhất định. Có thể dùng bottlerocket, nhưng chúng ta sẽ nói đến bottlerocket trong một chuyên mục khác sau.
• Fargate: Fargate thì không phải nói rồi, cái loại này được AWS buff rất nhiều, khen là nhiều ưu điểm các thứ, manage luôn cả instance và tính giá theo Serverless. Nhưng mà đối với kubernetes thì nhiều khi không phải chỉ đơn giản là chạy cho nó lên, mà phải đào bới xới lộn sâu sâu tầng thấp hơn 1 chút, như quản lý namespace và cụm compute resource. Fargate với mỗi pod sẽ tạo ra một “node” để chúng ta có thể tương tác với nó và tính tiền như thật. Nói chung thì cũng khá là nhanh, gọn.

Kết luận:

Túm lại thì EKS cũng sử dụng K8S, nhưng khi sử dụng, chúng ta cần lưu ý 1 vài điểm khác biệt so với những kiến thức K8S thông thường để tránh bị bỡ ngỡ. Chúc mọi người vui, happy learning.

Để hiểu rõ hơn về service EKS, mời các độc giả tham khảo ngay thông tin khóa học DevOps on K8S : https://codestar.vn/product/khoa-hoc-kubernetes-fundamentals-k8s/

Tham khảo thêm nội dung khóa Devops on AWS : https://codestar.vn/product/devops-on-aws/

Và khóa học AWS Practical giúp bạn nắm vững kiến thức và cách sử dụng các service trên hệ thống AWS : https://codestar.vn/product/aws-co-ban/