28.5. Network Observability Operator の設定
Flow Collector API リソースを更新して、Network Observability Operator とそのマネージドコンポーネントを設定できます。Flow Collector は、インストール中に明示的に作成されます。このリソースはクラスター全体で動作するため、単一の FlowCollector のみが許可され、cluster という名前を付ける必要があります。
28.5.1. FlowCollector リソースを表示する リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールで YAML を直接表示および編集できます。
手順
-
Web コンソールで、Operators
Installed Operators に移動します。 - NetObserv Operator の Provided APIs 見出しの下で、Flow Collector を選択します。
-
cluster を選択し、YAML タブを選択します。そこで、
FlowCollectorリソースを変更して Network Observability Operator を設定できます。
以下の例は、OpenShift Container Platform Network Observability Operator のサンプル FlowCollector リソースを示しています。
FlowCollector リソースのサンプル
- 1
- エージェント仕様
spec.agent.typeはEBPFでなければなりません。eBPF は、OpenShift Container Platform でサポートされる唯一のオプションです。 - 2
- サンプリング仕様
spec.agent.ebpf.samplingを設定して、リソースを管理できます。サンプリング値が低いと、大量の計算、メモリー、およびストレージリソースが消費される可能性があります。これは、サンプリング比の値を指定することで軽減できます。値 100 は、100 ごとに 1 つのフローがサンプリングされることを意味します。0 または 1 の値は、すべてのフローがキャプチャーされることを意味します。値が低いほど、返されるフローが増加し、派生メトリクスの精度が向上します。デフォルトでは、eBPF サンプリングは値 50 に設定されているため、50 ごとに 1 つのフローがサンプリングされます。より多くのサンプルフローは、より多くのストレージが必要になることにも注意してください。デフォルト値から始めて経験的に調整し、クラスターが管理できる設定を決定することを推奨します。 - 3
- オプションの仕様
spec.processor.logTypes、spec.processor.conversationHeartbeatInterval、およびspec.processor.conversationEndTimeoutを設定して、会話追跡を有効にすることができます。有効にすると、Web コンソールで会話イベントをクエリーできるようになります。spec.processor.logTypesの値は次のとおりです:FLOWSCONVERSATIONS、ENDED_CONVERSATIONS、またはALL。ストレージ要件はALLで最も高く、ENDED_CONVERSATIONSで最も低くなります。 - 4
- Loki 仕様である
spec.lokiは、Loki クライアントを指定します。デフォルト値は、Loki Operator のインストールセクションに記載されている Loki インストールパスと一致します。Loki の別のインストール方法を使用した場合は、インストールに適切なクライアント情報を指定します。 - 5
spec.quickFilters仕様は、Web コンソールに表示されるフィルターを定義します。Applicationフィルターキー、src_namespaceおよびdst_namespaceは否定 (!) されているため、Applicationフィルターは、openshift-またはnetobservnamespace から発信されて いない、または宛先がないすべてのトラフィックを表示します。詳細は、以下のクイックフィルターの設定を参照してください。
28.5.2. Kafka を使用した Flow Collector リソースの設定 リンクのコピーリンクがクリップボードにコピーされました!
Kafka を使用するように FlowCollector リソースを設定できます。Kafka インスタンスを実行する必要があり、そのインスタンスで OpenShift Container Platform Network Observability 専用の Kafka トピックを作成する必要があります。詳細は、AMQ Streams を使用する Kafka など、Kafka ドキュメントを参照してください。
以下の例は、OpenShift Container Platform Network Observability Operator の FlowCollector リソースを変更して Kafka を使用する方法を示しています。
FlowCollector リソースの Kafka 設定のサンプル
- 1
- Kafka デプロイメントモデルを有効にするには、
spec.deploymentModelをDIRECTではなくKAFKAに設定します。 - 2
spec.kafka.addressは、Kafka ブートストラップサーバーのアドレスを参照します。ポート 9093 で TLS を使用するため、kafka-cluster-kafka-bootstrap.netobserv:9093など、必要に応じてポートを指定できます。- 3
spec.kafka.topicは、Kafka で作成されたトピックの名前と一致する必要があります。- 4
spec.kafka.tlsを使用して、Kafka との間のすべての通信を TLS または mTLS で暗号化できます。有効にした場合、Kafka CA 証明書は、flowlogs-pipelineプロセッサーコンポーネントがデプロイされている namespace (デフォルト:netobserv) と eBPF エージェントがデプロイされている namespace (デフォルト:netobserv-privileged) の両方で ConfigMap または Secret として使用できる必要があります。spec.kafka.tls.caCertで参照する必要があります。mTLS を使用する場合、クライアントシークレットはこれらの namespace でも利用でき (たとえば、AMQ Streams User Operator を使用して生成できます)、spec.kafka.tls.userCertで参照される必要があります。
28.5.3. 強化されたネットワークフローデータをエクスポートする リンクのコピーリンクがクリップボードにコピーされました!
オプションでネットワークフローを Kafka に送信して、Splunk、Elasticsearch、Fluentd などの Kafka 入力をサポートするプロセッサーまたはストレージでネットワークフローを利用できるようにすることができます。
前提条件
- インストールされた Kafka
手順
-
Web コンソールで、Operators
Installed Operators に移動します。 - NetObserv Operator の Provided APIs 見出しの下で、Flow Collector を選択します。
- cluster を選択し、YAML タブを選択します。
FlowCollectorを編集して、spec.exportersを次のように設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Network Observability Operator は、すべてのフローを設定された Kafka トピックにエクスポートします。
- 2
- Kafka との間のすべての通信を SSL/TLS または mTLS で暗号化できます。有効にした場合、Kafka CA 証明書は、
flowlogs-pipelineプロセッサーコンポーネントがデプロイされている namespace (デフォルト: netobserv) で、ConfigMap または Secret として使用できる必要があります。これはspec.exporters.tls.caCertで参照する必要があります。mTLS を使用する場合、クライアントシークレットはこれらの namespace でも利用可能であり (たとえば、AMQ Streams ユーザーオペレーターを使用して生成できます)、spec.exporters.tls.userCertで参照される必要があります。
- 設定後、ネットワークフローデータを JSON 形式で利用可能な出力に送信できます。詳細は、ネットワークフロー形式のリファレンス を参照してください。
28.5.4. Flow Collector リソースの更新 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールで YAML を編集する代わりに、flowcollector カスタムリソース (CR) にパッチを適用することで、eBPF サンプリングなどの仕様を設定できます。
手順
次のコマンドを実行して、
flowcollectorCR にパッチを適用し、spec.agent.ebpf.sampling値を更新します。oc patch flowcollector cluster --type=json -p "[{"op": "replace", "path": "/spec/agent/ebpf/sampling", "value": <new value>}] -n netobserv"$ oc patch flowcollector cluster --type=json -p "[{"op": "replace", "path": "/spec/agent/ebpf/sampling", "value": <new value>}] -n netobserv"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
28.5.5. クイックフィルターの設定 リンクのコピーリンクがクリップボードにコピーされました!
FlowCollector リソースでフィルターを変更できます。値を二重引用符で囲むと、完全一致が可能になります。それ以外の場合、テキスト値には部分一致が使用されます。キーの最後にあるバング (!) 文字は、否定を意味します。YAML の変更に関する詳細なコンテキストは、サンプルの FlowCollector リソースを参照してください。
フィルターマッチングタイプ "all of" または "any of" は、ユーザーがクエリーオプションから変更できる UI 設定です。これは、このリソース設定の一部ではありません。
使用可能なすべてのフィルターキーのリストを次に示します。
| Universal* | ソース | 送信先 | 説明 |
|---|---|---|---|
| namespace |
|
| 特定の namespace に関連するトラフィックをフィルタリングします。 |
| name |
|
| 特定の Pod、サービス、またはノード (ホストネットワークトラフィックの場合) など、特定のリーフリソース名に関連するトラフィックをフィルター処理します。 |
| kind |
|
| 特定のリソースの種類に関連するトラフィックをフィルタリングします。リソースの種類には、リーフリソース (Pod、Service、または Node)、または所有者リソース (Deployment および StatefulSet) が含まれます。 |
| owner_name |
|
| 特定のリソース所有者に関連するトラフィックをフィルタリングします。つまり、ワークロードまたは Pod のセットです。たとえば、Deployment 名、StatefulSet 名などです。 |
| resource |
|
|
一意に識別する正規名で示される特定のリソースに関連するトラフィックをフィルタリングします。正規の表記法は、namespace の種類の場合は |
| address |
|
| IP アドレスに関連するトラフィックをフィルタリングします。IPv4 と IPv6 がサポートされています。CIDR 範囲もサポートされています。 |
| mac |
|
| MAC アドレスに関連するトラフィックをフィルタリングします。 |
| port |
|
| 特定のポートに関連するトラフィックをフィルタリングします。 |
| host_address |
|
| Pod が実行しているホスト IP アドレスに関連するトラフィックをフィルタリングします。 |
| protocol | 該当なし | 該当なし | TCP や UDP などのプロトコルに関連するトラフィックをフィルタリングします。 |
-
ソースまたは宛先のいずれかのユニバーサルキーフィルター。たとえば、フィルタリング
name: 'my-pod'は、使用される一致タイプ (Match all または Match any) に関係なく、my-podからのすべてのトラフィックとmy-podへのすべてのトラフィックを意味します。
28.5.6. リソース管理およびパフォーマンスに関する考慮事項 リンクのコピーリンクがクリップボードにコピーされました!
ネットワーク監視に必要なリソースの量は、クラスターのサイズと、クラスターが可観測データを取り込んで保存するための要件によって異なります。リソースを管理し、クラスターのパフォーマンス基準を設定するには、次の設定を設定することを検討してください。これらの設定を設定すると、最適なセットアップと可観測性のニーズを満たす可能性があります。
次の設定は、最初からリソースとパフォーマンスを管理するのに役立ちます。
- 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 負荷の低下と相関します。ただし、値を大きくするとメモリー消費量がわずかに増加し、フロー収集でより多くの遅延が発生する可能性があります。
28.5.6.1. リソースの留意事項 リンクのコピーリンクがクリップボードにコピーされました!
次の表は、特定のワークロードサイズのクラスターのリソースに関する考慮事項の例を示しています。
表に概要を示した例は、特定のワークロードに合わせて調整されたシナリオを示しています。各例は、ワークロードのニーズに合わせて調整を行うためのベースラインとしてのみ考慮してください。
| 極小規模 (10 ノード) | 小規模 (25 ノード) | 中規模 (65 ノード) [2] | 大規模 (120 ノード) [2] | |
|---|---|---|---|---|
| ワーカーノードの vCPU とメモリー | 4 vCPU| 16GiB mem [1] | 16 vCPU| 64GiB mem [1] | 16 vCPU| 64GiB mem [1] | 16 vCPU| 64GiB Mem [1] |
| LokiStack サイズ |
|
|
|
|
| ネットワーク可観測性コントローラーのメモリー制限 | 400Mi (デフォルト) | 400Mi (デフォルト) | 400Mi (デフォルト) | 800 Mi |
| eBPF サンプリングレート | 50 (デフォルト) | 50 (デフォルト) | 50 (デフォルト) | 50 (デフォルト) |
| eBPF メモリー制限 | 800Mi (デフォルト) | 800Mi (デフォルト) | 2000Mi | 800Mi (デフォルト) |
| FLP メモリー制限 | 800Mi (デフォルト) | 800Mi (デフォルト) | 800Mi (デフォルト) | 800Mi (デフォルト) |
| FLP Kafka パーティション | 該当なし | 48 | 48 | 48 |
| Kafka コンシューマーレプリカ | 該当なし | 24 | 24 | 24 |
| Kafka ブローカー | 該当なし | 3 (デフォルト) | 3 (デフォルト) | 3 (デフォルト) |
- AWS M6i インスタンスでテスト済み。
-
このワーカーとそのコントローラーに加えて、3 つのインフラノード (サイズ
M6i.12xlarge) と 1 つのワークロードノード (サイズM6i.8xlarge) がテストされました。