Network Observability

1. Pod ごとなど。
2. ワークロードまたは namespace ごとなど。
3. パケットドロップの統計情報は Loki でのみ利用可能です。

手順

1. OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
2. 使用可能な Operator のリストから Loki Operator を選択し、Install をクリックします。
3. Installation Mode で、All namespaces on the cluster を選択します。

検証

1. Loki Operator がインストールされていることを確認します。Operators→ Installed Operators ページにアクセスして、Loki Operator を探します。
2. Loki Operator がすべてのプロジェクトで Succeeded の Status でリストされていることを確認します。

手順

1. OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
2. OperatorHub で使用可能な Operator のリストから Network Observability Operator を選択し、Install をクリックします。
3. Enable Operator recommended cluster monitoring on this Namespace チェックボックスを選択します。
4. Operators → Installed Operators に移動します。Network Observability の Provided APIs で、Flow Collector リンクを選択します。

5. Flow Collector タブに移動し、Create FlowCollector をクリックします。フォームビューで次の選択を行います。

   1. spec.agent.ebpf.Sampling: フローのサンプリングサイズを指定します。サンプリングサイズが小さいほど、リソース使用率への影響が大きくなります。詳細は、「FlowCollector API リファレンス」の spec.agent.ebpf を参照してください。
   2. Loki を使用していない場合は、Loki クライアント設定 をクリックし、Enable を False に変更します。デフォルトでは設定は True です。

   3. Loki を使用している場合は、次の仕様を設定します。

      1. spec.loki.mode: これを LokiStack モードに設定すると、URL、TLS、クラスターロール、クラスターロールバインディング、および authToken 値が自動的に設定されます。または、Manual モードを使用すると、これらの設定をより詳細に制御できます。
      2. spec.loki.lokistack.name: これは LokiStack リソースの名前に設定します。このドキュメントでは、loki を使用します。
   4. オプション: 使用している環境が大規模な場合は、回復性とスケーラビリティーが高い方法でデータを転送するために、Kafka を使用して FlowCollector を設定することを検討してください。「Flow Collector 設定に関する重要な考慮事項」セクションの「Kafka ストレージを使用した Flow Collector リソースの設定」を参照してください。
   5. オプション: 次の FlowCollector 作成手順に進む前に、他のオプションを設定します。たとえば、Loki を使用しないことを選択した場合は、Kafka または IPFIX へのフローのエクスポートを設定できます。「Flow Collector 設定に関する重要な考慮事項」セクションの「エンリッチされたネットワークフローデータを Kafka および IPFIX にエクスポートする」などを参照してください。
6. Create をクリックします。

手順

1. FlowCollector カスタムリソースを削除します。

   1. Provided APIs 列の Network Observability Operator の横にある Flow Collector をクリックします。
   2. cluster のオプションメニュー をクリックし、Delete FlowCollector を選択します。

2. Network Observability Operator をアンインストールします。

   1. Operators → Installed Operators エリアに戻ります。
   2. Network Observability Operator の隣にあるオプションメニュー をクリックし、Uninstall Operator を選択します。
   3. Home → Projects を選択し、openshift-netobserv-operator を選択します。
   4. Actions に移動し、Delete Project を選択します。

3. FlowCollector カスタムリソース定義 (CRD) を削除します。

   1. Administration → CustomResourceDefinitions に移動します。
   2. FlowCollector を探し、オプションメニュー をクリックします。

   3. Delete CustomResourceDefinition を選択します。

      重要

      Loki Operator と Kafka は、インストールされていた場合、残っているため、個別に削除する必要があります。さらに、オブジェクトストアに保存された残りのデータ、および削除する必要がある永続ボリュームがある場合があります。

手順

1. 次のコマンドを実行して、FlowCollector の状態を表示します。

   $ oc get flowcollector/cluster

   出力例

   NAME      AGENT   SAMPLING (EBPF)   DEPLOYMENT MODEL   STATUS
   cluster   EBPF    50                DIRECT             Ready

