bởi Vikram Venkataraman, Chandra Vellaichamy, Ganesh Kumar Kattamuri, Gene Ting, và Harpreet Singh | ngày 03, tháng 05, năm 2024 | trong Amazon Elastic Kubernetes Service, Containers, Customer Solutions
Bedrock – Nền tảng Kubernetes nội bộ của Slack
Slack là một nền tảng tích hợp AI cho phép kết nối mọi người, cuộc hội thoại, ứng dụng và hệ thống với nhau ở một nơi. Slack đã áp dụng Amazon Elastic Kubernetes Service (Amazon) để xây dựng “Bedrock”, tên mã cho một nền tảng tổ chức tính toán nội bộ đơn giản hóa việc triển khai và quản lý container. Bedrock xử lý các môi trường xây dựng, triển khai và chạy thông qua một tập tin YAML duy nhất, giảm đáng kể sự phức tạp cho các nhà phát triển bên trong Slack. Nó cũng tận dụng các công cụ như Jenkins, phát hiện dịch vụ FQDN, và mạng lớp phủ Nebula cho các hoạt động hiệu quả. Với hơn 80% các ứng dụng của Slack hiện đang hoạt động trên Bedrock, Slack đã cải thiện độ chính xác kiểm tra và quản lý cơ sở hạ tầng tinh vi, trao quyền cho các nhà phát triển để hoạt động hiệu quả hơn.
Trong bài viết này, chúng ta đi sâu vào hành trình của Slack để hiện đại hóa nền tảng container của họ trên Amazon EKS và làm thế nào họ tăng tiết kiệm chi phí và cải thiện hiệu quả hoạt động bằng cách tận dụng Karpenter.
Cơ hội để cải thiện hiệu quả hoạt động
Trước khi sử dụng Karpenter, Slack đã tận dụng một giải pháp khác để tự động mở rộng quy mô tính toán của Amazon EKS, nhưng gặp phải những hạn chế khi nhu cầu nhóm nội bộ của họ tăng lên. Với nhiều ứng dụng hơn cùng với số lượng các loại instance và nhu cầu sử dụng các instance tăng lên, họ đã quản lý nhiều Autoscaling Groups (ASGs). Điều này trở thành một thách thức, vì Slack có các yêu cầu tuân thủ nghiêm ngặt và cần phải cập nhật thường xuyên các EKS cluster có hàng ngàn worker node. Những lần cập nhật thường xuyên này, kết hợp với việc quản lý nhiều ASGs, dẫn đến sự ngày càng chậm lại của tốc độ nâng cấp tổng thể. Họ cũng quan tâm đến việc sử dụng kiến trúc một bản sao (single-replica architecture) trong thiết lập hiện tại. Slack cần một công cụ tự động mở rộng quy mô có khả năng phục hồi cao giúp khởi động các node nhanh hơn, có độ sẵn sàng cao, và cung cấp việc đóng gói thùng cụm (cluster bin packing) tốt hơn.
Tổng quan về giải pháp
Để vượt qua những thách thức vận hành đã được đề cập trước đó, Slack quyết định sử dụng Karpenter, một công cụ tự động mở rộng cluster mã nguồn mở có khả năng cung cấp tự động các node mới để phản ứng với các pod không thể lên lịch. Karpenter đánh giá các yêu cầu tài nguyên tổng hợp của các pod đang chờ và chọn loại instance tối ưu để chạy chúng. Nó tự động co dãn hoặc chấm dứt các instance không có các pods không phải là daemonset để giảm lãng phí. Nó cũng hỗ trợ tính năng hợp nhất (consolidation) giúp chủ động di chuyển các pods xung quanh và xóa hoặc thay thế các node bằng các phiên bản rẻ hơn để giảm chi phí cluster.
Tất cả những tính năng này đã giải quyết được những thách thức Slack đang gặp phải, và với sự giúp đỡ từ AWS, chúng tôi đã thành công trong việc triển khai Karpenter trong môi trường Bedrock của Slack. Ngoài những tính năng đã được đề cập trước đó, việc Karpenter thực hiện trực tiếp các cuộc gọi API của Amazon Elastic Compute Cloud (Amazon EC2) fleet đảm bảo rằng Slack nhận được tính toán đúng mà không có độ trễ.
Chúng tôi đã bắt đầu hành trình của mình với một kế hoạch triển khai cẩn thận gồm hai giai đoạn.
Trong giai đoạn đầu tiên, triển khai Karpenter trong một nhóm node được quản lý cùng với các triển khai và ứng dụng cốt lõi. Karpenter đã được xác nhận cho một phần nhỏ của các ứng dụng và tính năng hợp nhất đã bị vô hiệu hóa trong giai đoạn này.
Trong giai đoạn thứ hai, chúng tôi di chuyển các tải công việc của Karpenter Controller sang các ASG riêng của chúng, vì chúng tôi không muốn Karpenter chạy trên các node của Karpenter. Sau khi kiểm tra kỹ lưỡng và xem xét cẩn thận tất cả các trường hợp sử dụng, cuối cùng chúng tôi đã triển khai Karpenter trên hơn 200 EKS cluster đang chạy hàng nghìn worker node. Slack cũng đã kích hoạt tính năng hợp nhất của Karpenter để đạt được tiết kiệm chi phí đáng kể.
Do việc triển khai Karpenter theo từng giai đoạn, chúng tôi có thể kiểm soát cluster nào có Karpenter được kích hoạt. Điều này cho phép chúng tôi xác nhận hiệu suất tải công việc trong Karpenter và nhanh chóng phục hồi khi có vấn đề được báo cáo. Khi một tải công việc không có yêu cầu/giới hạn thích hợp, Karpenter sẽ phân bổ các instance nhỏ hơn hoặc chỉ một phần nhỏ của một instance lớn, dẫn đến sự thay đổi pod cao hơn khi tải tăng. Karpenter đã giúp Slack phát hiện ra điều này, từ đó giúp Slack cải thiện nền tảng của mình bằng cách làm việc với các chủ sở hữu dịch vụ để đảm bảo rằng các pod được thiết lập với các yêu cầu để chúng được phân bổ trên các node thích hợp. Đối với các tải công việc cần các loại instance cụ thể, Slack đã có thể điều chỉnh tài nguyên NodePool và sử dụng các nhãn phổ biến với Karpenter để gán các pod vào các loại instance liên quan.
Kiến trúc của Bedrock EKS cluster của Slack
Hình 1: Kiến trúc EKS của Slack
Kết quả đạt được
Sau khi triển khai Karpenter trên toàn bộ hệ thống của mình, chúng tôi đã bắt đầu quá trình làm hỏng các nút ASG và chuyển đổi ứng dụng sang các phiên bản do Karpenter quản lý. Các kết quả thu được từ sáng kiến này đều đáng kể và có thể định lượng được.
Với sự trợ giúp của Karpenter, Slack đã có thể đóng gói thành công các ứng dụng và tận dụng nhiều loại instance từ 8xlarge đến 32xlarge dựa trên tài nguyên mà các pod đang chờ xử lý yêu cầu. Điều này dẫn đến việc tăng cường sử dụng cluster và tiết kiệm chi phí. Khối lượng công việc thiếu yêu cầu phiên bản cụ thể đã bắt đầu sử dụng hiệu quả các tài nguyên sẵn có trên diện rộng. Hơn nữa, các biện pháp hợp nhất của Karpenter đảm bảo loại bỏ các phiên bản nhàn rỗi, thay vì giữ chúng như một phần của kích thước ASG tối thiểu trên các Availability Zones (AZs) khác nhau, như trường hợp với giải pháp trước đây của chúng tôi. Ngoài ra, chúng tôi nhận thấy thời gian cung cấp node được tăng tốc nhờ các quyết định mở rộng quy mô nhanh chóng của Karpenter.
Tóm lại, việc lựa chọn động các instance dựa trên nhu cầu tài nguyên của pod, cùng với việc loại bỏ các loại instance được mã hóa cứng trong các tệp Terraform cluster, đã hỗ trợ khởi chạy pod nhanh hơn. Những lo ngại về việc nâng cấp hệ thống của Slack cũng được giảm bớt vì chúng tôi có thể nhanh chóng rút và xoay các node trong quá trình nâng cấp. Khả năng tương tác trực tiếp với API Amazon EC2 của Karpenter và cơ chế thử lại được cải tiến đã đảm bảo chúng tôi phục hồi nhanh hơn trong trường hợp AZ bị lỗi. Các ứng dụng có thể mở rộng dung lượng phiên bản nhiều nhất có sẵn với AWS, điều này có nghĩa là chúng tôi sẽ tốn ít chi phí hơn để quản lý ASG và mang lại trải nghiệm tốt hơn cho người dùng Slack! Hôm nay, Slack chạy Karpenter với khả năng cung cấp vượt mức tùy chỉnh để cung cấp vùng đệm cho ứng dụng quan trọng của họ trong các hoạt động mở rộng quy mô nhanh chóng.
Bằng cách tận dụng tính năng tạo khuôn mẫu của Helm, Slack đã tùy chỉnh biểu đồ hỗ trợ Karpenter và đang sử dụng một NodePool và AWS EC2NodeClass duy nhất trên hơn 200 EKS cluster.
Với nhiều lựa chọn loại instance có sẵn trong họ instance do Karpenter cung cấp, các nhóm kỹ thuật tại Slack nhận thấy việc chuyển từ loại phiên bản này sang loại phiên bản khác khi sử dụng các ràng buộc lập lịch động là rất hữu ích. Điều này đã giảm bớt gánh nặng RTB cho các nhóm cơ sở hạ tầng và giảm thiểu rủi ro khi thay đổi loại instance như chúng tôi đã thấy khi duy trì cấu hình ASG. Bằng cách tận dụng Karpenter, Slack có thể tiết kiệm được 12% chi phí tính toán EKS của họ.
Hình 2: Hiệu quả đóng gói thùng
Cải tiến trong tương lai
Slack hiện đang làm việc để tinh chỉnh cấu hình Karpenter để cải thiện hơn nữa các hoạt động và tiết kiệm chi phí. Một số tính năng trong lộ trình bao gồm:
- Karpenter được quản lý: Điều này giúp Slack tập trung vào các hạn chế để chạy pod trong khi để lại công việc quản lý bộ điều khiển Karpenter cho AWS.
- Tùy chỉnh Kubelets: Sử dụng các cờ kubelet trong EC2NodeClass của Karpenter thay vì truyền chúng qua giải pháp cơ sở hạ tầng dưới dạng mã (Infrastructure as Code – IaC) để cải thiện thời gian khởi động của các instance.
- Bể nhiệt/tối thiểu (Warmpool/minimum): Vì Karpenter là một dự án mã nguồn mở, Slack đang khám phá các cách góp phần giảm thời gian khởi động bằng cách làm cho Karpenter chọn các instance từ một bể nhiệt thay vì thực hiện các cuộc gọi API của Amazon EC2 fleet.
- Kiểm soát sự gián đoạn: Slack tận dụng kiểm soát sự gián đoạn để điều khiển các sự gián đoạn xảy ra do sự hợp nhất, và để giới hạn ảnh hưởng đến tính sẵn có của ứng dụng.
Kết luận
Trong bài viết này, chúng ta đã thảo luận về cách mà nhóm Bedrock của Slack đã cải thiện hoạt động và tiết kiệm chi phí khi sử dụng Amazon EKS cluster bằng cách triển khai Karpenter. Sự hợp tác giữa AWS và Slack rất quan trọng trong việc triển khai thành công Karpenter và hiện đại hóa môi trường Amazon EKS của Slack. Chúng ta cũng đã nói về cách Slack có thể cải thiện tốc độ nâng cấp và tăng tiết kiệm chi phí của họ bằng cách sử dụng Karpenter như là một công cụ tự động mở rộng quy mô cho EKS cluster. Trong tương lai, Slack sẽ tập trung nhiều vào việc tối ưu hơn nữa môi trường Karpenter bằng cách đóng góp và tận dụng các tính năng mới để xây dựng một nền tảng mạnh mẽ dựa trên Amazon EKS.
Bài viết được dịch từ link blog sau đây:
AWS Study Group 