Network Observability（网络可观察性）

• RHEA-2025:22761 Network Observability Operator 1.10.1

• CVE-2025-47907

• RHEA-2025:19153 Network Observability Operator 1.10

• RHEA-2025:15780 Network Observability Operator 1.9.3

• RHEA-2025:14150 Network Observability Operator 1.9.2

• 在此次更新之前，OpenShift Container Platform 版本 4.15 及更早版本不支持 TC_ATACH_MODE 配置。这会导致命令行界面(CLI)错误，并阻止对数据包和流的观察。在这个版本中，对这些旧版本调整了流量控制 eXtension (TCX) hook 附加模式。这消除了 tcx hook 错误，并启用流和数据包观察。

• 2025:12024 network Observability Operator 1.9.1

• 在此次更新之前，因为一个不正确的附加模式设置，在 OpenShift Container Platform 4.15 中不会观察到网络流。这使用户无法正确监控网络流，特别是某些目录。在这个版本中，早于 4.16.0 的 OpenShift Container Platform 版本的默认附加模式被设置为 tc，因此流现在可以在 OpenShift Container Platform 4.15 上观察到。(NETOBSERV-2333)
• 在此次更新之前，如果 IPFIX 收集器重启，配置 IPFIX exporter 可能会丢失其连接，并停止将网络流发送到收集器。在这个版本中，连接被恢复，网络流将可以继续发送到收集器。(NETOBSERV-2315)
• 在此次更新之前，当您配置 IPFIX 导出器时，没有端口信息的流会被忽略（如 ICMP 流量），这会导致日志出现错误。IPFIX 导出中也缺少了 TCP 标志和 ICMP 数据。在这个版本中，包括了这些详情。缺少字段（如端口）不再会导致错误，并且是导出的数据的一部分。(NETOBSERV-2307)
• 在此次更新之前，User Defined Networks (UDN) Mapping 功能在 OpenShift Container Platform 4.18 上显示一个配置问题和警告，因为 OpenShift 版本在代码中被错误地设置。这会影响用户体验。在这个版本中，UDN 映射支持可以正确支持 OpenShift Container Platform 4.18 而不会出现警报，从而用户可以获得更好的体验。(NETOBSERV-2305)
• 在此次更新之前，Network Traffic 页中的扩展功能与 OpenShift Container Platform Console 4.19 存在兼容性问题。这会导致在扩展以及不一致的用户界面时出现空菜单。在这个版本中，NetflowTraffic 部分和 theme hook 的问题已被解决。Network Traffic 视图中的侧边菜单现在可以被正确管理，这提高了用户与用户界面进行交互的体验。(NETOBSERV-2304)

• Network Observability Operator 1.9

• 网络 observability 1.9 中的 NetworkEvents 功能已更新，以便与 OpenShift Container Platform 4.19 的更新 Linux 内核。这个版本会破坏与旧内核的兼容性。因此，NetworkEvents 功能只能用于 OpenShift Container Platform 4.19。如果您在网络 observability 1.8 和 OpenShift Container Platform 4.18 中使用此功能，请考虑避免网络可观察性升级或升级到网络 observability 1.9，OpenShift Container Platform 升级到 4.19。
• netobserv-reader 集群角色已重命名为 netobserv-loki-reader。
• 改进了 eBPF 代理的 CPU 性能。

• CVE-2025-26791

