Bài 4: Cơ sở hạ tầng Kubernetes AutoScale

Giới thiệu

AWS Elastic Kubernetes Service (EKS) là một dịch vụ mạnh mẽ giúp triển khai Kubernetes trên AWS nhanh chóng và hiệu quả. Tuy nhiên, để tận dụng tối đa EKS, chúng ta cần thiết kế hạ tầng một cách tối ưu, đảm bảo khả năng mở rộng và tiết kiệm chi phí. Trong bài viết này, chúng ta sẽ tập trung vào:

1. Triển khai EKS trên nhiều tài khoản.
2. Cấu hình mở rộng EKS với Cluster Autoscaler và Karpenter.
3. Sử dụng Node hiệu quả để tối ưu chi phí.

Triển khai EKS trên từng tài khoản AWS

Ở bài viết trước, chúng ta đã đề cập cách sử dụng Terraform để triển khai hạ tầng trên nhiều tài khoản AWS. Với EKS, cấu trúc thư mục Terraform cho môi trường nonprod có thể như sau:

└── nonprod-terraform
    ├── data-nonprod
    │   ├── dev
    │   │   ├── eks
    ├── networking-nonprod
    │   ├── dev
    │   │   ├── eks
    ├── observability-nonprod
    │   ├── dev
    │   │   ├── eks
    ├── operation-nonprod
    │   ├── dev
    │   │   ├── eks
    └── workload-nonprod
        ├── dev
        │   ├── eks

Mỗi tài khoản AWS sẽ có cụm EKS riêng, được quản lý thông qua Terraform, đảm bảo hạ tầng được đồng bộ và dễ dàng tái sử dụng.

EKS AutoScale

Sau khi tạo EKS trên từng tài khoản xong, vấn đề tiếp theo cần quan tâm là cấu hình mở rộng cho EKS như thế nào. AWS EKS gồm hai phần chính là Control Plane do AWS quản lý và EKS Node Group (là các EC2 mà Kubernetes Pod triển khai lên). Thành phần cần mở rộng là Node Group. Trước khi nói về cách mở rộng Node Group ta xem qua các kỹ thuật mở rộng ứng dụng trong Kubernetes, gồm 4 cách:

• Application Tuning: mở rộng process trong một Pod hoặc tối ưu bằng code
• Horizontal Pod Autoscaling: mở rộng theo chiều ngang, thêm số lượng Pod
• Vertical Pod Autoscaling: mở rộng theo chiều dọc, tăng CPU hoặc Memory của Pod
• Cluster Autoscaling: mở rộng theo chiều ngang, thêm số lượng Node

Ở bài này mình tập trung chính vào Cluster Autoscaling. Còn về Horizontal Pod Autoscaling thì các bạn tham khảo Kubernetes Event-driven Autoscaling, Vertical Pod Autoscaling thì tham khảo Vertical Pod Autoscaler.

Cluster Autoscaler

Cluster Autoscaling

EKS cung cấp hai giải pháp mở rộng Cluster:

• Cluster Autoscaler: hoạt động dựa trên Auto Scaling Groups (ASG)
• Open-source Karpenter: làm việc trực tiếp với Amazon EC2 Instances

Cả Cluster Autoscaler và Karpenter đều thực hiện mở rộng bằng cách điều chỉnh số lượng EC2 trong Node Group. Nếu một Pod mới được triển khai mà số lượng EC2 hiện tại không đủ, AutoScaler sẽ tự động tạo thêm EC2. Tương tự, khi số lượng Pod giảm, nếu EC2 không có Pod nào triển khai lên thì AutoScaler sẽ tự động xóa EC2 đó để tiết kiệm tài nguyên.

Tuy nhiên, Cluster Autoscaler là giải pháp đầu tiên để mở rộng EKS nên nó có một vài giới hạn. Cluster Autoscaler hoạt động dựa trên ASG, ASG hoạt động dựa trên Launch Template. Với mỗi Launch Template, ta chỉ có thể định nghĩa một loại EC2 Instance Type, mỗi loại Instance Type thì dính cứng CPU và Memory. Do đó thường dẫn tới tình trạng thừa tài nguyên khi mở rộng Node Group.

Ví dụ, trong ASG, chúng ta sử dụng loại EC2 m5a.large (2 vCPUs – 8 GiB). EKS hiện đang triển khai 16 Pod, mỗi Pod cần 0.5 vCPUs và 2 GiB, chúng ta cần 4 EC2 m5a.large. Khi hệ thống nhận nhiều yêu cầu, Kubernetes tự động mở rộng thêm một Pod. Tuy nhiên, do số lượng EC2 không đủ, Cluster AutoScaler sẽ tạo thêm một EC2 mới. Vì sử dụng ASG nên EC2 được tạo ra phải là loại m5a.large. Pod mới sẽ được triển khai trên EC2 mới này. Do mỗi Pod chỉ cần 0.5 vCPUs và 2 GiB nên chúng ta còn dư tới 1.5 vCPUs và 6 GiB tài nguyên.

