Kubernetes のポッドの優先順位が Grafana Labs でダウンタイムを引き起こした仕組み

ノート。 翻訳。: Grafana の作成者によって管理されているクラウド サービスで最近発生したダウンタイムの理由について、技術的な詳細をお知らせします。 これは、インフラストラクチャの品質を向上させるために設計された、一見非常に便利な新機能が、実際の運用環境でのアプリケーションのさまざまな微妙な違いに対応していないと、害を及ぼす可能性があることを示す典型的な例です。 自分の間違いからだけでなく学ぶこともできるこのような教材が登場するのは素晴らしいことです。 詳細は、Grafana Labs の製品担当副社長によるこのテキストの翻訳に記載されています。

19 月 30 日金曜日、Grafana Cloud の Hosted Prometheus サービスが約 XNUMX 分間機能を停止しました。 停電の影響を受けられたお客様には心よりお詫び申し上げます。 私たちの仕事は、お客様が必要とする監視ツールを提供することであり、それらが利用できないとお客様の生活がより困難になる可能性があることを理解しています。 私たちはこの事件を非常に深刻に受け止めています。 このメモでは、何が起こったのか、私たちがどのように対応したか、そして同じことが二度と起こらないようにするために私たちが何をしているのかについて説明します。

背景

Grafana Cloud Hosted Prometheus サービスは、以下に基づいています。 皮質 — 水平スケーラブルで可用性の高いマルチテナントの Prometheus サービスを作成する CNCF プロジェクト。 Cortex アーキテクチャは一連の個別のマイクロサービスで構成され、それぞれがレプリケーション、ストレージ、クエリなどの独自の機能を実行します。 Cortex は積極的に開発中であり、常に新機能を追加し、パフォーマンスを向上させています。 お客様がこれらの機能を利用できるように、新しい Cortex リリースを定期的にクラスターにデプロイします。幸いなことに、Cortex はダウンタイムなしで更新できます。

シームレスな更新のために、Ingester Cortex サービスは更新プロセス中に追加の Ingester レプリカを必要とします。 (ノート。 翻訳。: インジェスター - 皮質の基本コンポーネント。 その仕事は、サンプルの一定のストリームを収集し、それらを Prometheus チャンクにグループ化し、DynamoDB、BigTable、または Cassandra などのデータベースに保存することです)。 これにより、古いインジェスターが現在のデータを新しいインジェスターに転送できるようになります。 インジェスタはリソースを大量に消費することに注意してください。 これらが機能するには、ポッドごとに 4 つのコアと 15 GB のメモリが必要です。 Kubernetes クラスターの場合、ベース マシンの処理能力とメモリの 25%。 一般に、クラスター内には 4 コアと 15 GB のメモリよりも多くの未使用リソースがあるため、アップグレード中にこれらの追加のインジェスターを簡単にスピンアップできます。

ただし、通常の運用では、どのマシンにもこの 25% の未使用リソースが存在しないことがよくあります。 はい、努力する必要はありません。CPU とメモリは常に他のプロセスに役立ちます。 この問題を解決するために、私たちは使用することにしました Kubernetes ポッドの優先順位。 このアイデアは、インジェスターに他の (ステートレス) マイクロサービスよりも高い優先順位を与えることです。 追加の (N+1) インジェスターを実行する必要がある場合は、他の小さなポッドを一時的に置き換えます。 これらのポッドは他のマシン上の空きリソースに転送され、追加のインジェスターを実行するのに十分な大きさの「穴」が残ります。

18 月 XNUMX 日木曜日、クラスターに XNUMX つの新しい優先度レベルを展開しました。 クリティカル, 高い, 平均 и 低い。 これらは、クライアント トラフィックのない内部クラスターで約 XNUMX 週間テストされました。 デフォルトでは、優先順位が指定されていないポッドは受信されます。 平均 優先度、クラスはインジェスタに設定されました 高い 優先順位。 致命的 モニタリング用に予約されていました (Prometheus、Alertmanager、node-exporter、kube-state-metrics など)。 構成は公開されており、PR を表示できます。 ここで.

クラッシュ

19 月 XNUMX 日金曜日、エンジニアの XNUMX 人が大規模クライアント向けに新しい専用の Cortex クラスターを立ち上げました。 このクラスターの構成には新しいポッドの優先順位が含まれていなかったため、すべての新しいポッドにはデフォルトの優先順位が割り当てられました。 平均.