• 在以前的版本中，当根据控制台插件的源或目标 IP 过滤时，使用无类别域间路由(CIDR)标记（如 10.128.0.0/24 ）无法正常工作，返回应该过滤掉的结果。在这个版本中，可以使用 CIDR 表示法，结果会如预期过滤。(NETOBSERV-2276)
• 在以前的版本中，网络流可能会错误地识别正在使用的网络接口，特别是混合使用 eth0 和 ens5 的风险。只有在 eBPF 代理配置为 Privileged 时，才会出现这个问题。在这个版本中，它已被部分修复，几乎所有网络接口都会被正确识别。详情请参考以下已知问题。(NETOBSERV-2257)
• 在以前的版本中，当 Operator 检查可用的 Kubernetes API 以适应其行为时，如果出现过时的 API，这会导致阻止 Operator 正常启动的错误。在这个版本中，Operator 忽略了不相关的 API 的错误，在相关 API 中记录错误，并继续运行。(NETOBSERV-2240)
• 在以前的版本中，用户无法在 Console 插件的流量 视图中根据 Bytes 或 Packets 对流进行排序。在这个版本中，用户可以按 Bytes 和 Packets 对流进行排序。(NETOBSERV-2239)
• 在以前的版本中，当使用 IPFIX 导出器配置 FlowCollector 资源时，IPFIX 流中的 MAC 地址会截断为其 2 个字节。在这个版本中，MAC 地址在 IPFIX 流中完全表示。(NETOBSERV-2208)
• 在以前的版本中，从 Operator 验证 Webhook 发送的一些警告可能会缺少所需操作所需的清晰性。在这个版本中，其中一些消息已被检查并修改，以使它们更可操作。(NETOBSERV-2178)
• 在以前的版本中，从 FlowCollector 资源中引用 LokiStack 时并不知道问题，比如在输入错误时。在这个版本中，FlowCollector 状态会明确指出引用的 LokiStack 在那个情形中未找到。(NETOBSERV-2174)
• 在以前的版本中，在控制台插件流量流视图中，在文本溢出时，文本省略有时会隐藏要显示的许多文本。在这个版本中，它会尽可能显示文本。(NETOBSERV-2119)
• 在以前的版本中，网络 observability 1.8.1 及更早版本的控制台插件无法用于 OpenShift Container Platform 4.19 web 控制台，从而使 Network Traffic 页面无法访问。在这个版本中，控制台插件兼容，在网络 observability 1.9.0 中可以访问 Network Traffic 页面。(NETOBSERV-2046)
• 在以前的版本中，当使用对话跟踪(在 FlowCollector 资源中使用 logTypes: Conversations 或 logTypes: All)时，仪表板中出现的流量速率指标有缺陷，它会错误地显示以无法控制的流量。现在，指标显示更准确的流量率。但请注意，在 Conversations 和 EndedConversations 模式中，这些指标仍不是完全准确的，因为它们不包括长期的连接。此信息已添加到文档中。建议使用默认模式 logTypes: Flows 来避免这些不准确。(NETOBSERV-1955)

• 用户定义的网络(UDN)功能在与 OpenShift Container Platform 4.18 一起使用时会显示一个配置问题和一个警告，即使它被支持。这个警告可以被忽略。(NETOBSERV-2305)
• 在某些情况下，在带有几个网络命名空间的特权 模式下运行时，eBPF 代理无法正确将流与涉及的接口关联。本发行版本中已经识别并解决了这些问题的较大部分，但仍存在一些不一致的情况，特别是 ens5 接口。(NETOBSERV-2287)

• CVE-2024-56171
• CVE-2025-24928

• 在这个版本中，Observe 菜单会在以后的 OpenShift Container Platform 版本中出现一次。(NETOBSERV-2139)

• Network Observability Operator 1.8.0

• 在以前的版本中，Network Observability Operator 附带一个 "kube-rbac-proxy" 容器来管理其指标服务器的 RBAC。由于此外部组件已弃用，因此需要将其删除。现在，它通过 Kubernetes controller-runtime 替换为直接 TLS 和 RBAC 管理，而无需 side-car 代理。(NETOBSERV-1999)
• 在以前的版本中，在 OpenShift Container Platform 控制台插件中，对不等于多个值的键进行过滤不会过滤任何内容。在这个版本中，可以返回预期的结果 - 没有过滤值的流。(NETOBSERV-1990)
• 在以前的版本中，在禁用了 Loki 的 OpenShift Container Platform 控制台插件中，由于选择不兼容的过滤器和聚合集合，这会产生一个 "Can't build query" 错误。现在，通过自动禁用不兼容的过滤器来避免这个错误，同时使用户了解过滤不兼容。(NETOBSERV-1977)
• 在以前的版本中，当从控制台插件查看流详情时，ICMP 信息总是显示在侧面面板中，并对非 ICMP 流显示 "undefined" 值。在这个版本中，非 ICMP 流不会显示 ICMP 信息。(NETOBSERV-1969)
• 在以前的版本中，流量流视图 中的 "Export data" 链接无法按预期工作，生成空 CSV 报告。现在，导出功能会被恢复，生成非空 CSV 数据。(NETOBSERV-1958)
• 在以前的版本中，可以配置 FlowCollector 带有 processor.logTypes Conversations, EndedConversations 或 All，loki.enable 被设置为 false，尽管对话日志仅在启用 Loki 时才有用。这会导致资源使用量被浪费。现在，此配置无效，由验证 Webhook 拒绝。(NETOBSERV-1957)
• 使用将 processor.logTypes 设置为 All 的 FlowCollector 配置消耗更多资源，如 CPU、内存和网络带宽，而不是其他选项。之前没有记录此内容。现在，它已被记录，并从验证 Webhook 触发警告。(NETOBSERV-1956)
• 在以前的版本中，在高压力下，eBPF 代理生成的一些流被错误地忽略，从而导致流量带宽较低。现在，这些生成的流不会被忽略。(NETOBSERV-1954)
• 在以前的版本中，当在 FlowCollector 配置中启用网络策略时，到 Operator Webhook 的流量会被阻断，破坏 FlowMetrics API 验证。现在，允许 Webhook 流量。(NETOBSERV-1934)
• 在以前的版本中，当部署默认网络策略时，在 additionalNamespaces 字段中默认设置命名空间 openshift-console 和 openshift-monitoring，从而导致重复的规则。现在，没有默认设置额外的命名空间，这有助于避免获取重复的规则。(NETOBSERV-1933)
• 以前，在 OpenShift Container Platform 控制台插件中，对 TCP 标记进行过滤会匹配只有准确所需标记的流。现在，任何至少具有所需标志的流都会在过滤流中出现。(NETOBSERV-1890)
• 当 eBPF 代理以特权模式运行且 pod 持续添加或删除时，会发生文件描述符(FD)泄漏。此修复可确保删除网络命名空间时 FD 的正确冲突。( NETOBSERV-2063)
• 在以前的版本中，CLI 代理 DaemonSet 不会在 master 节点上部署。现在，在代理 DaemonSet 上添加了一个容限，以便在设置污点时在每个节点上调度。现在，CLI 代理 DaemonSet pod 在所有节点上运行。(NETOBSERV-2030)
• 在以前的版本中，当只使用 Prometheus 存储时，Source Resource 和 Source Destination 过滤自动完成功能无法正常工作。现在这个问题已被解决，建议会如预期显示。(NETOBSERV-1885)
• 在以前的版本中，Topology 视图中会单独显示使用多个 IP 的资源。现在，资源在视图中显示为单个拓扑节点。(NETOBSERV-1818)
• 在以前的版本中，当鼠标指针悬停在列上时，控制台会刷新 Network traffic 表查看内容。现在，显示已被修复，因此行的高度会与鼠标指针一起保持恒定。(NETOBSERV-2049)