Karpenter

Karpenter là một open-source được phát triển bởi AWS, Karpenter cũng thực hiện điều chỉnh số lượng EC2 khi Pod được triển khai, nhưng Karpenter không hoạt động dựa trên ASG mà làm việc trực tiếp với EC2, nên nó sẽ tạo EC2 theo cách tối ưu tài nguyên nhất.

Như hình trên ta có ví dụ sau, 5 Pod (0.75 vCPUs 1.5 GiB) ở trạng thái pending cần triển khai. Số lượng EC2 hiện tại là 2 con (1 vCPU 2GiB) nên mỗi Pod chỉ có thể triển khai lên 1 con EC2, ta còn 3 Pod pending, nếu dùng Cluster Autoscaler thì ta cần thêm 3 con EC2 và tài nguyên dư thừa là 1.25 vCPU (0.25 vCPU mỗi EC2). Còn Karpenter thì ban đầu để đảm bảo ít bị trì hoãn nhất khi triển khai Pod, nó sẽ tìm kiếm con EC2 phù hợp để triển khai được 3 Pod còn lại. Sau khi toàn bộ Pod được triển khai thì Karpenter có thêm thời gian tính toán tiếp và chọn lại các con EC2 tối ưu nhất để triển khai Pod, sau khi EC2 mới được tạo thì nó sẽ khởi tạo Pod ở EC2 mới, sau đó mới xóa mấy con EC2 cũ đi. Tham khảo bài này để hiểu rõ hơn về Karpenter: Getting Started.

Với hạ tầng EKS mới nên xài Karpenter để tối ưu cost nhất, còn đối với những hạ tầng EKS cũ nếu có thời gian ta có thể migrate Cluster Autoscaler qua Karpenter. Hạ tầng Vikki sử dụng Karpenter để mở rộng EKS.

Sử dụng Node hiệu quả để tiết kiệm chi phí

AWS cung cấp 4 mô hình định giá EC2:

• On-Demand Instances: Trả phí theo giờ, phù hợp cho các workload quan trọng, không chịu downtime.
• Savings Plans và Reserved Instances: Mua gói giảm giá, tiết kiệm 20-30% hoặc hơn.
• Spot Instances: Tiết kiệm tới 90%, nhưng có thể bị thu hồi bất kỳ lúc nào.

Kết hợp On-Demand và Spot Instances

Trong môi trường nonprod (DEV, UAT), chúng ta có thể sử dụng Spot Instances cho các workload không yêu cầu cao về tính sẵn sàng. Trong môi trường prod, cần cẩn trọng hơn:

• On-Demand: Dành cho các ứng dụng quan trọng (vd: kube-system namespace).
• Spot Instances: Dành cho các ứng dụng có thể chịu downtime ngắn (vd: CI/CD cho workload).

Tối ưu với Karpenter

Karpenter hỗ trợ chạy kết hợp On-Demand và Spot Instances:

• Node Group On-Demand: Chạy các ứng dụng quan trọng như Karpenter Controller để đảm bảo không bị downtime.
• Node Group Spot Instances: Chạy các ứng dụng ít quan trọng hơn để tiết kiệm chi phí.

Chiến lược giảm downtime khi dùng Spot Instances:

• Spread Constraints: Đảm bảo Pods được phân phối trên nhiều EC2 khác nhau.
• Node Termination Handler: Xử lý trước khi Spot Instances bị thu hồi, giảm thiểu ảnh hưởng.

Ví dụ về CI/CD:

• CI/CD cho workload: Có thể dùng Spot Instances vì các bước như lint, test, build đều có thể chạy lại nếu bị gián đoạn.
• CI/CD cho data: Nên dùng On-Demand Instances vì các tác vụ như migrate dữ liệu rất quan trọng, không thể gián đoạn.

Kết luận

Việc triển khai và mở rộng EKS trong môi trường Multi AWS Accounts đòi hỏi sự cân nhắc kỹ lưỡng để đảm bảo hiệu quả chi phí và khả năng mở rộng. Sử dụng Karpenter cho hạ tầng mới là lựa chọn tối ưu nhất, trong khi các hạ tầng cũ có thể cân nhắc migrate từ Cluster Autoscaler sang Karpenter.

Ở bài viết tiếp theo, chúng ta sẽ tìm hiểu cách ứng dụng trong EKS giao tiếp giữa các tài khoản khác nhau.

Trích: Quân Huỳnh – Cloud Engineer, Tác giả trang devopsvn.tech