1.6. Network Observability Operator 1.4.0
以下公告可用于 Network Observability Operator 1.4.0:
1.6.1. 频道删除
您必须将频道从 v1.0.x
切换到 stable
,以接收最新的 Operator 更新。v1.0.x
频道现已被删除。
1.6.2. 新功能及功能增强
1.6.2.1. 主要改进
Network Observability Operator 的 1.4 发行版本为 OpenShift Container Platform Web 控制台插件和 Operator 配置添加了改进和新功能。
Web 控制台增强:
- 在 Query Options 中,添加了 Duplicate 流 复选框,以选择要显示重复流。
- 现在您可以使用 One-way, Back-and-forth, 和 Swap 过滤器过滤源和目标流。
Observe
Dashboards NetObserv 和 NetObserv / Health 中的 Network Observability 指标仪表板被修改,如下所示: - NetObserv 仪表板显示顶级字节、数据包发送、每个节点、命名空间和工作负载接收的数据包。流图从此仪表板中删除。
- NetObserv / Health 仪表板显示流开销,以及每个节点的流率、命名空间和工作负载。
- 基础架构和应用程序指标显示在命名空间和工作负载的 split-view 中。
如需更多信息,请参阅 Network Observability 指标和快速过滤器。
配置增强:
- 现在,您可以选择为任何配置的 ConfigMap 或 Secret 引用指定不同的命名空间,如证书配置中。
-
添加
spec.processor.clusterName
参数,以便集群名称出现在流数据中。这在多集群上下文中很有用。使用 OpenShift Container Platform 时,留空,使其自动决定。
如需更多信息,请参阅 流收集器示例资源和流收集器 API 参考。
1.6.2.2. 没有 Loki 的 Network Observability
Network Observability Operator 现在可以在没有 Loki 的情况下正常工作。如果没有安装 Loki,它只能将流导出到 KAFKA 或 IPFIX 格式,并在 Network Observability 指标仪表板中提供指标。如需更多信息,请参阅没有 Loki 的网络可观察性。
1.6.2.3. DNS 跟踪
在 1.4 中,Network Observability Operator 使用 eBPF 追踪点 hook 启用 DNS 跟踪。您可以监控网络,执行安全分析,并对 web 控制台中的 Network Traffic 和 Overview 页面中的 DNS 问题进行故障排除。
1.6.2.4. SR-IOV 支持
现在,您可以使用单根 I/O 虚拟化(SR-IOV)设备从集群收集流量。如需更多信息,请参阅配置 SR-IOV 接口流量的监控。
1.6.2.5. 支持 IPFIX exporter
现在,您可以将 eBPF 丰富的网络流导出到 IPFIX 收集器。如需更多信息,请参阅导出增强的网络流数据。
1.6.2.6. 数据包丢弃
在 Network Observability Operator 的 1.4 发行版本中,eBPF 追踪点 hook 用于启用数据包丢弃跟踪。现在,您可以检测和分析数据包丢弃的原因,并做出决策来优化网络性能。在 OpenShift Container Platform 4.14 及更高版本中,会检测主机丢弃和 OVS 丢弃。在 OpenShift Container Platform 4.13 中,只检测主机丢弃。如需更多信息,请参阅配置数据包丢弃跟踪和使用数据包丢弃。
1.6.2.7. s390x 架构支持
Network Observability Operator 现在可在 s390x
构架中运行。以前,它在 amd64
、ppc64le
或 arm64
上运行。
1.6.3. 程序错误修复
-
在以前的版本中,被 Network Observability 导出的 Prometheus 指标会忽略潜在的重复网络流。在相关的仪表板中,在 Observe
Dashboards 中,这可能会导致潜在的双倍率。请注意,来自 Network Traffic 视图中的仪表板不会受到影响。现在,会过滤网络流以消除指标计算前的重复项,仪表板中会显示正确的流量率。(NETOBSERV-1131) -
在以前的版本中,当使用 Multus 或 SR-IOV (非默认网络命名空间)配置时,Network Observability Operator 代理无法捕获网络接口上的流量。现在,所有可用的网络命名空间都会被识别并用于捕获 SR-IOV 的流量。
FlowCollector
和SRIOVnetwork
自定义资源收集流量需要的配置。(NETOBSERV-1283) -
在以前的版本中,在 Operators
Installed Operators 的 Network Observability Operator 详情中, FlowCollector
Status 字段可能会报告有关部署状态的错误信息。现在,status 字段会显示正确的信息。保持的事件历史记录,按事件日期排序。(NETOBSERV-1224) -
在以前的版本中,在网络流量负载激增时,某些 eBPF pod 被 OOM 终止,并进入
CrashLoopBackOff
状态。现在,eBPF
代理内存占用率有所改进,因此 pod 不会被 OOM 终止,并进入CrashLoopBackOff
状态。(NETOBSERV-975) -
在以前的版本中,当
processor.metrics.tls
设置为PROVIDED
时,insecureSkipVerify
选项值被强制为true
。现在,您可以将insecureSkipVerify
设置为true
或false
,并在需要时提供 CA 证书。(NETOBSERV-1087)
1.6.4. 已知问题
-
由于 Network Observability Operator 的 1.2.0 发行版本使用 Loki Operator 5.6,Loki 证书更改会定期影响
flowlogs-pipeline
pod,并导致丢弃流而不是写入 Loki 的流。一段时间后,问题会自行修正,但它仍然会在 Loki 证书更改过程中导致临时流数据丢失。此问题仅在有 120 个节点或更多节点的大型环境中观察到。(NETOBSERV-980) -
目前,当
spec.agent.ebpf.features
包括 DNSTracking 时,更大的 DNS 数据包需要eBPF
代理在第一套接字缓冲区(SKB)网段外查找 DNS 标头。需要实施新的eBPF
代理帮助程序功能来支持它。目前,这个问题还没有临时解决方案。(NETOBSERV-1304) -
目前,当
spec.agent.ebpf.features
包括 DNSTracking 时,通过 TCP 数据包的 DNS 需要eBPF
代理在 1st SKB 段外查找 DNS 标头。需要实施新的eBPF
代理帮助程序功能来支持它。目前,这个问题还没有临时解决方案。(NETOBSERV-1245) -
目前,在使用
KAFKA
部署模型时,如果配置了对话跟踪,则对话事件可能会在 Kafka 用户间重复,导致跟踪对话不一致和不正确的 volumetric 数据。因此,不建议在deploymentModel
设置为KAFKA
时配置对话跟踪。(NETOBSERV-926) -
目前,当
processor.metrics.server.tls.type
配置为使用PROVIDED
证书时,Operator 会进入一个没有就绪的状态,该状态可能会影响其性能和资源消耗。在解决此问题解决前,建议不要使用PROVIDED
证书,而是使用自动生成的证书,将processor.metrics.server.tls.type
设置为AUTO
。(NETOBSERV-1293 -
由于 Network Observability Operator 的 1.3.0 发行版本,安装 Operator 会导致出现警告内核污点。此错误的原因是,Network Observability eBPF 代理具有内存限制,可防止预分配整个 hashmap 表。Operator eBPF 代理设置
BPF_F_NO_PREALLOC
标志,以便在 hashmap 过内存扩展时禁用预分配。