• 如果集群中有流量使用重叠的子网，则 eBPF 代理会有一些小的风险，从重叠的 IP 混合了流。如果不同的连接发生于具有相同源和目标 IP，并且端口和协议位于 5 秒时间内并在同一节点上发生，则会出现这种情况。除非配置了二级网络或 UDN，否则不应该执行此操作。即使在这种情况下，在正常的网络流量中仍然不太可能发生，因为源端口通常是一个很好的区分器。(NETOBSERV-2115)
• 在 OpenShift Container Platform Web 控制台表单视图中选择要在 FlowCollector 资源 spec.exporters 部分中配置的导出类型后，该类型的详细配置不会以表单显示。解决办法是直接配置 YAML。(NETOBSERV-1981)

• Network Observability Operator 1.7.0

• 在以前的版本中，当使用 RHEL 9.2 实时内核时，一些 Webhook 无法正常工作。现在，提供了一个修复程序，用于检查是否使用了这个 RHEL 9.2 实时内核。如果使用内核，则会显示有关无法正常工作的功能的警告，如数据包丢弃，以及使用 s390x 架构时的 Round-trip Time。相关的修复包括在 OpenShift 4.16 及更高版本中。(NETOBSERV-1808)
• 在以前的版本中，在 Overview 选项卡中的 Manage 面板 对话框中，根据 total, bar, donut, or line 过滤不会显示结果。现在，可以正确地过滤可用的面板。(NETOBSERV-1540)
• 在以前的版本中，在高力下，eBPF 代理容易进入一个会生成大量小的流而几乎不聚合它们的状态。在这个版本中，在高压的情况下聚合过程仍然可以进行，因此会创建较少的流。在这个版本中，改进了在 eBPF 代理中，以及 flowlogs-pipeline 和 Loki 中的资源消耗。(NETOBSERV-1564)
• 在以前的版本中，当启用了 workload_flows_total 指标而不是 namespace_flows_total 指标时，健康仪表板会停止显示 By namespace 流图表。在这个版本中，当启用了 workload_flows_total 时，健康仪表板会显示流图表。(NETOBSERV-1746)
• 在以前的版本中，当您使用 FlowMetrics API 生成自定义指标并稍后修改其标签时，指标会停止填充，并在 flowlogs-pipeline 日志中显示错误。在这个版本中，您可以修改标签，在 flowlogs-pipeline 日志中不再引发错误。(NETOBSERV-1748)
• 在以前的版本中，默认的 Loki WriteBatchSize 配置不一致：在 FlowCollector CRD 中被设置为 100 KB，在 OLM 示例或默认配置中被设置为 10 MB。现在，它们都一致地设置为 10，这通常会提供更好的性能并减少资源占用量。(NETOBSERV-1766)
• 在以前的版本中，如果您没有指定协议，则端口上的 eBPF 流过滤器会被忽略。在这个版本中，您可以独立于端口和或协议设置 eBPF 流过滤器。(NETOBSERV-1779)
• 在以前的版本中，Topology 视图中隐藏了从 Pod 到服务的流量。只有从 Services 到 Pod 的返回流量才可见。在这个版本中，流量会被正确显示。(NETOBSERV-1788)
• 在以前的版本中，当具有 Network Observability 访问权限的非集群管理员用户试图过滤触发自动完成的内容（如命名空间）时，控制台插件中的错误会在控制台插件中看到一个错误。在这个版本中，不会显示错误，自动完成会返回预期的结果。( NETOBSERV-1798)
• 当添加二级接口支持时，您必须多次使用 netlink 注册每个网络命名空间，以了解接口通知。同时，因为使用 TCX hook，不成功的处理程序会导致泄漏文件描述符。这与 TC 不同，在接口停止时需要显式删除处理程序。另外，当删除网络命名空间时，没有 Go 关闭频道事件来终止 netlink goroutine 套接字，这会导致 go 线程泄漏。现在，在创建和删除 pod 时，不会再泄漏文件描述符或 go 线程。(NETOBSERV-1805)
• 在以前的版本中，即使流 JSON 中相关的数据可用，ICMP 类型和值在流量流表中显示 'n/a'。在这个版本中，ICMP 列在流表中按预期显示相关值。(NETOBSERV-1806)
• 在以前的版本中，在控制台插件中，无法为未设置的字段过滤，如取消设置 DNS 延迟。在这个版本中，可以对未设置的字段进行过滤。(NETOBSERV-1816)
• 在以前的版本中，当您在 OpenShift Web 控制台插件中清除过滤器时，有时会在进入另一个页面后重新应用过滤器，并返回带有过滤器的页面。在这个版本中，过滤器在清除后不会意外地重新显示它们。(NETOBSERV-1733)