2. 次のコマンドを実行して、netobserv namespace で実行している Pod のステータスを確認します。

   $ oc get pods -n netobserv

   出力例

   NAME                              READY   STATUS    RESTARTS   AGE
   flowlogs-pipeline-56hbp           1/1     Running   0          147m
   flowlogs-pipeline-9plvv           1/1     Running   0          147m
   flowlogs-pipeline-h5gkb           1/1     Running   0          147m
   flowlogs-pipeline-hh6kf           1/1     Running   0          147m
   flowlogs-pipeline-w7vv5           1/1     Running   0          147m
   netobserv-plugin-cdd7dc6c-j8ggp   1/1     Running   0          147m

1. 次のコマンドを入力して、namespace netobserv-privileged で実行している Pod のステータスを確認します。

   $ oc get pods -n netobserv-privileged

   出力例

   NAME                         READY   STATUS    RESTARTS   AGE
   netobserv-ebpf-agent-4lpp6   1/1     Running   0          151m
   netobserv-ebpf-agent-6gbrk   1/1     Running   0          151m
   netobserv-ebpf-agent-klpl9   1/1     Running   0          151m
   netobserv-ebpf-agent-vrcnf   1/1     Running   0          151m
   netobserv-ebpf-agent-xf5jh   1/1     Running   0          151m

1. Loki Operator を使用している場合は、次のコマンドを実行して、openshift-operators-redhat namespace で実行している Pod のステータスを確認します。

   $ oc get pods -n openshift-operators-redhat

   出力例

   NAME                                                READY   STATUS    RESTARTS   AGE
   loki-operator-controller-manager-5f6cff4f9d-jq25h   2/2     Running   0          18h
   lokistack-compactor-0                               1/1     Running   0          18h
   lokistack-distributor-654f87c5bc-qhkhv              1/1     Running   0          18h
   lokistack-distributor-654f87c5bc-skxgm              1/1     Running   0          18h
   lokistack-gateway-796dc6ff7-c54gz                   2/2     Running   0          18h
   lokistack-index-gateway-0                           1/1     Running   0          18h
   lokistack-index-gateway-1                           1/1     Running   0          18h
   lokistack-ingester-0                                1/1     Running   0          18h
   lokistack-ingester-1                                1/1     Running   0          18h
   lokistack-ingester-2                                1/1     Running   0          18h
   lokistack-querier-66747dc666-6vh5x                  1/1     Running   0          18h
   lokistack-querier-66747dc666-cjr45                  1/1     Running   0          18h
   lokistack-querier-66747dc666-xh8rq                  1/1     Running   0          18h
   lokistack-query-frontend-85c6db4fbd-b2xfb           1/1     Running   0          18h
   lokistack-query-frontend-85c6db4fbd-jm94f           1/1     Running   0          18h

手順

1. 次のコマンドを実行して、Network Observability Operator のステータスと設定を表示します。

   $ oc describe flowcollector/cluster

手順

1. Web コンソールで、Operators → Installed Operators に移動します。
2. NetObserv Operator の Provided APIs 見出しの下で、Flow Collector を選択します。
3. cluster を選択し、YAML タブを選択します。そこで、FlowCollector リソースを変更して Network Observability Operator を設定できます。

手順

1. Web コンソールで、Operators → Installed Operators に移動します。
2. Network Observability Operator の Provided APIs という見出しの下で、Flow Collector を選択します。
3. クラスターを選択し、YAML タブをクリックします。
4. 次のサンプル YAML に示すように、Kafka を使用するように OpenShift Container Platform Network Observability Operator の FlowCollector リソースを変更します。

手順

1. Web コンソールで、Operators → Installed Operators に移動します。
2. NetObserv Operator の Provided APIs 見出しの下で、Flow Collector を選択します。
3. cluster を選択し、YAML タブを選択します。

