28.5. Network Observability Operator の設定

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 リソースのサンプル

apiVersion: flows.netobserv.io/v1beta1
kind: FlowCollector
metadata:
  name: cluster
spec:
  namespace: netobserv
  deploymentModel: DIRECT
  agent:
    type: EBPF                                1
    ebpf:
      sampling: 50                            2
      logLevel: info
      privileged: false
      resources:
        requests:
          memory: 50Mi
          cpu: 100m
        limits:
          memory: 800Mi
  processor:
    logLevel: info
    resources:
      requests:
        memory: 100Mi
        cpu: 100m
      limits:
        memory: 800Mi
    conversationEndTimeout: 10s
    logTypes: FLOWS                            3
    conversationHeartbeatInterval: 30s
  loki:                                       4
    url: 'https://loki-gateway-http.netobserv.svc:8080/api/logs/v1/network'
    statusUrl: 'https://loki-query-frontend-http.netobserv.svc:3100/'
    authToken: FORWARD
    tls:
      enable: true
      caCert:
        type: configmap
        name: loki-gateway-ca-bundle
        certFile: service-ca.crt
  consolePlugin:
    register: true
    logLevel: info
    portNaming:
      enable: true
      portNames:
        "3100": loki
    quickFilters:                             5
    - name: Applications
      filter:
        src_namespace!: 'openshift-,netobserv'
        dst_namespace!: 'openshift-,netobserv'
      default: true
    - name: Infrastructure
      filter:
        src_namespace: 'openshift-,netobserv'
        dst_namespace: 'openshift-,netobserv'
    - name: Pods network
      filter:
        src_kind: 'Pod'
        dst_kind: 'Pod'
      default: true
    - name: Services network
      filter:
        dst_kind: 'Service'

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 の値は次のとおりです: FLOWS CONVERSATIONS、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- または netobserv namespace から発信されて いない、または宛先がないすべてのトラフィックを表示します。詳細は、以下のクイックフィルターの設定を参照してください。

関連情報

会話追跡の詳細は、Working with conversations を参照してください。

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 設定のサンプル

  deploymentModel: KAFKA                                    1
  kafka:
    address: "kafka-cluster-kafka-bootstrap.netobserv"      2
    topic: network-flows                                    3
    tls:
      enable: false                                         4

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 を次のように設定します。
```
apiVersion: flows.netobserv.io/v1alpha1
kind: FlowCollector
metadata:
  name: cluster
spec:
  exporters:
  - type: KAFKA
      kafka:
        address: "kafka-cluster-kafka-bootstrap.netobserv"
        topic: netobserv-flows-export   1
        tls:
          enable: false                 2
```
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 サンプリングなどの仕様を設定できます。

手順

次のコマンドを実行して、flowcollector CR にパッチを適用し、spec.agent.ebpf.sampling 値を更新します。

$ oc patch flowcollector cluster --type=json -p "[{"op": "replace", "path": "/spec/agent/ebpf/sampling", "value": <new value>}] -n netobserv"

28.5.5. クイックフィルターの設定

FlowCollector リソースでフィルターを変更できます。値を二重引用符で囲むと、完全一致が可能になります。それ以外の場合、テキスト値には部分一致が使用されます。キーの最後にあるバング (!) 文字は、否定を意味します。YAML の変更に関する詳細なコンテキストは、サンプルの FlowCollector リソースを参照してください。

注記

フィルターマッチングタイプ "all of" または "any of" は、ユーザーがクエリーオプションから変更できる UI 設定です。これは、このリソース設定の一部ではありません。

使用可能なすべてのフィルターキーのリストを次に示します。

表28.2 フィルターキー
Universal*	ソース	送信先	説明
namespace	`src_namespace`	`dst_namespace`	特定の namespace に関連するトラフィックをフィルタリングします。
name	`src_name`	`dst_name`	特定の Pod、サービス、またはノード (ホストネットワークトラフィックの場合) など、特定のリーフリソース名に関連するトラフィックをフィルター処理します。
kind	`src_kind`	`dst_kind`	特定のリソースの種類に関連するトラフィックをフィルタリングします。リソースの種類には、リーフリソース (Pod、Service、または Node)、または所有者リソース (Deployment および StatefulSet) が含まれます。
owner_name	`src_owner_name`	`dst_owner_name`	特定のリソース所有者に関連するトラフィックをフィルタリングします。つまり、ワークロードまたは Pod のセットです。たとえば、Deployment 名、StatefulSet 名などです。
resource	`src_resource`	`dst_resource`	一意に識別する正規名で示される特定のリソースに関連するトラフィックをフィルタリングします。正規の表記法は、namespace の種類の場合は `kind.namespace.name`、ノードの場合は `node.name` です。たとえば、`Deployment.my-namespace.my-web-server` です。
address	`src_address`	`dst_address`	IP アドレスに関連するトラフィックをフィルタリングします。IPv4 と IPv6 がサポートされています。CIDR 範囲もサポートされています。
mac	`src_mac`	`dst_mac`	MAC アドレスに関連するトラフィックをフィルタリングします。
port	`src_port`	`dst_port`	特定のポートに関連するトラフィックをフィルタリングします。
host_address	`src_host_address`	`dst_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. リソースの留意事項

次の表は、特定のワークロードサイズのクラスターのリソースに関する考慮事項の例を示しています。

重要

表に概要を示した例は、特定のワークロードに合わせて調整されたシナリオを示しています。各例は、ワークロードのニーズに合わせて調整を行うためのベースラインとしてのみ考慮してください。

表28.3 リソースの推奨事項
	極小規模 (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 サイズ	`1x.extra-small`	`1x.small`	`1x.small`	`1x.medium`
ネットワーク可観測性コントローラーのメモリー制限	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) がテストされました。

28.5.1. FlowCollector リソースを表示する

28.5.2. Kafka を使用した Flow Collector リソースの設定

28.5.3. 強化されたネットワークフローデータをエクスポートする

28.5.4. Flow Collector リソースの更新

28.5.5. クイックフィルターの設定

28.5.6. リソース管理およびパフォーマンスに関する考慮事項

28.5.6.1. リソースの留意事項

詳細情報

試用、購入および販売

コミュニティー

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

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

会社概要

Red Hat legal and privacy links

Red Hat legal and privacy links