• 当您将 must-gather 工具与网络可观察性搭配使用时，当集群启用了 FIPS 时，不会收集日志。(NETOBSERV-1830)

• 当在 FlowCollector 中启用 spec.networkPolicy 时，它会在 netobserv 命名空间中安装网络策略，无法使用 FlowMetrics API。网络策略块调用验证 Webhook。作为临时解决方案，请使用以下网络策略：

  kind: NetworkPolicy
  apiVersion: networking.k8s.io/v1
  metadata:
    name: allow-from-hostnetwork
    namespace: netobserv
  spec:
    podSelector:
      matchLabels:
        app: netobserv-operator
    ingress:
      - from:
          - namespaceSelector:
              matchLabels:
                policy-group.network.openshift.io/host-network: ''
    policyTypes:
      - Ingress

  (NETOBSERV-193)

• 2024:7074 Network Observability Operator 1.6.2

• CVE-2024-24791

• 当添加了二级接口支持时，需要多次使用 netlink 注册每个网络命名空间，以了解接口通知。同时，因为使用 TCX hook，不成功的处理程序会导致泄漏文件描述符。这与 TC 不同，在接口停止时需要显式删除处理程序。现在，创建和删除 pod 时不再泄漏文件描述符。(NETOBSERV-1805)

• 与控制台插件存在兼容性问题，它们会阻止在 OpenShift Container Platform 集群以后的版本上安装网络可观察性。通过升级到 1.6.2，兼容性问题已解决，网络可观察性可以如预期安装。(NETOBSERV-1737)

• 2024:4785 Network Observability Operator 1.6.1

• RHSA-2024:4237
• RHSA-2024:4212

