第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-pipelinePod は、Pod、ノード、サービス、およびその他の Kubernetes リソースについて個別のインフォーマーを維持します。 - すべてのインフォーマーは、API サーバーへの接続を監視します。
-
リソースの更新は、各
flowlogs-pipelineインスタンスに個別に送信されます。
たとえば、10 flowlogs-pipeline プロセッサー Pod を持つクラスターでは、API サーバーは、単一インスタンスと比較して、監視接続および更新通知を 10 倍処理します。flowlogs-pipeline 拡大されたネットワークトラフィックを処理するために水平方向にスケーリングすると、それに応じて API サーバーの負荷が掛けられます。
10.1.2. リソース消費パターン リンクのコピーリンクがクリップボードにコピーされました!
このアーキテクチャーでは、いくつかのパフォーマンス上の課題が発生します。
- メモリーフットプリント
-
各
flowlogs-pipelineインスタンスは、すべての監視された Kubernetes リソースの完全なインメモリーキャッシュを維持します。Pod およびサービス数が数千の大規模なクラスターでは、このキャッシュはインスタンスごとに大量のメモリーを消費する可能性があります。 - CPU の使用率
-
冗長な API サーバー更新を処理し、個別のキャッシュを維持すると、すべての
flowlogs-pipelinePod 間で CPU 使用率が増加します。 - API サーバーの影響
-
複数の
flowlogs-pipelineインスタンスからの累積的な負荷は、API サーバーのパフォーマンスが低下する可能性があり、重要な操作のために API サーバーに依存する他のクラスターコンポーネントに影響を及ぼす可能性があります。 - ネットワーク帯域幅
-
リソースの更新を複製すると、API サーバーと
flowlogs-pipelineインスタンス間のネットワーク帯域幅が使用されます。
これらのリソース消費パターンは、特に以下を使用してクラスター内で発音されます。
- アプリケーションを頻繁にスケールアップおよびスケールダウンする高い Pod シリンレート
- 多数の namespace およびサービス
-
高いネットワークトラフィックボリュームを処理するためにデプロイされた複数の
flowlogs-pipelineインスタンス