第10章 大規模なクラスターでの flowlogs-pipeline リソース消費の最適化


共有キャッシュアーキテクチャーを使用して、ネットワークフローの可視性を維持しつつ、大規模な フローlogs-pipeline デプロイメントでの Kubernetes API サーバーの負荷とリソース消費を減らします。

10.1. 大規模なデプロイメントでのパフォーマンスに関する課題

大規模なデプロイメントでは、各 flowlogs-pipeline インスタンスは Kubernetes API サーバーに対して個別にクエリーを実行してメタデータのフローを補完するため、API クエリーをインスタンススケールとして直線的に増加します。

flowlogs-pipeline コンポーネントは、Pod 名、ラベル、namespace 情報などの Kubernetes メタデータでネットワークフローデータを強化します。このメタデータを取得するには、各 flowlogs-pipeline インスタンスは、リソースの変更を監視するインフォーマーを使用して Kubernetes API サーバーを個別にクエリーします。

10.1.1. API サーバーの大規模な負荷

デフォルトのデプロイメントモデルでは、flowlogs-pipeline インスタンスの数に直線的に API クエリーの数が増えます。

  • 各 flowlogs-pipeline Pod は、Pod、ノード、サービス、およびその他の Kubernetes リソースについて個別のインフォーマーを維持します。
  • すべてのインフォーマーは、API サーバーへの接続を監視します。
  • リソースの更新は、各 flowlogs-pipeline インスタンスに個別に送信されます。

たとえば、10 flowlogs-pipeline プロセッサー Pod を持つクラスターでは、API サーバーは、単一インスタンスと比較して、監視接続および更新通知を 10 倍処理します。flowlogs-pipeline 拡大されたネットワークトラフィックを処理するために水平方向にスケーリングすると、それに応じて API サーバーの負荷が掛けられます。

10.1.2. リソース消費パターン

このアーキテクチャーでは、いくつかのパフォーマンス上の課題が発生します。

メモリーフットプリント
各 flowlogs-pipeline インスタンスは、すべての監視された Kubernetes リソースの完全なインメモリーキャッシュを維持します。Pod およびサービス数が数千の大規模なクラスターでは、このキャッシュはインスタンスごとに大量のメモリーを消費する可能性があります。
CPU の使用率
冗長な API サーバー更新を処理し、個別のキャッシュを維持すると、すべての flowlogs-pipeline Pod 間で CPU 使用率が増加します。
API サーバーの影響
複数の flowlogs-pipeline インスタンスからの累積的な負荷は、API サーバーのパフォーマンスが低下する可能性があり、重要な操作のために API サーバーに依存する他のクラスターコンポーネントに影響を及ぼす可能性があります。
ネットワーク帯域幅
リソースの更新を複製すると、API サーバーと flowlogs-pipeline インスタンス間のネットワーク帯域幅が使用されます。

これらのリソース消費パターンは、特に以下を使用してクラスター内で発音されます。

  • アプリケーションを頻繁にスケールアップおよびスケールダウンする高い Pod シリンレート
  • 多数の namespace およびサービス
  • 高いネットワークトラフィックボリュームを処理するためにデプロイされた複数の flowlogs-pipeline インスタンス
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

Red Hat ドキュメントについて

Legal Notice

Theme

© 2026 Red Hat
トップに戻る