6.7. 资源管理和性能注意事项
Network Observability 所需的资源量取决于集群的大小以及集群要存储可观察数据的要求。要管理集群的资源并设置性能标准,请考虑配置以下设置。配置这些设置可能会满足您的最佳设置和可观察性需求。
以下设置可帮助您管理 outset 中的资源和性能:
- eBPF Sampling
-
您可以设置 Sampling 规格
spec.agent.ebpf.sampling
,以管理资源。较小的抽样值可能会消耗大量计算、内存和存储资源。您可以通过指定一个抽样比率值来缓解这个问题。100
表示每 100 个流进行 1 个抽样。值0
或1
表示捕获所有流。较小的值会导致返回的流和派生指标的准确性增加。默认情况下,eBPF 抽样设置为 50,因此每 50 个流抽样 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.cacheMaxFlows
andspec.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网络流量"中涵盖的功能,其中包括为此测试启用的所有功能。