• 在以前的版本中，关于数据包丢弃的信息（如原因和 TCP 状态）仅在 Loki 数据存储中提供，而不是在 Prometheus 中提供。因此，OpenShift Web 控制台插件 Overview 中的丢弃统计信息仅适用于 Loki。在这个版本中，有关数据包丢弃的信息也添加到指标中，因此您可以在禁用 Loki 时查看丢弃统计信息。(NETOBSERV-1649)
• 当 eBPF 代理 PacketDrop 功能被启用，并抽样被配置为一个大于 1 的值时，报告的丢弃的字节并丢弃数据包会忽略抽样配置。虽然这样做的目的为了不遗漏任何数据丢弃，但这样做的一个副作用是报告的丢弃数据与非丢弃数据的比例变得有倾向性。例如，对于一个非常高的抽样率（如 1:1000）中，在控制台插件中观察到的情况是，几乎所有流量都被丢弃。在这个版本中，抽样配置会正确处理丢弃的字节和数据包。(NETOBSERV-1676)
• 在以前的版本中，如果首先创建了接口，然后才部署 eBPF 代理，则不会检测到这个 SR-IOV 二级接口。只有在先部署了代理，然后再创建 SR-IOV 接口时，才会检测到它。在这个版本中，无论部署序列是什么，都会检测到 SR-IOV 二级接口。(NETOBSERV-1697)
• 在以前的版本中，当禁用 Loki 时，OpenShift Web 控制台中的 Topology 视图始终会在网络拓扑图旁边的滑块中显示集群和 区域聚合选项，即使未启用相关的功能。在这个版本中，滑块只根据启用的功能显示选项。(NETOBSERV-1705)
• 在以前的版本中，当 Loki 被禁用时，OpenShift Web 控制台第一次加载时，可能会显示错误：Request failed with status code 400 Loki is disabled。在这个版本中，不再会出现错误。(NETOBSERV-1706)
• 在以前的版本中，在 OpenShift Web 控制台的 Topology 视图中，当点击任何图形节点旁边的 Step into 图标时，过滤器不会根据需要应用，从而将重点设置为所选图形节点，从而导致在 OpenShift Web 控制台中显示 Topology 视图的广泛视图。在这个版本中，正确设置了过滤，有效缩小 Topology 的范围。作为此更改的一部分，点节点上的 Step into 图标进入 Resource 范围而不是 Namespaces 范围。(NETOBSERV-1720)
• 在以前的版本中，当 Loki 被禁用时，在 OpenShift Web 控制台的 Topology 视图中，将 Scope 设置为 Owner，点任何图形节点旁的 Step into 图标会使 Scope 变为 Resource，在没有 Loki 的情况下不可用，因此会显示错误消息。在这个版本中，当 Loki 被禁用时，在 Owner 范围中会隐藏 Step into 图标，因此不再会发生此场景。(NETOBSERV-1721)
• 在以前的版本中，当禁用 Loki 时，当设置了一个组时，OpenShift Web 控制台的 Topology 视图中会显示一个错误，但会更改范围，以便组变得无效。在这个版本中，无效的组会被删除，从而导致错误。(NETOBSERV-1722)
• 从 OpenShift web 控制台 Form view 创建 FlowCollector 资源时，与 YAML 视图 不同，以下设置被 web 控制台： agent.ebpf.metrics.enable 和 processor.subnetLabels.openShiftAutoDetect 管理。这些设置只能在 YAML 视图中被禁用，不能在 Form 视图中禁用。为避免混淆，这些设置已从 Form 视图中删除。它们仍可在 YAML 视图中访问。(NETOBSERV-1731)
• 在以前的版本中，eBPF 代理无法在非正常崩溃前清理安装的流量控制流，例如因为 SIGTERM 信号造成崩溃。这会导致使用相同名称创建多个流量控制流过滤，因为旧的流没有被删除。在这个版本中，在代理启动时，所有之前安装的流量控制流都会被清理。(NETOBSERV-1732)
• 在以前的版本中，当配置自定义子网标签并保持 OpenShift 子网自动检测时，OpenShift 子网优先于自定义子网，从而导致在集群子网中定义自定义标签。在这个版本中，自定义的子网具有优先权，允许在集群子网中定义自定义标签。(NETOBSERV-1734)

• Network Observability Operator 1.6.0

• 在以前的版本中，Operator Lifecycle Manager (OLM)表单中会显示到 OpenShift Container Platform 文档的死链接，用于创建 FlowMetrics API。现在，链接已被更新以指向有效的页面。(NETOBSERV-1607)
• 在以前的版本中，Operator Hub 中的 Network Observability Operator 描述信息中显示的一个到文档的链接有问题。在这个版本中，这个链接也被修正。(NETOBSERV-1544)
• 在以前的版本中，如果 Loki 被禁用，且 Loki Mode 被设置为 LokiStack，或者配置了 Loki manual TLS 配置，Network Observability Operator 仍然会尝试读取 Loki CA 证书。在这个版本中，当 Loki 被禁用时，即使在 Loki 配置中有设置，也不会读 Loki 证书。(NETOBSERV-1647)
• 在以前的版本中，Network Observability Operator 的 oc must-gather 插件只适用于 amd64 架构，并在所有其他架构上都会失败，这是因为对于 oc，插件使用了 amd64。现在，Network Observability Operator oc must-gather 插件会在任何架构平台上收集日志。
• 在以前的版本中，当使用 不等于 逻辑过滤 IP 地址时，Network Observability Operator 会返回请求错误。现在，对于 IP 地址和范围的 IP 过滤，可以正常使用等于和不等于逻辑。(NETOBSERV-1630)
• 在以前的版本中，当用户不是管理员时，错误消息与 web 控制台中的 Network Traffic 视图的所选标签页不一致。现在，user not admin 错误可以正确地在任何标签页中显示。(NETOBSERV-1621)

