红帽全球峰会6.7. 资源管理和性能注意事项
Network Observability 所需的资源量取决于集群的大小以及集群要存储可观察数据的要求。要管理集群的资源并设置性能标准，请考虑配置以下设置。配置这些设置可能会满足您的最佳设置和可观察性需求。
以下设置可帮助您管理 outset 中的资源和性能：
- eBPF Sampling
-
您可以设置 Sampling 规格
spec.agent.ebpf.sampling，以管理资源。默认情况下，eBPF 抽样设置为50，因此流抽样为 50 个几率。较低的抽样间隔值需要更多计算、内存和存储资源。值0或1表示所有流都是抽样的。建议您以默认值开始，并将其优化为决定集群的最佳设置。 - eBPF 功能
- 启用更多功能，CPU 和内存受到影响。如需这些功能的完整列表，请参阅"保留网络流量"。
- 没有 Loki
- 您可以减少 Network Observability 所需资源量，而不是使用 Loki，而依赖于 Prometheus。例如，当在没有 Loki 的情况下配置 Network Observability 时，内存用量的总节省在 20-65% 范围内，CPU 使用率低于 10-30%，具体取决于抽样间隔值。如需更多信息，请参阅 "Network Observability without Loki"。
- 限制或排除接口
-
通过为
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.cacheMaxFlowsandspec.agent.ebpf.cacheActiveTimeout规格的代理报告网络流量的频率。较大的值会导致代理生成较少的流量，与较低 CPU 负载相关联。但是，较大的值会导致内存消耗稍有更高的，并可能会在流集合中生成更多延迟。
-
资源要求和限制：使用
6.7.1. 资源注意事项
下表概述了具有特定工作负载的集群的资源注意事项示例。
表中概述的示例演示了为特定工作负载量身定制的场景。每个示例仅作为基准，可以进行调整以适应您的工作负载需求。
| Extra small (10 个节点) | Small (25 个节点) | Large (250 个节点 )[2] | |
|---|---|---|---|
| Worker 节点 vCPU 和内存 | 4 个 vCPU| 16GiB 内存 [1] | 16 个 vCPU| 64GiB 内存 [1] | 16 个 vCPU| 64GiB Mem [1] |
| LokiStack 大小 |
|
|
|
| Network Observability 控制器内存限值 | 400Mi （默认） | 400Mi （默认） | 400Mi （默认） |
| eBPF 抽样间隔 | 50 （默认） | 50 （默认） | 50 （默认） |
| eBPF 内存限值 | 800Mi （默认） | 800Mi （默认） | 1600Mi |
| cacheMaxSize | 50,000 | 100,000 （默认） | 100,000 （默认） |
| FLP 内存限制 | 800Mi （默认） | 800Mi （默认） | 800Mi （默认） |
| FLP Kafka 分区 | – | 48 | 48 |
| Kafka 消费者副本 | – | 6 | 18 |
| Kafka 代理 | – | 3 （默认） | 3 （默认） |
- 使用 AWS M6i 实例测试。
-
除了此 worker 及其控制器外，还会测试 3 infra 节点 (size
M6i.12xlarge) 和 1 个工作负载节点 (sizeM6i.8xlarge)。
6.7.2. 总内存和 CPU 用量
下表概述了在两个不同的测试中抽样值为 1 和 50 的集群的总资源使用量： Test 1 和 Test 2。这三个测试间的不同：
-
除了 OpenShift Container Platform 集群中的命名空间、Pod 和服务总数外，
Test 1还考虑高入口流量卷，将负载放置在 eBPF 代理上，并代表给定集群大小有大量工作负载的用例。例如，Test 1由 76 个命名空间、5153 个 Pod 和 2305 服务组成，网络流量大小为 ~350 MB/s。 -
除了 OpenShift Container Platform 集群中的命名空间总数、Pod 和服务总数外，
Test 2还考虑高入口流量卷，并代表具有给定集群大小大量工作负载的用例。例如，Test 2包括 553 命名空间、6998 个 Pod 和 2508 服务，网络流量扩展为 ~950 MB/s。
因为在不同的测试中使用了不同类型的集群，因此在一对一比较时，此表中的数字并不会线性扩展。相反，它们旨在用于评估个人集群使用情况的基准。表中概述的示例演示了为特定工作负载量身定制的场景。每个示例仅作为基准，可以进行调整以适应您的工作负载需求。
导出到 Prometheus 的指标可能会影响资源使用量。指标的 cardinality 值可帮助确定资源受到影响量。如需更多信息，请参阅附加资源部分中的"网络流格式"。
| 抽样值 | 使用的资源 | Test 1 (25 个节点) | Test 2 (250 个节点) |
|---|---|---|---|
| Sampling = 50 | 总 NetObserv CPU 用量 | 1.35 | 5.39 |
| 总 NetObserv RSS （内存）用量 | 16 GB | 63 GB | |
| sampling = 1 | 总 NetObserv CPU 用量 | 1.82 | 11.99 |
| 总 NetObserv RSS （内存）用量 | 22 GB | 87 GB |
Summary：此表显示 Network Observability 的平均资源使用量，其中包括启用了所有功能的 Agents、FLP、Kafka 和 Loki。有关启用功能的详情，请查看"Observing网络流量"中涵盖的功能，其中包括为此测试启用的所有功能。
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}