5.7. 资源管理和性能注意事项

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 负载相关联。但是，较大的值会导致内存消耗稍有更高的，并可能会在流集合中生成更多延迟。

下表概述了具有特定工作负载的集群的资源注意事项示例。

重要

表中概述的示例演示了为特定工作负载量身定制的场景。每个示例仅作为基准，可以进行调整以适应您的工作负载需求。

表 5.2. 资源建议
	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 大小	`1x.extra-small`	`1x.small`	`1x.small`	`1x.medium`
Network Observability 控制器内存限值	400Mi （默认）	400Mi （默认）	400Mi （默认）	400Mi （默认）
eBPF 抽样率	50 （默认）	50 （默认）	50 （默认）	50 （默认）
eBPF 内存限值	800Mi （默认）	800Mi （默认）	800Mi （默认）	1600Mi
FLP 内存限制	800Mi （默认）	800Mi （默认）	800Mi （默认）	800Mi （默认）
FLP Kafka 分区	N/A	48	48	48
Kafka 消费者副本	N/A	24	24	24
Kafka 代理	N/A	3 （默认）	3 （默认）	3 （默认）

使用 AWS M6i 实例测试。
除了此 worker 及其控制器外，还会测试 3 infra 节点 (size M6i.12xlarge) 和 1 个工作负载节点 (size M6i.8xlarge)。

下表包括了 3 个不同的测试（Test 1、Test 2 和 Test 3）的集群的总资源使用数据，抽样值为 1、50 和 400。这三个测试间的不同：

Test 1 考虑 OpenShift Container Platform 集群中的命名空间、Pod 和服务总数，将负载放置在 eBPF 代理中，它代表了一个具有特定集群大小的带有大量工作负载的用例。例如，Test 1 包括 76 个命名空间，5153 个 Pod 和 2305 个服务。
Test 2 考虑到具有高入口流量的环境。
Test 3 考虑 OpenShift Container Platform 集群中的命名空间、Pod 和服务总数，将负载放置在 eBPF 代理中，它代表了一个具有特定集群大小的带有比 Test 1 更大工作负载的用例。例如，Test 3 包括 553 个命名空间，6998 个 Pod 和 2508 个服务。

因为在不同的测试中的不同类型的集群用例只是一个示例，所以此表中的数字不能线性比较，它们旨在用作评估个人集群用途的基准测试。表中概述的示例演示了为特定工作负载量身定制的场景。每个示例仅作为基准，可以进行调整以适应您的工作负载需求。

注意

导出到 Prometheus 的指标可能会影响资源使用量。指标的 cardinality 值可帮助确定资源受到影响量。如需更多信息，请参阅附加资源部分中的"网络流格式"。

表 5.3. 总平均资源使用量
抽样值	参数	Test 1 (25 个节点)	Test 2 (65 个节点)	Test 3 (120 个节点)
sampling = 1	带有 Loki
	总 NetObserv CPU 用量	3.24	3.42	7.30
	总 NetObserv RSS （内存）用量	14.09 GB	22.56 GB	36.46 GB
	没有 Loki
	总 NetObserv CPU 用量	2.40	2.43	5.59
	总 NetObserv RSS （内存）用量	6.85 GB	10.39 GB	13.92 GB
Sampling = 50	带有 Loki
	总 NetObserv CPU 用量	2.04	2.36	3.31
	总 NetObserv RSS （内存）用量	8.79 GB	19.14 GB	21.07 GB
	没有 Loki
	总 NetObserv CPU 用量	1.55	1.64	2.70
	总 NetObserv RSS （内存）用量	6.71 GB	10.15 GB	14.82 GB
Sampling = 400	带有 Loki
	总 NetObserv CPU 用量	1.71	1.44	2.36
	总 NetObserv RSS （内存）用量	8.21 GB	16.02 GB	17.44 GB
	没有 Loki
	总 NetObserv CPU 用量	1.31	1.06	1.83
	总 NetObserv RSS （内存）用量	7.01 GB	10.70 GB	13.26 GB

概述：此表显示 Network Observability 的平均资源使用量 (Agents+FLP+Kafka+Loki)。

其他资源