5.7. リソース管理およびパフォーマンスに関する考慮事項
ネットワーク監視に必要なリソースの量は、クラスターのサイズと、クラスターが可観測データを取り込んで保存するための要件によって異なります。リソースを管理し、クラスターのパフォーマンス基準を設定するには、次の設定を設定することを検討してください。これらの設定を設定すると、最適なセットアップと可観測性のニーズを満たす可能性があります。
次の設定は、最初からリソースとパフォーマンスを管理するのに役立ちます。
- eBPF サンプリング
-
サンプリング仕様
spec.agent.ebpf.sampling
を設定して、リソースを管理できます。サンプリング値が低いと、大量の計算、メモリー、およびストレージリソースが消費される可能性があります。これは、サンプリング比の値を指定することで軽減できます。値100
は、100 ごとに 1 つのフローがサンプリングされることを意味します。0
または1
の値は、すべてのフローがキャプチャーされることを意味します。値が小さいほど、返されるフローが増加し、派生メトリクスの精度が向上します。デフォルトでは、eBPF サンプリングは値 50 に設定されているため、50 ごとに 1 つのフローがサンプリングされます。より多くのサンプルフローは、より多くのストレージが必要になることにも注意してください。クラスターがどの設定を管理できるかを判断するには、デフォルト値から始めて実験的に調整することを検討してください。 - インターフェイスの制限または除外
-
spec.agent.ebpf.interfaces
およびspec.agent.ebpf.excludeInterfaces
の値を設定して、観測されるトラフィック全体を削減します。デフォルトでは、エージェントは、excludeInterfaces
およびlo
(ローカルインターフェイス) にリストされているインターフェイスを除く、システム内のすべてのインターフェイスを取得します。インターフェイス名は、使用される Container Network Interface (CNI) によって異なる場合があることに注意してください。
Network Observability をしばらく実行した後、次の設定を使用してパフォーマンスを微調整できます。
- リソース要件および制限
-
spec.agent.ebpf.resources
およびspec.processor.resources
仕様を使用して、リソース要件と制限をクラスターで予想される負荷とメモリー使用量に適応させます。多くの中規模のクラスターには、デフォルトの制限の 800MB で十分な場合があります。 - キャッシュの最大フロータイムアウト
-
eBPF エージェントの
spec.agent.ebpf.cacheMaxFlows
およびspec.agent.ebpf.cacheActiveTimeout
仕様を使用して、エージェントによってフローが報告される頻度を制御します。値が大きいほど、エージェントで生成されるトラフィックが少なくなり、これは CPU 負荷の低下と相関します。ただし、値を大きくするとメモリー消費量がわずかに増加し、フロー収集でより多くの遅延が発生する可能性があります。
5.7.1. リソースの留意事項
次の表は、特定のワークロードサイズのクラスターのリソースに関する考慮事項の例を示しています。
表に概要を示した例は、特定のワークロードに合わせて調整されたシナリオを示しています。各例は、ワークロードのニーズに合わせて調整を行うためのベースラインとしてのみ考慮してください。
極小規模 (10 ノード) | 小規模 (25 ノード) | 中規模 (65 ノード) [2] | 大規模 (120 ノード) [2] | |
---|---|---|---|---|
ワーカーノードの vCPU とメモリー | 4 仮想 CPU| 16 GiB メモリー [1] | 16 仮想 CPU| 64 GiB メモリー [1] | 16 仮想 CPU| 64 GiB メモリー [1] | 16 仮想 CPU| 64 GiB メモリー [1] |
LokiStack サイズ |
|
|
|
|
Network Observability コントローラーのメモリー制限 | 400 Mi (デフォルト) | 400 Mi (デフォルト) | 400 Mi (デフォルト) | 400 Mi (デフォルト) |
eBPF サンプリングレート | 50 (デフォルト) | 50 (デフォルト) | 50 (デフォルト) | 50 (デフォルト) |
eBPF メモリー制限 | 800 Mi (デフォルト) | 800 Mi (デフォルト) | 800 Mi (デフォルト) | 1600 Mi |
FLP メモリー制限 | 800 Mi (デフォルト) | 800 Mi (デフォルト) | 800 Mi (デフォルト) | 800 Mi (デフォルト) |
FLP Kafka パーティション | 該当なし | 48 | 48 | 48 |
Kafka コンシューマーレプリカ | 該当なし | 24 | 24 | 24 |
Kafka ブローカー | 該当なし | 3 (デフォルト) | 3 (デフォルト) | 3 (デフォルト) |
- AWS M6i インスタンスでテスト済み。
-
このワーカーとそのコントローラーに加えて、3 つのインフラノード (サイズ
M6i.12xlarge
) と 1 つのワークロードノード (サイズM6i.8xlarge
) がテストされました。
5.7.2. メモリーと CPU の合計平均使用量
次の表は、3 つの異なるテスト (Test 1
、Test 2
、および Test 3
) について、サンプリング値が 1、50、400 であるクラスターの合計リソース使用量の平均を示しています。テストは次の点で異なります。
-
Test 1
では、OpenShift Container Platform クラスター内の namespace、Pod、およびサービスの合計数を考慮し、eBPF エージェントに負荷をかけ、特定のクラスターサイズに対して多数のワークロードが発生するユースケースを表します。たとえば、Test 1
は、76 個の namespace、5153 個の Pod、および 2305 個の Service で構成されています。 -
Test 2
では、大量の Ingress トラフィックを考慮に入れます。 -
Test 3
では、OpenShift Container Platform クラスター内の namespace、Pod、およびサービスの合計数を考慮し、Test 1
よりも大規模な規模で eBPF エージェントに負荷をかけ、特定のクラスターサイズに対して多数のワークロードが発生するユースケースを表します。たとえば、Test 3
は、553 個の namespace、6998 個の Pod、および 2508 個の Service で構成されています。
さまざまなテストでさまざまなタイプのクラスター使用例が例示されているため、この表の数値を並べて直線的に比較することはできませんが、個人のクラスター使用状況を評価するベンチマークとして使用することを目的としています。表に概要を示した例は、特定のワークロードに合わせて調整されたシナリオを示しています。各例は、ワークロードのニーズに合わせて調整を行うためのベースラインとしてのみ考慮してください。
Prometheus にエクスポートされたメトリクスは、リソースの使用状況に影響を与える可能性があります。メトリクスのカーディナリティー値は、リソースがどの程度影響を受けるかを判断するのに役立ちます。詳細は、関連情報セクションの「ネットワークフローの形式」を参照してください。
サンプリング値 | パラメーター | テスト 1 (25 ノード) | テスト 2 (65 ノード) | テスト 3 (120 ノード) |
---|---|---|---|---|
Sampling = 1 | Loki を使用する場合 | |||
NetObserv の CPU 合計使用量 | 3.24 | 3.42 | 7.30 | |
NetObserv RSS (メモリー) の合計使用量 | 14.09 GB | 22.56 GB | 36.46 GB | |
Loki を使用しない場合 | ||||
NetObserv の CPU 合計使用量 | 2.40 | 2.43 | 5.59 | |
NetObserv RSS (メモリー) の合計使用量 | 6.85 GB | 10.39 GB | 13.92 GB | |
Sampling = 50 | Loki を使用する場合 | |||
NetObserv の CPU 合計使用量 | 2.04 | 2.36 | 3.31 | |
NetObserv RSS (メモリー) の合計使用量 | 8.79 GB | 19.14 GB | 21.07 GB | |
Loki を使用しない場合 | ||||
NetObserv の CPU 合計使用量 | 1.55 | 1.64 | 2.70 | |
NetObserv RSS (メモリー) の合計使用量 | 6.71 GB | 10.15 GB | 14.82 GB | |
Sampling = 400 | Loki を使用する場合 | |||
NetObserv の CPU 合計使用量 | 1.71 | 1.44 | 2.36 | |
NetObserv RSS (メモリー) の合計使用量 | 8.21 GB | 16.02 GB | 17.44 GB | |
Loki を使用しない場合 | ||||
NetObserv の CPU 合計使用量 | 1.31 | 1.06 | 1.83 | |
NetObserv RSS (メモリー) の合計使用量 | 7.01 GB | 10.70 GB | 13.26 GB |
概要: この表は、ネットワーク可観測性 (エージェント + FLP + Kafka + Loki) のリソースの平均合計使用量を示しています。
関連情報