4. FlowCollector を編集して、spec.exporters を次のように設定します。

   apiVersion: flows.netobserv.io/v1beta2
   kind: FlowCollector
   metadata:
     name: cluster
   spec:
     exporters:
     - type: Kafka                         1
         kafka:
           address: "kafka-cluster-kafka-bootstrap.netobserv"
           topic: netobserv-flows-export   2
           tls:
             enable: false                 3
     - type: IPFIX                         4
         ipfix:
           targetHost: "ipfix-collector.ipfix.svc.cluster.local"
           targetPort: 4739
           transport: tcp or udp           5
    -  type: OpenTelemetry                 6
         openTelemetry:
           targetHost: my-otelcol-collector-headless.otlp.svc
           targetPort: 4317
           type: grpc                      7
           logs:                           8
             enable: true
           metrics:                        9
             enable: true
             prefix: netobserv
             pushTimeInterval: 20s         10
             expiryTime: 2m
      #    fieldsMapping:                  11
      #      input: SrcAddr
      #      output: source.address

   1 4 6

   フローを IPFIX、OpenTelemetry、Kafka に個別または同時にエクスポートできます。

   2

   Network Observability Operator は、すべてのフローを設定された Kafka トピックにエクスポートします。

   3

   Kafka との間のすべての通信を SSL/TLS または mTLS で暗号化できます。有効にした場合、Kafka CA 証明書は、flowlogs-pipeline プロセッサーコンポーネントがデプロイされている namespace (デフォルト: netobserv) で、ConfigMap または Secret として使用できる必要があります。これは spec.exporters.tls.caCert で参照する必要があります。mTLS を使用する場合、クライアントシークレットはこれらの namespace でも利用可能であり (たとえば、AMQ Streams User Operator を使用して生成できます)、spec.exporters.tls.userCert で参照される必要があります。

   5

   オプションでトランスポートを指定できます。デフォルト値は tcp ですが、udp を指定することもできます。

   7

   OpenTelemetry 接続のプロトコル。使用可能なオプションは http と grpc です。

   8

   Loki 用に作成されたログと同じログをエクスポートするための OpenTelemetry 設定。

   9

   Prometheus 用に作成されたメトリクスと同じメトリクスをエクスポートするための OpenTelemetry 設定。これらの設定を、FlowMetrics カスタムリソースを使用して定義したカスタムメトリクスとともに、FlowCollector カスタムリソースの spec.processor.metrics.includeList パラメーターで指定します。

   10

   メトリクスを OpenTelemetry コレクターに送信する時間間隔。

   11

   オプション: Network Observability のネットワークフローの形式は、OpenTelemetry 準拠の形式に合わせて、自動的に名前が変更されます。fieldsMapping 仕様を使用すると、OpenTelemetry 形式の出力をカスタマイズできます。たとえば、YAML サンプルでは、SrcAddr が Network Observability の入力フィールドです。これは、OpenTelemetry の出力で source.address に名前が変更されます。「ネットワークフローの形式リファレンス」で、Network Observability の形式と OpenTelemetry の形式の両方を確認できます。

手順

1. 次のコマンドを実行して、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"

手順

1. .Web コンソールで、Operators → Installed Operators ページに移動します。
2. Network Observability の Provided APIs という見出しの下で、Flow Collector を選択します。
3. cluster を選択し、YAML タブを選択します。

4. FlowCollector CR を設定します。設定例は次のとおりです。

   ネットワークポリシー用の FlowCollector CR の例

   apiVersion: flows.netobserv.io/v1beta2
   kind: FlowCollector
   metadata:
     name: cluster
   spec:
     namespace: netobserv
     networkPolicy:
       enable: true   1
       additionalNamespaces: ["openshift-console", "openshift-monitoring"] 2
   # ...

   1

   デフォルトでは、enable 値は false です。

   2

   デフォルト値は ["openshift-console", "openshift-monitoring"] です。

手順

1. Networking → NetworkPolicies に移動します。
2. Project ドロップダウンメニューから netobserv プロジェクトを選択します。
3. ポリシーに名前を付けます。この例では、ポリシー名は allow-ingress です。
4. Add ingress rule を 3 回クリックして、3 つのイングレスルールを作成します。

5. フォームで以下を指定します。

   1. 最初の Ingress rule に対して以下の仕様を作成します。

      1. Add allowed source ドロップダウンメニューから、Allow pods from the same namespace を選択します。

   2. 2 番目の Ingress rule に対して次の仕様を作成します。

      1. Add allowed source ドロップダウンメニューから、Allow pods from inside the cluster を選択します。
      2. + Add namespace selector をクリックします。
      3. ラベル kubernetes.io/metadata.name とセレクター openshift-console を追加します。

   3. 3 番目の Ingress rule に対して次の仕様を作成します。

      1. Add allowed source ドロップダウンメニューから、Allow pods from inside the cluster を選択します。
      2. + Add namespace selector をクリックします。
      3. ラベル kubernetes.io/metadata.name とセレクター openshift-monitoring を追加します。

