第 1 章 Network Observability Operator 发行注记
Network Observability Operator 可让管理员观察和分析 OpenShift Container Platform 集群的网络流量流。
本发行注记介绍了 OpenShift Container Platform 中 Network Observability Operator 的开发。
有关 Network Observability Operator 的概述,请参阅关于 Network Observability Operator。
1.1. Network Observability Operator 1.7.0
以下公告可用于 Network Observability Operator 1.7.0:
1.1.1. 新功能及功能增强
1.1.1.1. OpenTelemetry 支持
现在,您可以将增强的网络流导出到兼容的 OpenTelemetry 端点,如红帽构建的 OpenTelemetry。如需更多信息,请参阅导出增强的网络流数据。
1.1.1.2. Network Observability Developer 视角
现在,您可以在 Developer 视角中使用 Network Observability。如需更多信息,请参阅 OpenShift Container Platform 控制台集成。
1.1.1.3. TCP 标记过滤
现在,您可以使用 tcpFlags
过滤器来限制 eBPF 程序处理的数据包卷。如需更多信息,请参阅流过滤器配置参数、eBPF 流规则过滤器,以及使用 FlowMetric API 和 TCP 标记来检测 SYN 填充。
1.1.1.4. OpenShift Virtualization 的网络可观察性
您可以通过识别来自连接到二级网络的虚拟机(如通过 Open Virtual Network (OVN)-Kubernetes)的 eBPF 增强网络流来观察 OpenShift Virtualization 设置中的网络模式。如需更多信息,请参阅为 Network Observability 配置虚拟机(VM)二级网络接口。
1.1.1.5. 网络策略在 FlowCollector 自定义资源 (CR) 中部署
在这个版本中,您可以将 FlowCollector
CR 配置为为 Network Observability 部署网络策略。在以前的版本中,如果需要网络策略,您必须手动创建一个。手动创建网络策略的选项仍然可用。如需更多信息,请参阅使用 FlowCollector 自定义资源配置入口网络策略。
1.1.1.6. FIPS 合规性
您可以在以 FIPS 模式运行的 OpenShift Container Platform 集群中安装和使用 Network Observability Operator。
重要要为集群启用 FIPS 模式,您必须从配置为以 FIPS 模式操作的 Red Hat Enterprise Linux (RHEL) 计算机运行安装程序。有关在 RHEL 中配置 FIPS 模式的更多信息,请参阅将 RHEL 切换到 FIPS 模式。
当以 FIPS 模式运行 Red Hat Enterprise Linux (RHEL) 或 Red Hat Enterprise Linux CoreOS (RHCOS)时,OpenShift Container Platform 核心组件使用 RHEL 加密库,在 x86_64、ppc64le 和 s390x 架构上提交到 NIST FIPS 140-2/140-3 Validation。
1.1.1.7. eBPF 代理增强
eBPF 代理有以下改进:
-
如果 DNS 服务映射到与
53
不同的端口,您可以使用spec.agent.ebpf.advanced.env.DNS_TRACKING_PORT
指定此 DNS 跟踪端口。 - 现在,您可以将两个端口用于传输协议(TCP、UDP 或 SCTP)过滤规则。
- 现在,您可以通过将 protocol 字段留空来过滤带有通配符协议的传输端口。
如需更多信息,请参阅 FlowCollector API 规格。
1.1.1.8. Network Observability CLI
Network Observability CLI (oc netobserv
) 现已正式发布。自 1.6 技术预览版本开始进行了以下改进:* 现在提供了一个 eBPF 过滤器用于数据包捕获,与流捕获类似。现在,您可以在流和数据包捕获中使用过tcp_flags
过滤。* 当达到 max-bytes 或 max-time 时,auto-teardown 选项可用。如需更多信息,请参阅 Network Observability CLI 和 Network Observability CLI 1.7.0。
1.1.2. 程序错误修复
-
在以前的版本中,当使用 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)
1.1.3. 已知问题
- 在 Network Observability 中使用 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