Mức độ ưu tiên của nhóm trong Kubernetes gây ra thời gian ngừng hoạt động tại Grafana Labs như thế nào

Ghi chú. bản dịch.: Chúng tôi trình bày cho bạn biết chi tiết kỹ thuật về lý do dẫn đến thời gian ngừng hoạt động gần đây của dịch vụ đám mây do những người tạo ra Grafana duy trì. Đây là một ví dụ kinh điển về việc một tính năng mới và dường như cực kỳ hữu ích được thiết kế để cải thiện chất lượng cơ sở hạ tầng... có thể gây hại như thế nào nếu bạn không cung cấp nhiều sắc thái ứng dụng của nó trong thực tế sản xuất. Thật tuyệt vời khi những tài liệu như thế này xuất hiện cho phép bạn học hỏi không chỉ từ những sai lầm của mình. Thông tin chi tiết có trong bản dịch văn bản này từ phó chủ tịch sản phẩm của Grafana Labs.

Mức độ ưu tiên của nhóm trong Kubernetes gây ra thời gian ngừng hoạt động tại Grafana Labs như thế nào

Vào thứ Sáu, ngày 19 tháng 30, dịch vụ Prometheus được lưu trữ trên Đám mây Grafana đã ngừng hoạt động trong khoảng XNUMX phút. Tôi xin lỗi tất cả khách hàng bị ảnh hưởng bởi việc ngừng hoạt động. Công việc của chúng tôi là cung cấp các công cụ giám sát mà bạn cần và chúng tôi hiểu rằng việc không có sẵn chúng có thể khiến cuộc sống của bạn trở nên khó khăn hơn. Chúng tôi cực kỳ coi trọng sự cố này. Ghi chú này giải thích điều gì đã xảy ra, cách chúng tôi phản hồi và những gì chúng tôi đang làm để đảm bảo điều đó không xảy ra lần nữa.

thời tiền sử

Dịch vụ Prometheus được lưu trữ trên nền tảng đám mây của Grafana dựa trên Cortex — Dự án CNCF nhằm tạo ra dịch vụ Prometheus có nhiều người thuê, có khả năng mở rộng theo chiều ngang, tính sẵn sàng cao. Kiến trúc Cortex bao gồm một tập hợp các vi dịch vụ riêng lẻ, mỗi vi dịch vụ thực hiện chức năng riêng: sao chép, lưu trữ, truy vấn, v.v. Cortex đang được phát triển tích cực và liên tục bổ sung các tính năng mới cũng như cải thiện hiệu suất. Chúng tôi thường xuyên triển khai các bản phát hành Cortex mới theo cụm để khách hàng có thể tận dụng những tính năng này - thật may là Cortex có thể được cập nhật mà không có thời gian ngừng hoạt động.

Để cập nhật liền mạch, dịch vụ Ingester Cortex yêu cầu bản sao Ingester bổ sung trong quá trình cập nhật. (Ghi chú. bản dịch.: Người nuốt - thành phần cơ bản của Cortex. Công việc của nó là thu thập một luồng mẫu liên tục, nhóm chúng thành các khối Prometheus và lưu trữ chúng trong cơ sở dữ liệu như DynamoDB, BigTable hoặc Cassandra.) Điều này cho phép các Ingester cũ chuyển tiếp dữ liệu hiện tại tới các Ingester mới. Điều đáng chú ý là Ingesters đòi hỏi nhiều tài nguyên. Để chúng hoạt động, bạn cần có 4 lõi và 15 GB bộ nhớ cho mỗi nhóm, tức là. 25% sức mạnh xử lý và bộ nhớ của máy cơ sở trong trường hợp cụm Kubernetes của chúng tôi. Nhìn chung, chúng tôi thường có nhiều tài nguyên chưa được sử dụng trong cụm hơn 4 lõi và 15 GB bộ nhớ, vì vậy chúng tôi có thể dễ dàng sử dụng các bộ nạp bổ sung này trong quá trình nâng cấp.