検証

1. Observe → Network Traffic に移動します。
2. Traffic Flows タブまたは任意のタブを表示して、データが表示されていることを確認します。
3. Observe → Dashboards に移動します。NetObserv/Health の選択で、フローが取り込まれて Loki に送信されていることを確認します (最初のグラフに示されています)。

手順

1. Web コンソールの Observe → Dashboards で、Netobserv ダッシュボードを選択します。

2. 次のカテゴリーのネットワークトラフィックメトリクスを表示します。各カテゴリーには、ノード、namespace、送信元、宛先ごとのサブセットがあります。

   • バイトレート
   • パケットドロップ
   • DNS
   • RTT
3. Netobserv/Health ダッシュボードを選択します。

4. Operator の健全性に関する次のカテゴリーのメトリクスを表示します。各カテゴリーには、ノード、namespace、送信元、宛先ごとのサブセットがあります。

   • フロー
   • フローのオーバーヘッド
   • フローレート
   • エージェント
   • プロセッサー
   • Operator

手順

1. インポートアイコン + をクリックして、YAML ファイルを作成します。

2. アラートルール設定を YAML ファイルに追加します。次の YAML サンプルでは、クラスターの Ingress トラフィックが宛先ワークロードごとの指定しきい値 (10 MBps) に達したときに、アラートが作成されます。

   apiVersion: monitoring.openshift.io/v1
   kind: AlertingRule
   metadata:
     name: netobserv-alerts
     namespace: openshift-monitoring
   spec:
     groups:
     - name: NetObservAlerts
       rules:
       - alert: NetObservIncomingBandwidth
         annotations:
           message: |-
             {{ $labels.job }}: incoming traffic exceeding 10 MBps for 30s on {{ $labels.DstK8S_OwnerType }} {{ $labels.DstK8S_OwnerName }} ({{ $labels.DstK8S_Namespace }}).
           summary: "High incoming traffic."
         expr: sum(rate(netobserv_workload_ingress_bytes_total     {SrcK8S_Namespace="openshift-ingress"}[1m])) by (job, DstK8S_Namespace, DstK8S_OwnerName, DstK8S_OwnerType) > 10000000      1
         for: 30s
         labels:
           severity: warning

   1

   netobserv_workload_ingress_bytes_total メトリクスは、spec.processor.metrics.includeList でデフォルトで有効です。

3. Create をクリックして設定ファイルをクラスターに適用します。

手順

1. Web コンソールで、Operators → Installed Operators に移動します。
2. NetObserv Operator の Provided APIs 見出しで、FlowMetric を選択します。
3. Project: ドロップダウンリストで、Network Observability Operator インスタンスのプロジェクトを選択します。
4. Create FlowMetric をクリックします。

