搜索

第 28 章 Network Observability(网络可观察性)

download PDF

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 中的多租户
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 所需的 RoleRoleBinding 不会按预期安装。从 Web 控制台安装 Operator 时,不会出现这个问题。现在,安装 Operator 的任何方法都会安装所需的 RoleRoleBinding。(NETOBSERV-1003)
  • 自版本 1.2 起,Network Observability Operator 可以在流集合出现问题时引发警报。在以前的版本中,由于一个程序错误,用于禁用警报的相关配置,spec.processor.metrics.disableAlerts 无法正常工作,有时无效。现在,此配置已被修复,可以禁用警报。(NETOBSERV-976)
  • 在以前的版本中,当 Network Observability 被配置为 spec.loki.authTokenDISABLED 时,只有 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-pipeline servicemonitor 不会适应 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-pipeline pod,并导致丢弃流而不是写入 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 控制台的用户,在没有身份验证的情况下检索流。现在,无论 Loki authToken 模式如何,只有集群管理员才能检索流。(BZ#2169468)
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.