Network Observability（网络可观察性）

1. 例如，每个 pod。
2. 例如，每个工作负载或命名空间。
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 是否在所有项目中 Status 为 Succeeded。

流程

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。在 Provided APIs for Network Observability 下， 选择 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 以更具弹性且可扩展的方式转发数据。请参阅"Important Flow Collector 配置注意事项"部分的"使用 Kafka 存储配置流收集器资源"。
   5. 可选：在创建 FlowCollector 前配置其他可选设置。例如，如果您选择不使用 Loki，您可以将导出流配置为 Kafka 或 IPFIX。请参阅"重要流收集器配置注意事项"一节中的"导出增强的网络流数据到 Kafka 和 IPFIX"。
6. 点 Create。

流程

1. 删除 FlowCollector 自定义资源。

   1. 点 Provided APIs 列中的 Network Observability Operator 旁边的 Flow Collector。
   2. 为集群点选项菜单 ，然后选择 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 命名空间中运行的 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. 输入以下命令检查在 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 命名空间中运行的 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. 修改 OpenShift Container Platform Network Observability Operator 的 FlowCollector 资源以使用 Kafka，如下例所示：

流程

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

   您可以加密所有使用 SSL/TLS 或 mTLS 的 Kafka 的通信。启用后，Kafka CA 证书必须作为 ConfigMap 或 Secret 提供，两者都位于部署了 flowlogs-pipeline 处理器组件的命名空间中（默认为 netobserv）。它必须使用 spec.exporters.tls.caCert 引用。使用 mTLS 时，客户端 secret 还必须在这些命名空间中可用（它们也可以使用 AMQ Streams User Operator 生成并使用 spec.exporters.tls.userCert 引用）。

   5

   您可以选择指定传输。默认值为 tcp，但您也可以指定 udp。

   7

   OpenTelemetry 连接的协议。可用的选项包括 http 和 grpc。

   8

   用于导出日志的 OpenTelemetry 配置，与为 Loki 创建的日志相同。

   9

   OpenTelemetry 用于导出指标，这与为 Prometheus 创建的指标相同。这些配置在 FlowCollector 自定义资源的 spec.processor.metrics.includeList 参数中指定，以及您使用 FlowMetrics 自定义资源定义的任何自定义指标。

   10

   指标被发送到 OpenTelemetry 收集器的时间间隔。

   11

   可选:Network Observability 网络流格式自动重命名为 OpenTelemetry 兼容格式。fieldsMapping 规格可让您自定义 OpenTelemetry 格式输出。例如，在 YAML 示例中，SrcAddr 是 Network Observability 输入字段，它会在 OpenTelemetry 输出中重命名 source.address。您可以在 "Network flow format reference" 中看到 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 三次来创建三个入站规则。

5. 指定以下内容：

   1. 对第一个 Ingress 规则设置以下规格：

      1. 从 Add allowed source 下拉菜单中选择 Allow pods。

   2. 为第二个 Ingress 规则设置以下规格 ：

      1. 从 Add allowed source 下拉菜单中选择 Allow pods。
      2. 点 + Add namespace selector。
      3. 添加标签 kubernetes.io/metadata.name，以及选择器 openshift-console。

   3. 为第三个 Ingress 规则设置以下规格 ：

      1. 从 Add allowed source 下拉菜单中选择 Allow pods。
      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. 查看以下类别中的网络流量指标，每个指标都有每个节点、命名空间、源和目标的子集：

   • 字节率
   • 数据包丢弃
   • DNS
   • RTT
3. 选择 Netobserv/Health 仪表板。

4. 在以下类别中查看有关 Operator 健康的指标，每个类别都有每个节点的子集、命名空间、源和目的地。

   • 流
   • 流开销
   • 流率
   • 代理
   • 处理器
   • Operator

流程

1. 点导入图标 + 创建 YAML 文件。

2. 向 YAML 文件添加警报规则配置。在以下 YAML 示例中，当集群入口流量达到每个目标工作负载的指定阈值 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

   在 spec.processor.metrics.includeList 中默认启用 netobserv_workload_ingress_bytes_total 指标。

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 中定义的命名空间中创建，默认为 netobserv。

   2

   Prometheus 指标的名称，它们在 web 控制台中的显示带有 netobserv-<metricName> 前缀。

   3

   type 指定指标类型。Counter type 有助于计算字节和数据包。

   4

   要捕获的流方向。如果没有指定，入口和出口数据都会捕获，这可能会导致重复计数。

   5

   标签定义了指标外，以及不同实体之间的关系，同时还定义了指标基数（cardinality）。例如，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. 显示集群外部入口流量的 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 中定义的命名空间中创建，默认为 netobserv。

   2

   type 指定指标类型。Histogram type 可用于延迟值 (TimeFlowRttNs)。

   3

   由于在流中 Round-trip time (RTT) 的单位为纳秒，需要将这个值除以十亿（1 billion）转换为秒，这是 Prometheus 指南中的标准。

   4

   自定义存储桶指定 RTT 的精度，其最佳精度范围介于 5ms 和 250ms 之间。

   验证

   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. 部署以下 AlertingRule 资源以警告出现 SYN 洪水的情况：

   用于 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 标志。
2. 在 Network Traffic 表视图中，根据 TCP 协议 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. 选择 集群，然后选择 YAML 选项卡。
4. 增加 spec.agent.ebpf.cacheMaxFlows 值，如以下 YAML 示例所示：

流程

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

   spec.agent.ebpf.privileged 字段值必须设置为 true 以启用 SR-IOV 监控。

流程

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 代理处于 特权模式，以便收集流进行二级接口。<.> 定义用于索引虚拟机启动程序 Pod 的字段。建议使用 MAC 地址作为索引字段，以获取二级接口的网络流。如果您在 pod 之间有重叠的 MAC 地址，那么可将其他索引字段（如 IP 和 Interface ）添加准确功能。<.> 如果您的额外网络信息具有 MAC 地址，请将 MAC 添加到字段列表中。<.> 指定 k8s.v1.cni.cncf.io/network-status 注解中找到的网络名称。通常为 <namespace>/<network_attachement_definition_name>。

6. 观察虚拟机流量：

   1. 进入 Network Traffic 页。
   2. 使用 k8s.v1.cni.cncf.io/network-status 注解中找到的虚拟机 IP 按照 Source IP过滤。
   3. 查看 Source 和 Destination 字段（应该增强），并将 VM launcher pod 和虚拟机实例识别为所有者。