5. 次のサンプル設定と同じように FlowMetric リソースを設定します。

   例8.1 クラスターの外部ソースから受信した Ingress バイト数を追跡するメトリクスを生成する

   apiVersion: flows.netobserv.io/v1alpha1
   kind: FlowMetric
   metadata:
     name: flowmetric-cluster-external-ingress-traffic
     namespace: netobserv                              1
   spec:
     metricName: cluster_external_ingress_bytes_total  2
     type: Counter                                     3
     valueField: Bytes
     direction: Ingress                                4
     labels: [DstK8S_HostName,DstK8S_Namespace,DstK8S_OwnerName,DstK8S_OwnerType] 5
     filters:                                          6
     - field: SrcSubnetLabel
       matchType: Absence

   1

   FlowMetric リソースは、FlowCollector spec.namespace で定義された namespace (デフォルトでは netobserv) に作成する必要があります。

   2

   Prometheus メトリクスの名前。Web コンソールでは接頭辞 netobserv-<metricName> とともに表示されます。

   3

   type はメトリクスのタイプを指定します。Counter type は、バイト数またはパケット数をカウントするのに役立ちます。

   4

   キャプチャーするトラフィックの方向。指定しない場合は、Ingress と Egress の両方がキャプチャーされ、重複したカウントが発生する可能性があります。

   5

   ラベルは、メトリクスの外観とさまざまなエンティティー間の関係を定義します。また、メトリクスのカーディナリティーも定義します。たとえば、SrcK8S_Name はカーディナリティーが高いメトリクスです。

   6

   リストされた基準に基づいて結果を絞り込みます。この例では、SrcSubnetLabel が存在しないフローのみを照合することによって、クラスターの外部トラフィックのみを選択します。これは、(spec.processor.subnetLabels により) サブネットラベル機能が有効になっていることを前提としています。この機能はデフォルトで有効になっています。

   検証

   1. Pod が更新されたら、Observe → Metrics に移動します。
   2. Expression フィールドにメトリクス名を入力して、対応する結果を表示します。topk(5, sum(rate(netobserv_cluster_external_ingress_bytes_total{DstK8S_Namespace="my-namespace"}[2m])) by (DstK8S_HostName, DstK8S_OwnerName, DstK8S_OwnerType)) などの式を入力することもできます。

   例8.2 クラスター外部 Ingress トラフィックの RTT 遅延を表示する

   apiVersion: flows.netobserv.io/v1alpha1
   kind: FlowMetric
   metadata:
     name: flowmetric-cluster-external-ingress-rtt
     namespace: netobserv    1
   spec:
     metricName: cluster_external_ingress_rtt_seconds
     type: Histogram                 2
     valueField: TimeFlowRttNs
     direction: Ingress
     labels: [DstK8S_HostName,DstK8S_Namespace,DstK8S_OwnerName,DstK8S_OwnerType]
     filters:
     - field: SrcSubnetLabel
       matchType: Absence
     - field: TimeFlowRttNs
       matchType: Presence
     divider: "1000000000"      3
     buckets: [".001", ".005", ".01", ".02", ".03", ".04", ".05", ".075", ".1", ".25", "1"]  4

   1

   FlowMetric リソースは、FlowCollector spec.namespace で定義された namespace (デフォルトでは netobserv) に作成する必要があります。

   2

   type はメトリクスのタイプを指定します。Histogram type は、遅延値 (TimeFlowRttNs) に役立ちます。

   3

   ラウンドトリップタイム (RTT) はフロー内でナノ秒単位で提供されるため、秒単位に変換するには除数として 10 億を使用します。これは Prometheus ガイドラインの標準です。

   4

   カスタムバケットは RTT の精度を指定します。最適な精度は 5 ミリ秒から 250 ミリ秒の範囲です。

   検証

   1. Pod が更新されたら、Observe → Metrics に移動します。
   2. Expression フィールドにメトリクス名を入力して、対応する結果を表示できます。

手順

1. Web コンソールで、Operators → Installed Operators に移動します。
2. NetObserv Operator の Provided APIs 見出しで、FlowMetric を選択します。
3. Project: ドロップダウンリストで、Network Observability Operator インスタンスのプロジェクトを選択します。
4. Create FlowMetric をクリックします。
5. 次のサンプル設定と同じように FlowMetric リソースを設定します。

手順

1. Web コンソールで、Operators → Installed Operators に移動します。
2. NetObserv Operator の Provided APIs 見出しで、FlowMetric を選択します。
3. Project ドロップダウンリストで、Network Observability Operator インスタンスのプロジェクトを選択します。
4. Create FlowMetric をクリックします。

5. FlowMetric リソースを作成して、次の設定を追加します。

   TCP フラグを使用して、宛先ホストとリソースごとにフローをカウントする設定

   apiVersion: flows.netobserv.io/v1alpha1
   kind: FlowMetric
   metadata:
     name: flows-with-flags-per-destination
   spec:
     metricName: flows_with_flags_per_destination_total
     type: Counter
     labels: [SrcSubnetLabel,DstSubnetLabel,DstK8S_Name,DstK8S_Type,DstK8S_HostName,DstK8S_Namespace,Flags]

   TCP フラグを使用して、ソースホストとリソースごとにフローをカウントする設定

   apiVersion: flows.netobserv.io/v1alpha1
   kind: FlowMetric
   metadata:
     name: flows-with-flags-per-source
   spec:
     metricName: flows_with_flags_per_source_total
     type: Counter
     labels: [DstSubnetLabel,SrcSubnetLabel,SrcK8S_Name,SrcK8S_Type,SrcK8S_HostName,SrcK8S_Namespace,Flags]

