28.5. 配置 Network Observability Operator
您可以更新 Flow Collector API 资源,以配置 Network Observability Operator 及其受管组件。流收集器在安装过程中显式创建。由于此资源在集群范围内运行,因此只允许一个 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
资源
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
- Agent 规格
spec.agent.type
必须是EBPF
。eBPF 是唯一的 OpenShift Container Platform 支持的选项。 - 2
- 您可以设置 Sampling 规格
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
命名空间的所有流量。如需更多信息,请参阅配置快速过滤器。
其他资源
有关对话跟踪的更多信息,请参阅使用对话。
28.5.2. 使用 Kafka 配置流收集器资源
您可以将 FlowCollector
资源配置为使用 Kafka。需要运行一个 Kafka 实例,并在该实例中创建专用于 OpenShift Container Platform Network Observability 的 Kafka 主题。如需更多信息,请参阅您的 Kafka 文档,如 AMQ Streams 的 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
- 将
spec.deploymentModel
设置为KAFKA
而不是DIRECT
来启用 Kafka 部署模型。 - 2
spec.kafka.address
是指 Kafka bootstrap 服务器地址。如果需要,您可以指定一个端口,如kafka-cluster-kafka-bootstrap.netobserv:9093
,以便在端口 9093 上使用 TLS。- 3
spec.kafka.topic
应与 Kafka 中创建的主题名称匹配。- 4
spec.kafka.tls
可用于加密所有与带有 TLS 或 mTLS 的 Kafka 的通信。启用后,Kafka CA 证书必须作为 ConfigMap 或 Secret 提供,两者都位于部署了flowlogs-pipeline
处理器组件的命名空间中(默认为netobserv
)以及 eBPF 代理被部署的位置(默认为netobserv-privileged
)。它必须通过spec.kafka.tls.caCert
引用。使用 mTLS 时,客户端 secret 还必须在这些命名空间中可用(它们也可以使用 AMQ Streams User Operator 生成并使用spec.kafka.tls.userCert
)。
28.5.3. 导出增强的网络流数据
您可以将网络流发送到 Kafka,以便它们可以被支持 Kafka 输入的任何处理器或存储使用,如 Splunk、Elasticsearch 或 Fluentd。
先决条件
- 安装的 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
- 您可以加密所有使用 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
引用)。
- 配置后,网络流数据可以以 JSON 格式发送到可用输出。如需更多信息,请参阅 网络流格式参考
其他资源
有关指定流格式的更多信息,请参阅网络流格式参考。
28.5.4. 更新流收集器资源
作为在 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"或"any of"的过滤器是用户可从查询选项进行修改的 UI 设置。它不是此资源配置的一部分。
以下是所有可用过滤器键的列表:
Universal* | 源 | 目的地 | 描述 |
---|---|---|---|
namespace |
|
| 过滤与特定命名空间相关的流量。 |
name |
|
| 过滤与给定叶资源名称相关的流量,如特定 pod、服务或节点(用于 host-network 流量)。 |
kind |
|
| 过滤与给定资源类型相关的流量。资源类型包括叶资源 (Pod、Service 或 Node) 或所有者资源(Deployment 和 StatefulSet)。 |
owner_name |
|
| 过滤与给定资源所有者相关的流量;即工作负载或一组 pod。例如,它可以是 Deployment 名称、StatefulSet 名称等。 |
resource |
|
|
过滤与特定资源相关的流量,它们通过其规范名称表示,以唯一标识它。规范表示法是 |
address |
|
| 过滤与 IP 地址相关的流量。支持 IPv4 和 IPv6。还支持 CIDR 范围。 |
mac |
|
| 过滤与 MAC 地址相关的流量。 |
端口 |
|
| 过滤与特定端口相关的流量。 |
host_address |
|
| 过滤与运行 pod 的主机 IP 地址相关的流量。 |
protocol | 不适用 | 不适用 | 过滤与协议相关的流量,如 TCP 或 UDP。 |
-
任何源或目的地的通用密钥过滤器。例如,过滤
name: 'my-pod'
表示从my-pod
和所有流量到my-pod
的所有流量,无论使用的匹配类型是什么,无论是 匹配所有 还是 匹配任何。
28.5.6. 资源管理和性能注意事项
Network Observability 所需的资源量取决于集群的大小以及集群要存储可观察数据的要求。要管理集群的资源并设置性能标准,请考虑配置以下设置。配置这些设置可能会满足您的最佳设置和可观察性需求。
以下设置可帮助您管理 outset 中的资源和性能:
- eBPF Sampling
-
您可以设置 Sampling 规格
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. 资源注意事项
下表概述了具有特定工作负载的集群的资源注意事项示例。
表中概述的示例演示了为特定工作负载量身定制的场景。每个示例仅作为基准,可以进行调整以适应您的工作负载需求。
Extra small (10 个节点) | Small (25 个节点) | Medium (65 个节点) [2] | Large (120 个节点) [2] | |
---|---|---|---|---|
Worker 节点 vCPU 和内存 | 4 个 vCPU| 16GiB 内存 [1] | 16 个 vCPU| 64GiB 内存 [1] | 16 个 vCPU| 64GiB 内存 [1] | 16 个 vCPU| 64GiB Mem [1] |
LokiStack 大小 |
|
|
|
|
Network Observability 控制器内存限值 | 400Mi (默认) | 400Mi (默认) | 400Mi (默认) | 800Mi |
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 实例测试。
-
除了此 worker 及其控制器外,还会测试 3 infra 节点 (size
M6i.12xlarge
) 和 1 个工作负载节点 (sizeM6i.8xlarge
)。