1.3. Network Observability Operator 1.4.0

以下公告可用于 Network Observability Operator 1.4.0：

RHSA-2023:5379 Network Observability Operator 1.4.0

1.3.1. 频道删除

您必须将频道从 v1.0.x 切换到 stable，以接收最新的 Operator 更新。v1.0.x 频道现已被删除。

1.3.2. 新功能及功能增强

1.3.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.3.2.2. 没有 Loki 的 Network Observability

Network Observability Operator 现在可以在没有 Loki 的情况下正常工作。如果没有安装 Loki，它只能将流导出到 KAFKA 或 IPFIX 格式，并在 Network Observability 指标仪表板中提供指标。网络如需更多信息，请参阅没有 Loki 的网络可观察性。

1.3.2.3. DNS 跟踪

在 1.4 中，Network Observability Operator 使用 eBPF 追踪点 hook 启用 DNS 跟踪。您可以监控网络，执行安全分析，并对 web 控制台中的 Network Traffic 和 Overview 页面中的 DNS 问题进行故障排除。

如需更多信息，请参阅配置 DNS 跟踪和使用 DNS 跟踪。

1.3.2.4. SR-IOV 支持

现在，您可以使用单根 I/O 虚拟化(SR-IOV)设备从集群收集流量。如需更多信息，请参阅配置 SR-IOV 接口流量的监控。

1.3.2.5. 支持 IPFIX exporter

现在，您可以将 eBPF 丰富的网络流导出到 IPFIX 收集器。如需更多信息，请参阅导出增强的网络流数据。

1.3.2.6. s390x 架构支持

Network Observability Operator 现在可在 s390x 构架中运行。以前，它在 amd64、ppc64le 或 arm64 上运行。

1.3.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.3.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