• 当 eBPF 代理 PacketDrop 功能被启用，并抽样被配置为一个大于 1 的值时，报告的丢弃的字节并丢弃数据包会忽略抽样配置。虽然这样做的目的为了不遗漏任何数据丢弃，但这样做的一个副作用是报告的丢弃数据与非丢弃数据的比例变得有倾向性。例如，对于一个非常高的抽样率（如 1:1000 ）中，在控制台插件中观察到的情况是，几乎所有流量都被丢弃。(NETOBSERV-1676)
• 在 Overview 选项卡中的 Manage panels 窗口中，过滤 总计,bar,donut, or line 不会显示任何结果。(NETOBSERV-1540)
• 如果首先创建了接口，然后才部署 eBPF 代理，则不会检测到这个 SR-IOV 二级接口。只有在先部署了代理，然后再创建 SR-IOV 接口时，才会检测到它。(NETOBSERV-1697)
• 当禁用 Loki 时，OpenShift Web 控制台中的 Topology 视图始终会在网络拓扑图旁边的滑块中显示集群和 区域聚合选项，即使未启用相关的功能。现在还没有可以解决这个问题的临时解决方案，只能忽略这些滑块选项。(NETOBSERV-1705)
• 当 Loki 被禁用时，OpenShift Web 控制台第一次加载时，可能会显示错误：Request failed with status code 400 Loki is disabled。作为临时解决方案，您可以继续在 Network Traffic 页面中切换内容，如点 Topology 和 Overview 选项卡。这个错误应该会消失。(NETOBSERV-1706)

• 在以前的版本中，如果禁用了 console 插件的自动注册功能，则无法在 web 控制台界面中手动注册 console 插件。如果在 FlowCollector 资源中将 spec.console.register 值设置为 false，Operator 会覆盖并清除插件注册。在这个版本中，将 spec.console.register 值设置为 false 不会影响控制台插件注册或删除。因此，可以安全地手动注册插件。(NETOBSERV-1134)
• 在以前的版本中，使用默认指标设置，NetObserv/Health 仪表板显示一个名为 Flows Overhead 的空图形。这个指标只能通过从 ignoreTags 列表中删除 "namespaces-flows" 和 "namespaces" 时才可用。在这个版本中，在使用默认指标设置时，此指标可见。(NETOBSERV-1351)
• 在以前的版本中，运行 eBPF 代理的节点无法使用一个特定的集群配置解析。这会导致一连串的后果，并导致无法提供一些流量指标。在这个版本中，eBPF 代理的节点 IP 由 Operator 安全提供，从 pod 状态推断出。现在，缺少的指标会被恢复。(NETOBSERV-1430)
• 在以前的版本中，Loki Operator 的 Loki 错误 'Input size too long' 错误中没有包括可以帮助进行故障排除的额外信息。在这个版本中，帮助信息在 web 控制台中的错误旁显示，并带有直接链接来获得更详细的信息。(NETOBSERV-1464)
• 在以前的版本中，控制台插件读取超时被强制为 30s。使用 FlowCollector v1beta2 API 更新，您可以配置 spec.loki.readTimeout 规格来根据 Loki Operator queryTimeout 限制更新这个值。(NETOBSERV-1443)
• 在以前的版本中，Operator 捆绑包不会按预期显示 CSV 注解的一些支持功能，如 features.operators.openshift.io/…​。在这个版本中，这些注解会在 CSV 中按预期设置。(NETOBSERV-1305)
• 在以前的版本中，在协调过程中，FlowCollector 状态有时会在 DeploymentInProgress 和 Ready 状态之间转换。在这个版本中，只有在所有底层组件都完全就绪时，状态才会变为 Ready。(NETOBSERV-1293)

• 当尝试访问 web 控制台时，OCP 4.14.10 上的缓存问题会阻止访问 Observe 视图。Web 控制台显示错误消息：Failed to get a valid plugin manifest from /api/plugins/monitoring-plugin/.推荐的解决方法是，把集群升级到最新的次版本。如果这无法解决问题，请参阅红帽知识库文章。(NETOBSERV-1493)
• 由于 Network Observability Operator 的 1.3.0 发行版本，安装 Operator 会导致出现警告内核污点。此错误的原因是网络可观察 eBPF 代理具有内存限制，阻止预分配整个哈希映射表。Operator eBPF 代理设置 BPF_F_NO_PREALLOC 标志，以便在 hashmap 过内存扩展时禁用预分配。

• 2023:6787 network Observability Operator 1.4.2

• 2023-39325
• 2023-44487

• 2023:5974 network Observability Operator 1.4.1

• 2023-44487
• 2023-39325
• 2023-29406
• 2023-29409
• 2023-39322
• 2023-39318
• 2023-39319
• 2023-39321

• 在 1.4 中，向 Kafka 发送网络流数据时存在一个已知问题。Kafka 消息密钥被忽略，从而导致带有连接跟踪的错误。现在，密钥用于分区，因此来自同一连接的每个流都会发送到同一处理器。(NETOBSERV-926)
• 在 1.4 中，引入了 Inner 流方向，以考虑在同一节点上运行的 pod 间的流。在生成的 Prometheus 指标中不会考虑从流派生的 Prometheus 指标中的带有 Inner 方向的流，从而导致出现以下字节和数据包率。现在，派生的指标包括带有 Inner 方向的流，提供正确的字节和数据包率。(NETOBSERV-1344)

• RHSA-2023:5379 Network Observability Operator 1.4.0

