Prometheus エクスポータである Kube Eagle を作成しました。 これは、中小規模のクラスターのリソースをより深く理解するのに役立つ素晴らしいものであることがわかりました。 適切なマシン タイプを選択し、ワークロードに応じてアプリケーション リソース制限を構成したため、最終的には数百ドルを節約できました。
メリットについてお話します , しかし、最初に、何が大騒ぎを引き起こしたのか、そしてなぜ高品質のモニタリングが必要なのかを説明します。
私は 4 ～ 50 ノードのクラスターをいくつか管理しました。 各クラスターには最大 200 のマイクロサービスとアプリケーションが含まれます。 既存のハードウェアを有効に活用するために、ほとんどの展開はバースト可能な RAM と CPU リソースを使用して構成されていました。 こうすることで、ポッドは必要に応じて利用可能なリソースを取得できると同時に、このノード上の他のアプリケーションに干渉することがなくなります。 まあ、それは素晴らしいことではありませんか？
また、クラスターが消費する CPU (8%) と RAM (40%) は比較的少なかったのですが、ノードで利用可能なメモリを超えるメモリを割り当てようとしたときにポッドがプリエンプトされるという問題が常に発生していました。 当時、Kubernetes リソースを監視するためのダッシュボードは XNUMX つだけでした。 このような：
cAdvisor メトリクスのみを含む Grafana ダッシュボード
このようなパネルでは、メモリと CPU を大量に消費するノードがあっても問題ありません。 問題はその理由を解明することです。 ポッドを所定の位置に維持するために、すべてのポッドに保証されたリソース (制限に等しい要求されたリソース) をセットアップすることもできます。 しかし、これはハードウェアの最も賢い使い方ではありません。 クラスターには数百ギガバイトのメモリがあり、一部のノードは不足していましたが、他のノードには 4 ～ 10 GB の予備が残っていました。
Kubernetes スケジューラが、利用可能なリソース全体にワークロードを不均等に分散していたことが判明しました。 Kubernetes スケジューラは、アフィニティ、テイントおよび許容ルール、使用可能なノードを制限できるノード セレクターなどのさまざまな構成を考慮します。 しかし、私の場合はそのようなことはなく、ポッドは各ノードで要求されたリソースに応じて計画されました。
空きリソースが最も多く、リクエスト条件を満たすノードがポッドとして選択されました。 ノード上で要求されたリソースが実際の使用状況と一致していないことがわかりました。ここで Kube Eagle とそのリソース監視機能が役に立ちました。
ほぼすべての Kubernetes クラスターをのみで監視しています и 。 Node Exporter は I/O、ディスク、CPU、RAM の使用状況に関する統計を提供し、Kube State Metrics はリクエストや CPU およびメモリ リソース制限などの Kubernetes オブジェクト メトリックを表示します。
Grafana で使用状況メトリクスをリクエストおよび制限メトリクスと組み合わせる必要があります。そうすれば、問題に関するすべての情報が得られます。 これは簡単に聞こえますが、実際には XNUMX つのツールのラベル名は異なり、一部のメトリクスにはメタデータ ラベルがまったくありません。 Kube Eagle はすべてを自動的に実行し、パネルは次のようになります。
私たちはリソースに関する多くの問題を解決し、設備を節約することができました。
- 一部の開発者は、マイクロサービスに必要なリソースの数を知りませんでした (または単に気にしませんでした)。 リソースに対する間違ったリクエストを見つける方法はありませんでした。そのためには、消費量とリクエストと制限を知る必要がありました。 現在では、Prometheus メトリクスを確認し、実際の使用状況を監視し、リクエストと制限を調整できるようになりました。
- JVM アプリケーションは、処理できる限り多くの RAM を必要とします。 ガベージ コレクターは、75% を超えてメモリが使用されている場合にのみメモリを解放します。 また、ほとんどのサービスにはバースト可能なメモリがあるため、常に JVM によって占有されていました。 したがって、これらすべての Java サービスは、予想よりもはるかに多くの RAM を消費していました。
- 一部のアプリケーションが過剰なメモリを要求したため、実際には他のノードより空きがあるにもかかわらず、Kubernetes スケジューラはこれらのノードを他のアプリケーションに与えませんでした。 ある開発者は、誤ってリクエストに余分な桁を追加し、20 GB ではなく 2 GB という大きな RAM を取得してしまいました。誰も気づきませんでした。 アプリケーションには 3 つのレプリカがあったため、最大 3 つのノードが影響を受けました。
- リソース制限を導入し、正しいリクエストを使用してポッドを再スケジュールし、すべてのノードにわたるハードウェア使用量の理想的なバランスを実現しました。 いくつかのノードが完全に閉じられた可能性があります。 そして、間違ったマシン (メモリ指向ではなく CPU 指向) を使用していることがわかりました。 タイプを変更し、さらにいくつかのノードを削除しました。
結果
クラスター内にバースト可能なリソースを使用すると、利用可能なハードウェアをより効率的に使用できますが、Kubernetes スケジューラーはリソースのリクエストに基づいてポッドをスケジュールするため、これには問題が伴います。 一石二鳥: 問題を回避し、リソースを最大限に活用するには、適切な監視が必要です。 だからこそ役に立つのです (Prometheus エクスポーターと Grafana ダッシュボード)。
出所： habr.com