第 28 章 Network Observability（网络可观察性）
28.1. Network Observability Operator 发行注记
Network Observability Operator 可让管理员观察和分析 OpenShift Container Platform 集群的网络流量流。
本发行注记介绍了 OpenShift Container Platform 中 Network Observability Operator 的开发。
有关 Network Observability Operator 的概述，请参阅关于 Network Observability Operator。
28.1.1. Network Observability Operator 1.3.0
以下公告可用于 Network Observability Operator 1.3.0 ：
28.1.1.1. 频道弃用
您必须将频道从 v1.0.x 切换到 stable，以接收将来的 Operator 更新。v1.0.x 频道已弃用，计划在以后的发行版本中删除。
28.1.1.2. 新功能及功能增强
28.1.1.2.1. Network Observability 中的多租户
- 系统管理员可以将单独的用户访问或组访问权限限制为存储在 Loki 中的流。如需更多信息，请参阅 Network Observability 中的多租户。
28.1.1.2.2. 基于流的指标仪表板
- 此发行版本添加了一个新的仪表板，它概述了 OpenShift Container Platform 集群中的网络流。如需更多信息，请参阅 Network Observability 指标。
28.1.1.2.3. 使用 must-gather 工具进行故障排除
- 有关 Network Observability Operator 的信息现在可以包含在 must-gather 数据中以进行故障排除。如需更多信息，请参阅 Network Observability must-gather。
28.1.1.2.4. 现在支持多个构架
- Network Observability Operator 现在可在 amd64、ppc64le 或 arm64 架构上运行。在以前的版本中，它只在 amd64 上运行。
28.1.1.3. 已弃用的功能
28.1.1.3.1. 弃用的配置参数设置
Network Observability Operator 1.3 发行版本弃用了 spec.Loki.authToken HOST 设置。使用 Loki Operator 时，现在必须使用 FORWARD 设置。
28.1.1.4. 程序错误修复
-
在以前的版本中，当通过 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) -
在以前的版本中，当 Network Observability 被配置为
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 字段，这意味着证书必须位于部署 Network Observability 的同一命名空间中。另外，当在 TLS/mTLS 中使用 Kafka 时，用户必须手动将证书复制到部署 eBPF 代理 pod 的特权命名空间，并手动管理证书更新，如证书轮转时。现在，通过在
FlowCollector资源中为证书添加 namespace 字段来简化 Network Observability 设置。现在，用户可以在不同的命名空间中安装 Loki 或 Kafka，而无需在 Network Observability 命名空间中手动复制其证书。原始证书会被监视，以便在需要时自动更新副本。(NETOBSERV-773) - 在以前的版本中，Network Observability 代理没有涵盖 SCTP、ICMPv4 和 ICMPv6 协议，从而导致较少的全面的网络流覆盖。现在，这些协议可以被识别以改进流覆盖。(NETOBSERV-934)
28.1.1.5. 已知问题
-
当
FlowCollector中的processor.metrics.tls设置为PROVIDED时，flowlogs-pipelineservicemonitor不会适应 TLS 方案。(NETOBSERV-1087)
28.1.2. Network Observability Operator 1.2.0
以下公告可用于 Network Observability Operator 1.2.0 ：
28.1.2.1. 准备下一次更新
已安装的 Operator 的订阅指定一个更新频道，用于跟踪和接收 Operator 的更新。在 Network Observability Operator 的 1.2 发布前，唯一可用的频道为 v1.0.x。Network Observability Operator 的 1.2 发行版本引入了用于跟踪和接收更新的 stable 更新频道。您必须将频道从 v1.0.x 切换到 stable，以接收将来的 Operator 更新。v1.0.x 频道已弃用，计划在以后的发行版本中删除。
28.1.2.2. 新功能及功能增强
28.1.2.2.1. 流量流视图中的直方图
- 现在，您可以选择显示一段时间内流的直方图表。histogram 可让您视觉化流历史记录，而不会达到 Loki 查询的限制。如需更多信息，请参阅使用直方图。
28.1.2.2.2. 对话跟踪
- 现在，您可以通过 Log Type 查询流，它允许对同一对话一部分的网络流进行分组。如需更多信息，请参阅使用对话。
28.1.2.2.3. Network Observability 健康警报
-
现在，如果因为写入阶段出现错误，或者达到 Loki ingestion 速率限制，Network Observability Operator 会在
flowlogs-pipeline丢弃流时自动创建自动警报。如需更多信息，请参阅查看健康信息。
28.1.2.3. 程序错误修复
-
在以前的版本中，在更改 FlowCollector spec 中的
namespace值后，在前一个命名空间中运行的 eBPF Agent 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)
28.1.2.4. 已知问题
-
在 Network Observability Operator 的 1.2.0 发行版本中，使用 Loki Operator 5.6，Loki 证书转换会定期影响
flowlogs-pipelinepod，并导致丢弃流而不是写入 Loki 的流程。一段时间后，问题会自行修正，但它仍然会在 Loki 证书转换过程中导致临时流数据丢失。(NETOBSERV-980)
28.1.2.5. 主要的技术变化
-
在以前的版本中，您可以使用自定义命名空间安装 Network Observability Operator。此发行版本引入了
转换 Webhook，它更改了ClusterServiceVersion。由于这个变化，所有可用的命名空间不再被列出。另外，要启用 Operator 指标集合，无法使用与其他 Operator 共享的命名空间（如openshift-operators命名空间）。现在，Operator 必须安装在openshift-netobserv-operator命名空间中。如果您之前使用自定义命名空间安装 Network Observability Operator，则无法自动升级到新的 Operator 版本。如果您之前使用自定义命名空间安装 Operator，您必须删除已安装的 Operator 实例，并在openshift-netobserv-operator命名空间中重新安装 Operator。务必要注意，对于FlowCollector、Loki、Kafka 和其他插件，仍可使用自定义命名空间（如常用的netobserv命名空间）。(NETOBSERV-907)(NETOBSERV-956)
28.1.3. Network Observability Operator 1.1.0
以下公告可用于 Network Observability Operator 1.1.0：
Network Observability Operator 现在稳定，发行频道已升级到 v1.1.0。
28.1.3.1. 程序错误修复
-
在以前的版本中，除非 Loki
authToken配置被设置为FORWARD模式，否则不再强制执行身份验证，允许任何可以在 OpenShift Container Platform 集群中连接到 OpenShift Container Platform 控制台的用户，在没有身份验证的情况下检索流。现在，无论 LokiauthToken模式如何，只有集群管理员才能检索流。(BZ#2169468)