• 在以前的版本中，网络可观察性导出的 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)

• 由于 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 会导致出现警告内核污点。此错误的原因是网络可观察 eBPF 代理具有内存限制，阻止预分配整个哈希映射表。Operator eBPF 代理设置 BPF_F_NO_PREALLOC 标志，以便在 hashmap 过内存扩展时禁用预分配。

• RHSA-2023:3905 Network Observability Operator 1.3.0

• 在以前的版本中，当通过 CLI 安装 Operator 时，Cluster Monitoring Operator 所需的 Role 和 RoleBinding 不会按预期安装。从 Web 控制台安装 Operator 时，不会出现这个问题。现在，安装 Operator 的任何方法都会安装所需的 Role 和 RoleBinding。(NETOBSERV-1003)
• 自版本 1.2 起，Network Observability Operator 可以在流集合出现问题时引发警报。在以前的版本中，由于一个程序错误，用于禁用警报的相关配置，spec.processor.metrics.disableAlerts 无法正常工作，有时无效。现在，此配置已被修复，可以禁用警报。(NETOBSERV-976)
• 在以前的版本中，当将 spec.loki.authToken 设置为 DISABLED 时，只有 kubeadmin 集群管理员能够查看网络流。其他类型的集群管理员收到授权失败。现在，任何集群管理员都可以查看网络流。(NETOBSERV-972)
• 在以前的版本中，一个 bug 会阻止用户将 spec.consolePlugin.portNaming.enable 设置为 false。现在，此设置可以设置为 false 来禁用端口到服务名称转换。(NETOBSERV-971)
• 在以前的版本中，Cluster Monitoring Operator (Prometheus) 不会收集由 console 插件公开的指标，因为配置不正确。现在，配置已被修复，控制台插件指标可以被正确收集并从 OpenShift Container Platform Web 控制台访问。(NETOBSERV-765)
• 在以前的版本中，当在 FlowCollector 中将 processor.metrics.tls 设置为 AUTO 时，flowlogs-pipeline servicemonitor 不会适应适当的 TLS 方案，且指标在 web 控制台中不可见。现在，这个问题已针对 AUTO 模式解决。(NETOBSERV-1070)
• 在以前的版本中，证书配置（如 Kafka 和 Loki）不允许指定 namespace 字段，这意味着证书必须位于部署网络可观察性的同一命名空间中。另外，当在 TLS/mTLS 中使用 Kafka 时，用户必须手动将证书复制到部署 eBPF 代理 pod 的特权命名空间，并手动管理证书更新，如证书轮转时。现在，通过为 FlowCollector 资源中的证书添加 namespace 字段来简化网络可观察性设置。现在，用户可以在不同的命名空间中安装 Loki 或 Kafka，而无需在网络可观察性命名空间中手动复制其证书。原始证书会被监视，以便在需要时自动更新副本。(NETOBSERV-773)
• 在以前的版本中，网络可观察性代理不包括 SCTP、ICMPv4 和 ICMPv6 协议，从而更全面的网络流覆盖。现在，这些协议可以被识别以改进流覆盖。(NETOBSERV-934)

• 当 FlowCollector 中的 processor.metrics.tls 设置为 PROVIDED 时，flowlogs-pipeline servicemonitor 不会适应 TLS 方案。(NETOBSERV-1087)
• 由于 Network Observability Operator 的 1.2.0 发行版本使用 Loki Operator 5.6，Loki 证书更改会定期影响 flowlogs-pipeline pod，并导致丢弃流而不是写入 Loki 的流。一段时间后，问题会自行修正，但它仍然会在 Loki 证书更改过程中导致临时流数据丢失。此问题仅在有 120 个节点或更多节点的大型环境中观察到。(NETOBSERV-980)
• 安装 Operator 时，可能会出现警告内核污点。此错误的原因是网络可观察 eBPF 代理具有内存限制，阻止预分配整个哈希映射表。Operator eBPF 代理设置 BPF_F_NO_PREALLOC 标志，以便在 hashmap 过内存扩展时禁用预分配。

• RHSA-2023:1817 Network Observability Operator 1.2.0