Tuy nhiên, điều thường xảy ra là trong quá trình hoạt động bình thường, không có máy nào có 25% tài nguyên chưa sử dụng này. Có, chúng tôi thậm chí không nỗ lực: CPU và bộ nhớ sẽ luôn hữu ích cho các quy trình khác. Để giải quyết vấn đề này, chúng tôi quyết định sử dụng Ưu tiên của Kubernetes Pod. Ý tưởng là cung cấp cho Ingesters mức độ ưu tiên cao hơn các dịch vụ vi mô (không trạng thái) khác. Khi cần chạy một Ingester (N+1) bổ sung, chúng tôi tạm thời thay thế các nhóm khác nhỏ hơn. Các nhóm này được chuyển sang tài nguyên miễn phí trên các máy khác, để lại một “lỗ hổng” đủ lớn để chạy một Ingester bổ sung.

Vào Thứ Năm, ngày 18 tháng XNUMX, chúng tôi đã triển khai bốn cấp độ ưu tiên mới cho các cụm của mình: quan trọng, высокий, trung bình и Thấp. Chúng đã được thử nghiệm trên một cụm nội bộ không có lưu lượng khách hàng trong khoảng một tuần. Theo mặc định, các nhóm không có mức độ ưu tiên được chỉ định sẽ nhận được trung bình mức độ ưu tiên, lớp đã được đặt cho Ingesters với cao sự ưu tiên. Phê bình được dành riêng để giám sát (Prometheus, Alertmanager, node-exporter, kube-state-metrics, v.v.). Cấu hình của chúng tôi đang mở và bạn có thể xem PR đây.

Tai nạn

Vào thứ Sáu, ngày 19 tháng XNUMX, một trong những kỹ sư đã ra mắt cụm Cortex chuyên dụng mới cho một khách hàng lớn. Cấu hình cho cụm này không bao gồm mức độ ưu tiên của nhóm mới, vì vậy tất cả các nhóm mới được chỉ định mức độ ưu tiên mặc định - trung bình.

Cụm Kubernetes không có đủ tài nguyên cho cụm Cortex mới và cụm Cortex sản xuất hiện tại chưa được cập nhật (Ingesters bị bỏ lại mà không có cao sự ưu tiên). Vì các Ingesters của cụm mới theo mặc định có trung bình ưu tiên và các nhóm hiện có trong quá trình sản xuất hoạt động mà không có mức độ ưu tiên nào cả, các Ingester của cụm mới đã thay thế các Ingesters từ cụm sản xuất Cortex hiện có.

ReplicaSet cho Ingester bị loại bỏ trong cụm sản xuất đã phát hiện nhóm bị loại bỏ và tạo một nhóm mới để duy trì số lượng bản sao được chỉ định. Nhóm mới được chỉ định theo mặc định trung bình ưu tiên, và một Ingester “cũ” khác đang trong quá trình sản xuất bị mất tài nguyên. Kết quả là quá trình tuyết lở, dẫn đến việc chuyển tất cả các nhóm từ cụm sản xuất Ingester sang Cortex.

Bộ nhập dữ liệu có trạng thái và lưu trữ dữ liệu trong 12 giờ trước đó. Điều này cho phép chúng tôi nén chúng hiệu quả hơn trước khi ghi chúng vào bộ lưu trữ dài hạn. Để đạt được điều này, Cortex phân chia dữ liệu trên các chuỗi bằng cách sử dụng Bảng băm phân tán (DHT) và sao chép từng chuỗi trên ba Ingester bằng cách sử dụng tính nhất quán đại biểu kiểu Dynamo. Cortex không ghi dữ liệu vào Ingesters đã bị vô hiệu hóa. Do đó, khi một số lượng lớn Ingester rời khỏi DHT, Cortex không thể cung cấp đủ bản sao cho các mục và chúng bị lỗi.

Phát hiện và khắc phục