6. SYN フラッディングを警告するための次の AlertingRule リソースをデプロイします。

   SYN フラッディングの AlertingRule

   apiVersion: monitoring.openshift.io/v1
   kind: AlertingRule
   metadata:
     name: netobserv-syn-alerts
     namespace: openshift-monitoring
   # ...
     spec:
     groups:
     - name: NetObservSYNAlerts
       rules:
       - alert: NetObserv-SYNFlood-in
         annotations:
           message: |-
             {{ $labels.job }}: incoming SYN-flood attack suspected to Host={{ $labels.DstK8S_HostName}}, Namespace={{ $labels.DstK8S_Namespace }}, Resource={{ $labels.DstK8S_Name }}. This is characterized by a high volume of SYN-only flows with different source IPs and/or ports.
           summary: "Incoming SYN-flood"
         expr: sum(rate(netobserv_flows_with_flags_per_destination_total{Flags="2"}[1m])) by (job, DstK8S_HostName, DstK8S_Namespace, DstK8S_Name) > 300      1
         for: 15s
         labels:
           severity: warning
           app: netobserv
       - alert: NetObserv-SYNFlood-out
         annotations:
           message: |-
             {{ $labels.job }}: outgoing SYN-flood attack suspected from Host={{ $labels.SrcK8S_HostName}}, Namespace={{ $labels.SrcK8S_Namespace }}, Resource={{ $labels.SrcK8S_Name }}. This is characterized by a high volume of SYN-only flows with different source IPs and/or ports.
           summary: "Outgoing SYN-flood"
         expr: sum(rate(netobserv_flows_with_flags_per_source_total{Flags="2"}[1m])) by (job, SrcK8S_HostName, SrcK8S_Namespace, SrcK8S_Name) > 300       2
         for: 15s
         labels:
           severity: warning
           app: netobserv
   # ...

   1 2

   この例では、アラートのしきい値は 300 ですが、この値は環境に応じて調整できます。しきい値が低すぎると誤検出が発生する可能性があります。また、しきい値が高すぎると実際の攻撃を見逃す可能性があります。

検証

1. Web コンソールで、Network Traffic テーブルビューの Manage Columns をクリックし、TCP flags をクリックします。
2. Network Traffic テーブルビューで、TCP protocol SYN TCPFlag でフィルタリングします。同じ byteSize を持つフローが多数ある場合は、SYN フラッドが発生しています。
3. Observe → Alerting に移動し、Alerting Rules タブを選択します。
4. netobserv-synflood-in alert でフィルタリングします。SYN フラッディングが発生すると、アラートが起動するはずです。

手順

1. Web コンソールの Administrator パースペクティブから、Observe → Dashboards に移動します。
2. Dashboards ドロップダウンメニューから、Netobserv/Health を選択します。
3. ページに表示された Operator の健全性に関するメトリクスを確認します。

手順

1. インポートアイコン + をクリックして、YAML ファイルを作成します。

2. アラートルール設定を YAML ファイルに追加します。次の YAML サンプルでは、Loki のレート制限に達した場合にアラートが作成されます。

   apiVersion: monitoring.openshift.io/v1
   kind: AlertingRule
   metadata:
     name: loki-alerts
     namespace: openshift-monitoring
   spec:
     groups:
     - name: LokiRateLimitAlerts
       rules:
       - alert: LokiTenantRateLimit
         annotations:
           message: |-
             {{ $labels.job }} {{ $labels.route }} is experiencing 429 errors.
           summary: "At any number of requests are responded with the rate limit error code."
         expr: sum(irate(loki_request_duration_seconds_count{status_code="429"}[1m])) by (job, namespace, route) / sum(irate(loki_request_duration_seconds_count[1m])) by (job, namespace, route) * 100 > 0
         for: 10s
         labels:
           severity: warning

3. Create をクリックして設定ファイルをクラスターに適用します。

手順