• 在以前的版本中，在更改 FlowCollector spec 中的 namespace 值后，在前一个命名空间中运行的 eBPF 代理 pod 没有被适当删除。现在，在上一个命名空间中运行的 pod 会被正确删除。(NETOBSERV-774)
• 在以前的版本中，在更改 FlowCollector spec （如 Loki 部分）中的 caCert.name 值后，FlowLogs-Pipeline pod 和 Console 插件 pod 不会重启，因此它们不知道配置更改。现在，pod 被重启，因此它们会获得配置更改。(NETOBSERV-772)
• 在以前的版本中，在不同节点上运行的 pod 间的网络流有时没有正确识别为重复，因为它们由不同的网络接口捕获。这会导致控制台插件中显示过量的指标。现在，流会被正确识别为重复，控制台插件会显示准确的指标。(NETOBSERV-755)
• 控制台插件中的 "reporter" 选项用于根据源节点或目标节点的观察点过滤流。在以前的版本中，无论节点观察点是什么，这个选项都会混合流。这是因为在节点级别将网络流错误地报告为 Ingress 或 Egress。现在，网络流方向报告是正确的。源观察点的 "reporter" 选项过滤器，或目标观察点如预期。( NETOBSERV-696)
• 在以前的版本中，对于配置为直接将流作为 gRPC+protobuf 请求发送的代理，提交的有效负载可能太大，并由处理器的 GRPC 服务器拒绝。这会在有非常高负载的场景中发生，且只会发生在一些代理配置中。代理记录错误消息，例如：grpc: received message larger than max。因此，缺少有关这些流的信息丢失。现在，当大小超过阈值时，gRPC 有效负载被分成多个信息。因此，服务器可以维护连接状态。(NETOBSERV-617)

• 在 Network Observability Operator 的 1.2.0 发行版本中，使用 Loki Operator 5.6，Loki 证书转换会定期影响 flowlogs-pipeline pod，并导致丢弃流而不是写入 Loki 的流程。一段时间后，问题会自行修正，但它仍然会在 Loki 证书转换过程中导致临时流数据丢失。(NETOBSERV-980)

• NETOBSERV-907
• NETOBSERV-956

• RHSA-2023:0786 Network Observability Operator 安全公告更新

• 在以前的版本中，除非 Loki authToken 配置被设置为 FORWARD 模式，否则不会强制身份验证，允许未授权用户检索流。现在，无论 Loki authToken 模式如何，只有集群管理员才能检索流。(BZ#2169468)

验证

• 创建 secret 后，您可以查看 web 控制台中的 Workloads → Secrets 下列出的 secret。

先决条件

• 已安装旧版本的 Operator，并希望准备集群来安装最新版本的 Operator。或者您试图安装 Network Observability Operator 1.6 并遇到错误：Failed risk of data loss updating "flowcollectors.flows.netobserv.io": new CRD removes version v1alpha1 that is listed as a stored version on the existing CRD。

验证

• 运行以下命令:

  $ oc get crd flowcollectors.flows.netobserv.io -ojsonpath='{.status.storedVersions}'

  结果列表应该不再显示 v1alpha1，仅显示最新版本 v1beta1。

• 额外小：每个 worker 10 个节点集群、4 个 vCPU 和 16 GiB 内存，Loki size 1x.extra-small，在 AWS M6i 实例上测试。
• Small: 25 个节点集群、每个 worker 16 vCPU 和 64 GiB 内存，Loki size 1x.small，在 AWS M6i 实例上测试。
• large: 250 个节点集群、每个 worker 16 vCPU 和 64 GiB 内存，Loki size 1x.medium，在 AWS M6i 实例上测试。除了 worker 和控制器节点外，还测试三个基础架构节点(size M6i.12xlarge)和一个工作负载节点(size M6i.8xlarge)。

• 除了 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。

• 为特定命名空间或工作负载启用选择流集合。
• 支持多租户和基于环境的可观察性。
• 通过过滤不相关的流量来降低存储和处理成本。
• 通过 opt-in 配置保留向后兼容性。

• 验证结果。
• 协调状态。
• 片段是否已成功应用。

• 审计外部依赖项：确保工作负载没有到达未授权的外部 API 或高风险域。
• 性能调优：监控 DNS 延迟，以识别 CoreDNS pod 是否需要额外的扩展，或者是否出现上游 DNS 供应商。

前提条件

• 使用管理员权限访问集群。

• Scope ：选择查看网络流量流在其中进行的组件。您可以将范围设置为 Node,Namespace,Owner,Zones,Cluster 或 Resource。Owner 是一个资源聚合。Resource 可以是一个 pod、服务、节点（主机网络流量），或未知 IP 地址。默认值为 Namespace。
• Truncate labels：从下拉列表中选择标签所需的宽度。默认值为 M。

• 身份识别：指定发生数据包丢弃的确切位置和网络路径。确定特定设备、接口或路由是否更易于丢弃。
• 根本原因分析：检查 eBPF 程序收集的数据，以了解数据包丢弃的原因。例如，它们是拥塞、缓冲区问题还是特定的网络事件的结果？
• 性能优化：通过数据包丢弃的清晰了解，您可以采取步骤来优化网络性能，如调整缓冲区大小、重新配置路由路径或实施服务质量(QoS)测量。

• 顶级 X 数据包丢弃状态的堆栈为总计
• 顶级 X 数据包丢弃会导致堆栈总计
• 顶级 X 平均丢弃的数据包率
• 顶级 X 丢弃的数据包速率堆栈为总计