Thông báo Prometheus mới dựa trên "ngân sách lỗi" (dựa trên ngân sách lỗi - chi tiết sẽ xuất hiện trong một bài viết trong tương lai) bắt đầu phát ra âm thanh báo động 4 phút sau khi bắt đầu tắt máy. Trong khoảng năm phút tiếp theo, chúng tôi đã chạy một số chẩn đoán và mở rộng quy mô cụm Kubernetes cơ bản để lưu trữ cả cụm sản xuất mới và cụm sản xuất hiện có.

Sau năm phút nữa, Ingesters cũ đã ghi thành công dữ liệu của họ, những Ingesters mới khởi động và cụm Cortex hoạt động trở lại.

10 phút nữa được dành để chẩn đoán và sửa lỗi hết bộ nhớ (OOM) từ các proxy ngược xác thực nằm phía trước Cortex. Lỗi OOM xảy ra do QPS tăng gấp XNUMX lần (chúng tôi tin rằng do các yêu cầu quá mạnh mẽ từ máy chủ Prometheus của khách hàng).

Hậu quả

Tổng thời gian ngừng hoạt động là 26 phút. Không có dữ liệu bị mất. Trình nhập đã tải thành công tất cả dữ liệu trong bộ nhớ vào bộ lưu trữ dài hạn. Trong quá trình tắt máy, máy chủ Prometheus của khách hàng đã bị xóa vào bộ đệm (Xa xôi) ghi âm sử dụng API mới remote_write dựa trên WAL (tác giả bởi Callum Styan từ Grafana Labs) và lặp lại thao tác ghi không thành công sau sự cố.

Mức độ ưu tiên của nhóm trong Kubernetes gây ra thời gian ngừng hoạt động tại Grafana Labs như thế nào
Hoạt động ghi cụm sản xuất

Những phát hiện

Điều quan trọng là phải rút kinh nghiệm từ sự cố này và thực hiện các bước cần thiết để tránh tái diễn.

Nhìn lại, lẽ ra chúng ta không nên đặt mặc định trung bình được ưu tiên cho đến khi tất cả các Ingester trong quá trình sản xuất đã nhận được высокий một ưu tiên. Ngoài ra, cần phải chăm sóc chúng trước cao sự ưu tiên. Bây giờ mọi thứ đã được sửa. Chúng tôi hy vọng kinh nghiệm của chúng tôi sẽ giúp ích cho các tổ chức khác đang cân nhắc việc sử dụng mức độ ưu tiên của nhóm trong Kubernetes.

Chúng tôi sẽ thêm một mức kiểm soát bổ sung đối với việc triển khai bất kỳ đối tượng bổ sung nào có cấu hình chung cho cụm. Kể từ bây giờ, những thay đổi đó sẽ được đánh giá bоthêm người. Ngoài ra, sửa đổi gây ra sự cố được coi là quá nhỏ đối với một tài liệu dự án riêng biệt - nó chỉ được thảo luận trong vấn đề GitHub. Kể từ bây giờ, tất cả những thay đổi về cấu hình như vậy sẽ được kèm theo tài liệu dự án phù hợp.

Cuối cùng, chúng tôi sẽ tự động thay đổi kích thước proxy ngược xác thực để ngăn chặn tình trạng quá tải OOM mà chúng tôi đã chứng kiến, đồng thời sẽ xem xét các cài đặt mặc định của Prometheus liên quan đến dự phòng và thay đổi quy mô để ngăn chặn các sự cố tương tự trong tương lai.

Thất bại cũng gây ra một số hậu quả tích cực: sau khi nhận được các tài nguyên cần thiết, Cortex tự động phục hồi mà không cần can thiệp thêm. Chúng tôi cũng đã thu được những kinh nghiệm quý báu khi làm việc với GrafanaLoki - hệ thống tổng hợp nhật ký mới của chúng tôi - giúp đảm bảo rằng tất cả các Ingester đều hoạt động bình thường trong và sau khi xảy ra lỗi.

Tái bút từ người dịch

Đọc thêm trên blog của chúng tôi:

Nguồn: www.habr.com

Thêm một lời nhận xét