1. Web コンソールで、Operators → Installed Operators に移動します。
2. Network Observability Operator の Provided APIs 見出しの下で、Flow Collector を選択します。
3. cluster を選択し、YAML タブを選択します。
4. 次の YAML サンプルに示すように、spec.agent.ebpf.cacheMaxFlows の値を増やします。

手順

1. Web コンソールで、Operators → Installed Operators に移動します。
2. NetObserv Operator の Provided APIs 見出しの下で、Flow Collector を選択します。
3. cluster を選択し、YAML タブを選択します。

4. FlowCollector カスタムリソースを設定します。設定例は次のとおりです。

   SR-IOV モニタリング用に FlowCollector を設定する

   apiVersion: flows.netobserv.io/v1beta2
   kind: FlowCollector
   metadata:
     name: cluster
   spec:
     namespace: netobserv
     deploymentModel: Direct
     agent:
       type: eBPF
       ebpf:
         privileged: true   1

   1

   SR-IOV モニタリングを有効にするには、spec.agent.ebpf.privileged フィールドの値を true に設定する必要があります。

手順

1. 次のコマンドを実行して、仮想マシンのランチャー Pod に関する情報を取得します。この情報はステップ 5 で使用します。

   $ oc get pod virt-launcher-<vm_name>-<suffix> -n <namespace> -o yaml

   apiVersion: v1
   kind: Pod
   metadata:
     annotations:
       k8s.v1.cni.cncf.io/network-status: |-
         [{
           "name": "ovn-kubernetes",
           "interface": "eth0",
           "ips": [
             "10.129.2.39"
           ],
           "mac": "0a:58:0a:81:02:27",
           "default": true,
           "dns": {}
         },
         {
           "name": "my-vms/l2-network",   1
           "interface": "podc0f69e19ba2", 2
           "ips": [                       3
             "10.10.10.15"
           ],
           "mac": "02:fb:f8:00:00:12",    4
           "dns": {}
         }]
     name: virt-launcher-fedora-aqua-fowl-13-zr2x9
     namespace: my-vms
   spec:
   #  ...
   status:
   #  ...

   1

   セカンダリーネットワークの名前。

   2

   セカンダリーネットワークのネットワークインターフェイス名。

   3

   セカンダリーネットワークで使用される IP のリスト。

   4

   セカンダリーネットワークに使用される MAC アドレス。

2. Web コンソールで、Operators → Installed Operators に移動します。
3. NetObserv Operator の Provided APIs 見出しの下で、Flow Collector を選択します。
4. cluster を選択し、YAML タブを選択します。

5. 追加のネットワーク調査で調べた情報に基づいて FlowCollector を設定します。

   apiVersion: flows.netobserv.io/v1beta2
   kind: FlowCollector
   metadata:
     name: cluster
   spec:
     agent:
       ebpf:
         privileged: true            1
     processor:
       advanced:
         secondaryNetworks:
         - index:                    2
           - MAC                     3
           name: my-vms/l2-network   4
   # ...

   <.> セカンダリーインターフェイスのフローが収集されるように、eBPF エージェントが privileged モードになっていることを確認します。<.> 仮想マシンのランチャー Pod のインデックスに使用するフィールドを定義します。セカンダリーインターフェイスのネットワークフローのエンリッチメントを取得するには、MAC アドレスをインデックスフィールドとして使用することを推奨します。Pod 間で MAC アドレスが重複している場合は、IP や Interface などの追加のインデックスフィールドを追加すると、正確なエンリッチメントを行うことができます。<.> 追加のネットワーク情報に MAC アドレスがある場合は、フィールドリストに MAC を追加します。<.> k8s.v1.cni.cncf.io/network-status アノテーションで見つかったネットワークの名前を指定します。Usually <namespace>/<network_attachement_definition_name>.

6. 仮想マシンのトラフィックを観測します。

   1. Network Traffic ページに移動します。
   2. k8s.v1.cni.cncf.io/network-status アノテーションで見つかった仮想マシンの IP を使用して、Source IP でフィルタリングします。
   3. エンリッチする必要がある Source フィールドと Destination フィールドの両方を表示し、仮想マシンランチャー Pod と仮想マシンインスタンスを所有者として指定します。