Tóm tắt
Trong quá trình vận hành Kubernetes (K8s), cụ thể là trên Google Kubernetes Engine (GKE), tôi đã phát triển một số công cụ nhằm cải thiện hiệu suất làm việc của mình. Những công cụ này nhằm giải quyết các vấn đề liên quan đến chi phí, tự động hóa và ổn định cho K8S workload. Nhân dịp này, tôi muốn giới thiệu một giải pháp khá hoàn chỉnh mà tôi đã xây dựng từ những công cụ này.
Giới thiệu
Hiện tại, tôi đang quản lý một số cluster K8s, bao gồm hệ thống nền tảng dữ liệu dùng Apache Spark. Với số lượng lớn Spark job chạy hàng ngày, việc theo dõi liên tục là rất cần thiết để giảm thiểu số lượng workload/job thất bại, đồng thời đảm bảo sự cân bằng về chi phí. Việc chỉ ngồi theo dõi và khắc phục các lỗi thất bại trở nên nhàm chán, nhất là khi hệ thống ngày càng mở rộng. Do đó, tôi đã quyết định phát triển một hệ thống gọi là "Tự Động Khôi Phục Lỗi" (Auto Remediation) nhằm tự động khắc phục một số lỗi phổ biến trong hệ thống nền tảng dữ liệu và có thể mở rộng sang các workload khác trên K8S.
Hệ thống này ban đầu được thiết kế để xử lý các vấn đề về bộ nhớ liên quan đến workload chạy trên K8S, đặc biệt là lỗi Out-Of-Memory (OOM). Giải pháp này có thể giúp:
- Giảm chi phí hạ tầng.
- Giảm thiểu lượng nhân lực cần thiết để vận hành hệ thống.
- Giảm số lượng lỗi trong môi trường sản xuất và những chi phí phát sinh khi xảy ra lỗi.
- Tạo thêm thời gian cho bản thân (thật tuyệt vời phải không? 😂).
Tổng quan, Auto Remediation sử dụng log và metrics kết hợp với bộ phân loại dựa trên quy tắc (rule-based classifier) để đưa ra các quyết định cụ thể nhằm giải quyết vấn đề gặp phải. Hệ thống có khả năng mở rộng để xử lý nhiều trường hợp khác nhau khi phát triển thêm các quy tắc từ các Kỹ sư Đảm bảo Tính khả dụng (SRE).
Quy trình tối ưu hóa K8S workload
Kể từ năm 2023, khi bắt đầu công việc SRE, tôi đã phát triển công cụ GKE Resource Recommendation (GRR) nhằm đưa ra các khuyến nghị cho K8S workload. Bạn có thể coi GRR hoạt động như Vertical Pod Autoscaler (VPA), nhưng tôi đã tùy biến cách tính toán để phù hợp hơn với nhu cầu cụ thể và cải thiện độ chính xác cho phần bộ nhớ. Công cụ này đã được tôi trình bày tại sự kiện Viet-OpenInfra 2023. Hiện tại, tôi đã cập nhật để xác định thêm bộ nhớ cần thiết để khởi động pod, đặc biệt cho các ứng dụng Java.
Mặc dù GRR có thể giải quyết vấn đề tối ưu hóa workload, nhưng khi pod cần thêm bộ nhớ, việc rollout lại có thể gặp khó khăn.
Vấn đề Out-Of-Memory (OOM)
Lỗi Out-Of-Memory là một vấn đề phổ biến khi sử dụng K8S. Để kiểm soát lượng bộ nhớ mà container sử dụng trong K8S, người dùng có thể đặt giới hạn tài nguyên (resource limit). Khi lượng bộ nhớ vượt quá giới hạn này, lỗi OOMKilled sẽ xuất hiện và ứng dụng của bạn sẽ bị tạm ngừng.
Nhiều người nghĩ rằng chỉ cần đặt giới hạn cao là đủ, nhưng không phải lúc nào cũng đơn giản như vậy. Các ứng dụng Spark thường thiết lập memory request bằng với memory limit, do đó việc đặt giới hạn cao sẽ làm tốn thêm tài nguyên. Khi khối lượng dữ liệu tăng đột biến, cấu hình ban đầu có thể không còn phù hợp, dẫn đến lỗi OOM.
Để xử lý vấn đề này, tôi đã phát triển một công cụ để xóa pod khi mức sử dụng bộ nhớ gần chạm ngưỡng giới hạn, đồng thời hỗ trợ cả các ứng dụng Java Spring khi bộ nhớ heap gần giới hạn tối đa của nó. Tôi tận dụng K8S metrics server để lấy thông tin về sử dụng bộ nhớ của từng container, và đối với ứng dụng Java, cần kích hoạt thêm Spring Boot Actuator. Thông tin chi tiết về công cụ này có thể tìm thấy tại: https://github.com/phamngocsonls/k8s-oom-killer.
Giải pháp Tự Động Khôi Phục Lỗi
Khi kết hợp các công cụ đã phát triển và xây dựng thêm một quy trình tích hợp toàn diện hơn, tôi đã tạo ra một hệ thống mới.
Kiến trúc hệ thống
Tôi hiện đang sử dụng Google Cloud và đã tận dụng các dịch vụ của Google Cloud. Tôi có hai GKE cluster:
- GKE cluster 1: Triển khai các workload cơ bản với công cụ OOM Killer để kiểm soát lượng bộ nhớ và tránh lỗi OOM xảy ra.
- GKE cluster 2: Triển khai Spark cho hệ thống dữ liệu.
Công cụ thực thi quy tắc (Rule Execution Engine): Nhận thông báo từ các chủ đề Pub/Sub được định tuyến từ log của các GKE cluster và xử lý với bộ quy tắc đã có. Các quy tắc này có thể được phát triển từ nhiều SRE tùy thuộc vào từng trường hợp cụ thể. Các lỗi có thể không cần khắc phục ngay hoặc cần tăng tài nguyên. Kết quả sẽ được lưu vào cơ sở dữ liệu hàng hoạt (Operational storage).
Ví dụ, nếu log cho thấy pod bị xóa bởi công cụ OOM Killer, chúng ta sẽ ghi nhận và theo dõi tình hình.
Dịch vụ cấu hình (Config Service): Chứa thông tin về khuyến nghị tài nguyên cho các workload được lấy từ công cụ GRR.
Pensive: Được kích hoạt định kỳ từ Cloud Scheduler, Pensive đọc thông tin từ Operational storage để đưa ra quyết định cụ thể. Nếu workload cần tăng tài nguyên, Pensive sẽ gọi đến Config Service để lấy cấu hình mới và cập nhật vào repository GitOps cho Argo CD thực hiện rollout với cấu hình mới. Đối với các job Apache Spark, Airflow sẽ gọi đến Pensive định kỳ để lấy thông tin cấu hình tài nguyên mới.
Kết luận
Giải pháp Auto Remediation có khả năng giải quyết nhiều vấn đề phát sinh trong quá trình vận hành K8S trong tương lai. Khi các Kỹ sư Đảm bảo Tính khả dụng (SRE) tiếp tục phát triển bộ quy tắc (Rule Engine), hệ thống sẽ ngày càng trở nên hoàn thiện hơn khi quy mô lớn lên và nhiều lỗi lặp đi lặp lại phát sinh. Dù rằng ở giai đoạn đầu phát triển có thể gặp một số false positive ảnh hưởng tới môi trường sản xuất, nhưng mọi người nên cân nhắc kỹ trước khi triển khai.
source: viblo