Kubernetes クラスターには新しい Cortex クラスターに十分なリソースがなく、既存の実稼働 Cortex クラスターは更新されませんでした (インジェスターは更新されずに残されました) высокого 優先度）。 新しいクラスターのインジェスターにはデフォルトで 平均 優先順位が高く、本番環境の既存のポッドが優先順位なしで動作したため、新しいクラスターのインジェスターが既存の Cortex 本番クラスターのインジェスターに置き換わりました。

実稼働クラスター内の削除された Ingester の ReplicaSet は、削除されたポッドを検出し、指定された数のコピーを維持するために新しいポッドを作成しました。 新しいポッドはデフォルトで割り当てられました 平均 が優先され、本番環境の別の「古い」Ingester がリソースを失いました。 結果は、 雪崩プロセスこれにより、Cortex 運用クラスターの Ingester からすべてのポッドが置き換えられました。

インジェスターはステートフルで、過去 12 時間のデータを保存します。 これにより、長期ストレージに書き込む前に、より効率的に圧縮できるようになります。 これを実現するために、Cortex は分散ハッシュ テーブル (DHT) を使用してシリーズ間でデータをシャーディングし、Dynamo スタイルのクォーラム一貫性を使用して XNUMX つのインジェスター間で各シリーズをレプリケートします。 Cortex は、無効になっているインジェスターにデータを書き込みません。 したがって、多数のインジェスタが DHT から離れると、Cortex はエントリの十分なレプリケーションを提供できず、クラッシュします。

検出と修復

「エラー バジェット」に基づく新しい Prometheus 通知 (エラーバジェットベース 詳細は今後の記事で説明します) シャットダウン開始から 4 分後にアラームが鳴り始めました。 次の XNUMX 分ほどで、いくつかの診断を実行し、基盤となる Kubernetes クラスターをスケールアップして、新規と既存の実稼働クラスターの両方をホストしました。

さらに XNUMX 分後、古いインジェスターがデータの書き込みに成功し、新しいインジェスターが起動し、Cortex クラスターが再び利用できるようになりました。

さらに 10 分は、Cortex の前にある認証リバース プロキシからのメモリ不足 (OOM) エラーの診断と修正に費やされました。 OOM エラーは、QPS の XNUMX 倍の増加によって発生しました (クライアントの Prometheus サーバーからの過度に積極的なリクエストが原因であると考えられます)。

余波

合計のダウンタイムは 26 分でした。 データは失われていませんでした。 インジェスタは、すべてのメモリ内データを長期ストレージに正常にロードしました。 シャットダウン中に、クライアントの Prometheus サーバーがバッファリングされ、削除されました (リモートで) を使用した録音 新しい API リモート書き込み WAL に基づく (作成者: カラム・スティアン Grafana Labs から) を使用し、クラッシュ後に書き込み失敗を繰り返しました。

実稼働クラスターの書き込み操作

所見

この事件から学び、再発を防ぐために必要な措置を講じることが重要です。

今にして思えば、デフォルトを設定すべきではなかった 平均 本番環境のすべてのインジェスターが受信するまで優先されます。 高い 優先事項。 また、事前に対処する必要がありました 高い 優先度。 これですべてが修正されました。 私たちの経験が、Kubernetes でポッド優先順位の使用を検討している他の組織に役立つことを願っています。

構成がクラスターに対してグローバルである追加オブジェクトのデプロイメントに対する制御レベルを追加します。 今後、このような変化は評価されます。оより多くの人々。 さらに、クラッシュの原因となった変更は、別のプロジェクト ドキュメントとして扱うには軽すぎると考えられ、GitHub の問題でのみ議論されました。 今後、このような構成への変更にはすべて、適切なプロジェクト ドキュメントが添付されるようになります。

最後に、私たちが目撃した OOM の過負荷を防ぐために認証リバース プロキシのサイズ変更を自動化し、将来同様の問題が発生しないようにフォールバックとスケーリングに関連する Prometheus のデフォルト設定を見直します。

この障害は、いくつかのプラスの結果ももたらしました。必要なリソースを受け取ったため、Cortex は追加の介入なしで自動的に回復しました。 私たちはまた、協力して貴重な経験を得ることができました。 グラファナ・ロキ - 新しいログ集約システム - 障害中および障害後にすべてのインジェスターが適切に動作することを保証するのに役立ちました。

翻訳者からの追伸

私たちのブログもお読みください:

• «Kubernetes の自動スケーリングとリソース管理 (レビューとビデオ レポート)";
• «Kubernetes の冒険 Dailymotion: クラウド + オンプレミスでのインフラストラクチャの作成";
• «Tinder から Kubernetes への移行";
• «運用環境における Kubernetes の成功事例。 パート 10: レディット'。

出所： habr.com