OpenShift 中 AMQ Streams 2.2 发行注记
OpenShift Container Platform 中此 AMQ Streams 发行版本的主要新功能及变化信息
摘要
使开源包含更多
红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。我们从这四个术语开始:master、slave、黑名单和白名单。由于此项工作十分艰巨,这些更改将在即将推出的几个发行版本中逐步实施。有关更多详情,请参阅我们的首席技术官 Chris Wright 提供的消息。
第 1 章 功能
AMQ Streams 2.2 及后续补丁版本引入了本节所述的功能。
OpenShift 上的 AMQ Streams 2.2 基于 Kafka 3.2.3 和 Strimzi 0.29.x。
要查看此版本中已解决的所有增强和错误,请查看 AMQ Streams Jira 项目。
1.1. AMQ Streams 2.2.x (Long Term Support)
AMQ Streams 2.2.x 是 AMQ Streams 的 Long Term Support (LTS)。
最新的补丁版本是 AMQ Streams 2.2.1。AMQ Streams 产品镜像已改为 2.2.1 版本。支持的 Kafka 版本保留在 3.2.3 中。
有关 LTS 术语和日期的详情,请查看 AMQ Streams LTS 支持策略。
1.2. OpenShift Container Platform 支持
OpenShift Container Platform 4.8 到 4.11 支持 AMQ Streams 2.2。
有关支持的平台版本的更多信息,请参阅 AMQ Streams 支持的配置。
1.3. Kafka 3.2.3 支持
AMQ Streams 现在支持 Apache Kafka 版本 3.2.3。
AMQ Streams uses Kafka 3.2.3.仅支持由红帽构建的 Kafka 发行版本。
您必须将 Cluster Operator 升级到 AMQ Streams 版本 2.2,然后才能将代理和客户端应用程序升级到 Kafka 3.2.3。有关升级说明,请参阅升级 AMQ Streams。
如需了解更多信息,请参阅 Kafka 3.1.0、Kafka 3.2.0、Kafka 3.2.1 和 Kafka 3.2.3 发行注记。
Kafka 3.1.x 仅支持升级到 AMQ Streams 2.2。
有关支持的版本的更多信息,请参阅 AMQ Streams 组件详情。
Kafka 3.2.3 使用 ZooKeeper 版本 3.6.3,它与 Kafka 3.1.0 版本相同。
1.4. 支持 v1beta2 API 版本
AMQ Streams 1.7 中引入了所有自定义资源的 v1beta2 API 版本。对于 AMQ Streams 1.8、v1alpha1 和 v1beta1 API 版本已从 KafkaTopic 和 KafkaUser 之外的所有 AMQ Streams 自定义资源中删除。
将自定义资源升级到 v1beta2 准备 AMQ Streams 以移至 Kubernetes CRD v1,这是 Kubernetes v1.22 所需要的。
如果您要从版本 1.7 之前的 AMQ Streams 版本升级:
- 升级到 AMQ Streams 1.7
-
将自定义资源转换为
v1beta2 - 升级到 AMQ Streams 1.8
在升级到 AMQ Streams 版本 2.2 前,您必须升级自定义资源以使用 API 版本 v1beta2。
请参阅 部署和升级 AMQ Streams。
1.4.1. 将自定义资源升级到 v1beta2
为了支持将自定义资源升级到 v1beta2,AMQ Streams 提供了一个 API 转换工具,您可以从 AMQ Streams 软件下载页面。
您可以在两个步骤中执行自定义资源升级。
步骤一:转换自定义资源的格式
使用 API 转换工具,您可以使用以下两种方式之一将自定义资源格式转换为适用于 v1beta2 的格式:
- 转换描述 AMQ Streams 自定义资源配置的 YAML 文件
- 直接在集群中转换 AMQ Streams 自定义资源
另外,您可以手动将每个自定义资源转换为适用于 v1beta2 的格式。文档中包括了手动转换自定义资源的说明。
步骤 2:将 CRD 升级到 v1beta2
接下来,在 crd-upgrade 命令中使用 API 转换工具,您必须将 v1beta2 设置为 CRD 中的 存储 API 版本。您无法手动执行此步骤。
有关完整步骤,请参阅升级 AMQ Streams。
1.5. 支持 IBM Z 和 LinuxONE 架构
AMQ Streams 2.2 被启用在 IBM Z 和 LinuxONE s390x 架构中运行。
对 IBM Z 和 LinuxONE 的支持适用于在 OpenShift Container Platform 4.10 及更新的版本中使用 Kafka 运行的 AMQ Streams。
1.5.1. IBM Z 和 LinuxONE 的要求
- OpenShift Container Platform 4.10 及更新的版本
1.5.2. 不支持 IBM Z 和 LinuxONE
- 断开连接的 OpenShift Container Platform 环境中的 AMQ Streams
- AMQ Streams OPA 集成
1.6. 支持 IBM Power 架构
AMQ Streams 2.2 被启用在 IBM Power ppc64le 构架中运行。
对 IBM Power 的支持适用于在 OpenShift Container Platform 4.9 及更新的版本中使用 Kafka 运行的 AMQ Streams。
1.6.1. IBM Power 的要求
- OpenShift Container Platform 4.9 及更新的版本
1.6.2. 不支持 IBM Power
- 断开连接的 OpenShift Container Platform 环境中的 AMQ Streams
1.7. UseStrimziPodSets 功能门(技术预览)
UseStrimziPodSets 功能门控制用于管理名为 StrimziPodSet 的 pod 的资源。启用功能门时,会使用此资源而不是 StatefulSets。AMQ Streams 处理 pod 的创建和管理,而不是 OpenShift。使用 StrimziPodSets 而不是 StatefulSets 可以提供对功能的更多控制。
功能门处于 alpha 成熟度,因此应被视为技术预览。
预览提供了测试 StrimziPodSet 资源的机会。在 2.3 版本中会默认启用这个功能。
要启用功能门,在 Cluster Operator 配置中将 +UseStrimziPodSets 指定为 STRIMZI_FEATURE_GATES 环境变量的值。
启用 UseStrimziPodSets 功能门
env:
- name: STRIMZI_FEATURE_GATES
value: +UseStrimziPodSets
请参阅 UseStrimziPodSets 功能门 和 功能门发行版本。
1.8. UseKRaft 功能门(开发预览)
作为 Kafka 集群管理员,您可以使用 Cluster Operator 部署配置中的功能门打开和关闭功能的子集。
Apache Kafka 正在进行 ZooKeeper 的需求。启用新的 UseKRaft 功能门后,您可以尝试在没有 ZooKeeper 的情况下在 KRaft(Kafka Raft 元数据)模式下部署 Kafka 集群。
此功能门处于 alpha 成熟度,但应该被视为开发预览。
此功能门是实验性的,仅 用于开发和测试,在生产环境中不能启用。
要启用 UseKRaft 功能门,在 Cluster Operator 配置中将 +UseKRaft 和 +USeStrimziPodSets 指定为 STRIMZI_FEATURE_GATES 环境变量的值。UseKRaft 功能门依赖于 UseStrimziPodSets 功能门。
启用 UseKRaft 功能门
env:
- name: STRIMZI_FEATURE_GATES
value: +UseKRaft, +USeStrimziPodSets
目前,AMQ Streams 中的 KRaft 模式有以下主要限制:
- 不支持从带有 ZooKeeper 的 Kafka 集群移动到 KRaft 集群或其他方法。
- 不支持升级和降级 Apache Kafka 版本或 AMQ Streams operator。用户可能需要删除集群,升级 Operator 并部署新的 Kafka 集群。
-
不支持 Entity Operator(包括 User Operator 和 Topic operator)。
spec.entityOperator属性 必须从Kafka自定义资源中删除。 -
不支持
简单授权。 - 不支持 SCRAM-SHA-512 验证。
-
不支持 JBOD 存储。可以使用
type: jbod存储,但 JBOD 阵列只能包含一个磁盘。 - 禁用存活度和就绪度探测。
-
所有 Kafka 节点都有
控制器和代理KRaft 角色。不支持带有独立控制器和代理节点的 Kafka 集群。
请参阅 UseKRaft 功能门 和 功能门发行版本。
1.9. Cruise Control 正式发行(GA)
Cruise Control 从技术预览移到正式发行(GA)。您可以部署 Cruise Control,并在 CPU、磁盘、网络负载等上使用 优化目标 detector-targetNamespaces 定义限制来重新平衡 Kafka 集群。在均衡 Kafka 集群中,工作负载更加均匀地分布在代理 pod 中。
作为 Kafka 资源的一部分,Tithise Control 被配置和部署。您可以使用默认优化目标或修改它们以满足您的要求。用于 Cruise Control 的 YAML 配置文件示例在 /cruise-control/ 中提供。
部署 Cruise Control 时,您可以创建 KafkaRebalance 自定义资源:
- 从多个优化目标生成优化效果
- 基于优化建议重新平衡 Kafka 集群
目前不支持其他 Cruise 控制功能,包括异常检测、通知、写入目标以及更改主题复制因素。
1.10. Cruise 控制扩展和重新平衡模式
现在,您可以在以下模式中为重新平衡操作生成优化建议:
-
full -
add-brokers -
remove-brokers
在以前的版本中,建议以 完整 模式生成,副本可能会在集群中的所有代理中移动。现在,您使用 add-brokers 和 remove-brokers 模式来考虑扩展和缩减操作。
在扩展后使用 add-brokers 模式。您可以指定新的代理和重新平衡操作,将副本从现有代理移动到新添加的代理中。与重新平衡整个集群相比,这个选项要快。
在缩减前,使用 remove-brokers 模式。您可以指定要删除的代理,这意味着这些代理中的所有副本都会在重新平衡操作中移出。
1.11. 用于更改数据捕获集成的 Debezium
红帽 Debezium 是一个分布式更改数据捕获平台。它捕获数据库中的行级更改,创建更改事件记录,并将记录流传输到 Kafka 主题。Debezium 基于 Apache Kafka 构建。您可以将 Debezium 与 AMQ Streams 部署和集成。部署 AMQ Streams 后,您可以通过 Kafka Connect 将 Debezium 部署为连接器配置。Debezium 将更改事件记录传递到 OpenShift 上的 AMQ Streams。应用程序可以读取 这些更改事件流,并按发生更改事件的顺序访问更改事件。
Debezium 具有多个用途,包括:
- 数据复制
- 更新缓存和搜索索引
- 简化单体式应用程序
- 数据集成
- 启用流查询
Debezium 为以下通用数据库提供连接器(基于 Kafka Connect):
- Db2
- MongoDB
- MySQL
- PostgreSQL
- SQL Server
有关使用 AMQ Streams 部署 Debezium 的更多信息,请参阅 产品文档。
1.12. Service Registry
您可以将 Service Registry 用作数据流的集中式存储。对于 Kafka,您可以使用 Service Registry 来存储 Apache Avro 或 JSON 模式。
Service Registry 提供 REST API 和 Java REST 客户端,用于通过服务器端端点从客户端应用注册和查询架构。
使用 Service Registry 将管理模式的过程与客户端应用程序配置分离。您可以通过在客户端代码中指定 URL 来启用应用程序从 registry 中使用 schema。
例如,消息序列化和反序列化的架构可以存储在注册表中,后者随后从使用它们的应用程序引用,以确保它们发送和接收的消息与这些模式兼容。
Kafka 客户端应用程序可以在运行时从 Service Registry 中推送或拉取其模式。
有关在 AMQ Streams 中使用 Service Registry 的详情,请参考 Service Registry 文档。
第 2 章 功能增强
AMQ Streams 2.2 添加了一个很多改进。
2.1. Kafka 3.2.3 的改进
有关 Kafka 3.2.0、3.2.1 和 3.2.3 中引入的增强功能概述,请参阅 Kafka 3.2.0 发行注记、Kafka 3.2.1 发行注记 和 Kafka 3.2.3 发行注记。
2.2. 跟踪命令行中的 Cruise Control 状态
现在,可以更轻松地检查优化过程的状态。您可以在命令行中检查状态,而不是检查资源配置 YAML。
当您运行建议时,运行以下命令并等待优化建议更改为 ProposalReady :
oc get kafkarebalance -o wide -w -n <namespace>PendingProposal-
PendingProposal状态表示重新平衡 Operator 轮询 Cruise Control API,以检查优化建议是否就绪。 ProposalReady-
ProposalReady状态表示优化建议已进行审核和批准。
当状态更改为 ProposalReady 时,优化建议可以批准。
2.3. 在维护时间窗内续订用户证书
通过维护时间窗,您可以调度某些 Kafka 和 ZooKeeper 集群的滚动更新,以便方便地启动。现在 User Operator 支持维护窗口。如果您已经使用 Cluster Operator 部署了 User Operator,而不是作为独立 Operator 部署,则会在计划中包含自动续订用户证书。
如果要部署独立用户 Operator,您可以配置过期用户证书的维护时间窗。您可以将时间窗指定为 STRIMZI_MAINTENANCE_TIME_WINDOWS 环境变量的 Cron 表达式。
请参阅 部署独立用户 Operator。
2.4. 重命名控制主题
现在,可以重命名与由 Cruise Control 自动创建的指标相关的主题。您可以使用以下 Cruise Control 配置属性来更改名称。
修正控制主题重命名示例
apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
name: my-cluster
spec:
# ...
cruiseControl:
# ...
config: 1
# ...
metric.reporter.topic: cruise-control-metrics-reporter-topic-name
partition.metric.sample.store.topic: cruise-control-partitions-metrics-name
broker.metric.sample.store.topic: cruise-control-broker-metrics
# ...
# ...
如果更改了现有部署中的主题的名称,则需要使用旧名称手动删除主题。
2.5. 在没有 ZooKeeper 的情况下使用 Cruise Control
现在,在没有 ZooKeeper 的情况下运行 Cruise Control,而是使用 Kafka API。用于与 ZooKeeper 进行安全通信的 TLS sidecar 已被删除。
不再需要 Kafka 资源中的 Cruise Control 的 TLS sidecar 配置。因此,.spec.cruiseControl.tlsSidecar 和 .spec.cruiseControl.template.tlsSidecar 属性现已弃用。
2.6. 为 MirrorMaker 2.0 配置机架感知
现在,您可以在 MirrorMaker 2.0 资源配置中启用机架感知功能。这是专门用于 同一位置部署的专门选项,而不是跨区域部署。如果您希望从最接近的副本(而非领导副本)消耗连接器,您可以使用这个选项。
机架 配置中的 topologyKey 必须与包含机架 ID 的节点标签匹配。在以下示例中,指定了标准的 topology.kubernetes.io/zone 标签。
MirrorMaker 2.0 的机架配置
apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaMirrorMaker2
metadata:
name: my-mirror-maker2
spec:
version: 3.2.3
# ...
rack:
topologyKey: topology.kubernetes.io/zone
要使用最接近的副本,还必须在 Kafka 代理配置中启用 RackAwareReplicaSelector。
带有启用副本感知选择器的 机架 配置示例
apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
name: my-cluster
spec:
kafka:
# ...
rack:
topologyKey: topology.kubernetes.io/zone
config:
# ...
replica.selector.class: org.apache.kafka.common.replica.RackAwareReplicaSelector
# ...
2.7. 根据可用内存的百分比设置堆大小
如果您没有在配置中指定堆大小,Cluster Operator 会自动实施默认堆大小。Cluster Operator 根据内存资源配置的百分比设置默认最大和最小堆大小。现在,在下表中显示的级别上设置默认分配的可用内存。
表 2.1. 组件的默认堆设置
| 组件 | 分配给堆的可用内存百分比 | 最大限制 |
|---|---|---|
| Kafka | 50% | 5 GB |
| ZooKeeper | 75% | 2 GB |
| Kafka Connect | 75% | 无 |
| MirrorMaker 2.0 | 75% | 无 |
| MirrorMaker | 75% | 无 |
| Sything Control | 75% | 无 |
| Kafka Bridge | 50% | 31 Gi |
请参阅 jvmOptions
第 3 章 技术预览
技术预览功能不被红帽产品服务级别协议(SLA)支持,且可能无法完成。因此,红帽不推荐在生产环境中实施任何技术预览功能。此技术预览功能为您提供对即将推出的产品创新的早期访问,允许您在开发过程中测试并提供反馈。如需有关支持范围的更多信息,请参阅 技术预览功能支持范围。
3.1. 新功能门
现在,可以使用 UseKRaft 和 UseStrimziPodSets 功能门的预览。
请参阅 第 1 章 功能。
3.2. Kafka Static Quota 插件配置
使用 Kafka Static Quota 插件在 Kafka 集群中的代理上设置吞吐量和存储限制。您可以通过配置 Kafka 资源来启用插件和设置限值。您可以设置一个字节阈值和存储配额,以便对与代理交互的客户端进行限制。
Kafka Static Quota 插件配置示例
apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
name: my-cluster
spec:
kafka:
# ...
config:
client.quota.callback.class: io.strimzi.kafka.quotas.StaticQuotaCallback
client.quota.callback.static.produce: 1000000
client.quota.callback.static.fetch: 1000000
client.quota.callback.static.storage.soft: 400000000000
client.quota.callback.static.storage.hard: 500000000000
client.quota.callback.static.storage.check-interval: 5
第 4 章 Kafka 破坏更改
本节论述了对 Kafka 的任何更改,需要对 AMQ Streams 进行相应的更改才能继续工作。
4.1. 使用 Kafka 示例文件连接器
Kafka 不再在其 CLASSPATH 和 plugin.path 中包含示例文件连接器 file StreamSourceConnector 和 FileStreamSinkConnector。AMQ Streams 已被更新,您仍然可以使用这些示例连接器。现在,示例必须象任何连接器一样添加到插件路径中。
提供了两个连接器配置文件示例:
-
示例/connect/kafka-connect-build.yaml提供了一个 Kafka Connect构建配置,您可以部署该配置以使用文件连接器构建新的 Kafka 连接镜像。 -
example/connect/source-connector.yaml提供了将文件连接器部署为KafkaConnector资源所需要的配置。
第 5 章 已弃用的功能
本发行版本中弃用的功能,以及之前的 AMQ Streams 版本中所支持的功能如下所示。
5.1. OpenTracing
对 OpenTracing 的支持已弃用。
Jaeger 客户端现已停用,OpenTracing 项目存档。因此,我们不能保证其对将来的 Kafka 版本的支持。我们基于 OpenTelemetry 项目推出新的追踪实施。
5.2. Java 8
在 Kafka 3.0.0 和 AMQ Streams 2.0 中已弃用对 Java 8 的支持。以后,所有 AMQ Streams 组件(包括客户端)不支持 Java 8。
AMQ Streams 支持 Java 11。在开发新应用程序时使用 Java 11。计划将当前使用 Java 8 的任何应用程序迁移到 Java 11。
5.3. Kafka MirrorMaker 1
Kafka MirrorMaker 在两个或者多个活跃的 Kafka 集群或跨数据中心间复制数据。Kafka MirrorMaker 1 弃用了 Kafka 3.0.0,并将在 Kafka 4.0.0 中删除。MirrorMaker 2.0 是唯一可用的版本。MirrorMaker 2.0 基于 Kafka Connect 框架,连接器用来管理集群间传输数据的连接器。
因此,用于部署 Kafka MirrorMaker 1 的 AMQ Streams KafkaMirrorMaker 自定义资源已弃用。当采用 Kafka 4.0.0 时,KafkaMirrorMaker 资源将从 AMQ Streams 中删除。
如果您使用 MirrorMaker 1(作为 AMQ Streams 文档中的 MirrorMaker,使用带有 IdentityReplicationPolicy 的 KafkaMirrorMaker2 自定义资源)。MirrorMaker 2.0 将主题重命名为目标集群。IdentityReplicationPolicy 配置会覆盖自动重命名。使用它生成与 MirrorMaker 1 相同的主动/被动布置复制。
5.4. Cruise Control TLS sidecar 属性
在本发行版本中,Cruise Control TLS sidecar 已被删除。因此,.spec.cruiseControl.tlsSidecar 和 .spec.cruiseControl.template.tlsSidecar 属性现已弃用。属性将被忽略,并将在以后的版本中删除。
5.5. 身份复制策略
身份复制策略与 MirrorMaker 2.0 用于覆盖远程主题的自动重命名。该主题不会用源集群的名称来附加名称,而是保留其原始名称。此可选设置对主动/被动备份和数据迁移很有用。
AMQ Streams Identity Replication Policy 类(io.strimzi.kafka.connect.mirror.IdentityReplicationPolicy)现已弃用,并将在以后的版本中被删除。您可以更新以使用 Kafka 自己的身份复制策略(类 org.apache.kafka.connect.mirror.IdentityReplicationPolicy)。
5.6. ListenerStatus 类型属性
ListenerStatus 的 type 属性已弃用,并将在以后的版本中删除。ListenerStatus 用于指定内部和外部监听程序的地址。现在,地址由 名称 指定,而不使用 类型。
请参阅 ListenerStatus 模式参考。
5.7. Cruise Control 容量配置
磁盘和 cpuUtilization 容量配置属性已弃用,将被忽略,并将在以后删除。属性用于设置优化容量限制,以确定基于资源优化目标是否出现问题。现在,AMQ Streams 会自动生成磁盘和 CPU 容量限制。
请参阅 Cruise Control 配置。
第 6 章 修复的问题
以下小节列出了 AMQ Streams 2.2.x 中修复的问题。红帽建议您升级到最新的补丁版本。
有关 Kafka 3.2.0、3.2.1 和 3.2.3 中修复的问题的详情,请参考 Kafka 3.2.0 发行注记、Kafka 3.2.1 发行注记 和 Kafka 3.2.3 发行注记。
6.1. 修复了 AMQ Streams 2.2.1 的问题
AMQ Streams 2.2.1 补丁发行版本(Long Term Support)现已正式发布。
有关 AMQ Streams 2.2.1 中解决问题的更多详细信息,请参阅 AMQ Streams 2.2.x 解决问题。
6.2. 修复了 AMQ Streams 2.2.0 的问题
表 6.1. 修复的问题
| 问题号 | 描述 |
|---|---|
| [KAFKA] MirrorMaker 2.0 negative lag | |
| "VertxException: Thread blocked" 在 Topic Operator 启动过程中 | |
| 网桥不应同时使用 slf4j-api 和 log4j-api | |
| 改进 KafkaRoller 中的日志记录 | |
| 修复删除 StrimziPodSet 资源的非cascading 删除 | |
| KafkaConnector 资源的协调失败不在 Operator 指标中计数 | |
| 滚动更新在集群启动过程中强制滚动 pod | |
| 添加以 millibyte 单位解析存储的支持 | |
| 当使用无效的存储单元时失败协调 | |
| 避免对 Cruise Control 部署进行不必要的滚动更新 | |
| 缺少注解 ANNO_STRIMZI_IO_CLUSTER_CA_CERT_GENERATION 在 Kafka 协调过程中会导致 CO 日志出现错误 | |
| 当 curl 下载失败时,Kafka Connect Build 应该会失败 | |
| KafkaRebalance 自定义资源中的错误无法正确记录 | |
| 在 AMQ Streams Drain cleaner 中处理 FIPS 模式 | |
| [KAFKA] Unauthenticated 客户端可能会导致代理上的 OutOfMemoryError |
表 6.2. 修复的常见漏洞和风险(CVE)
| 问题号 | 描述 |
|---|---|
| CVE-2020-36518 jackson-databind:通过大量嵌套对象来拒绝服务 | |
| CVE-2022-24823 netty:全局可读的临时文件,包含敏感数据 | |
| CVE-2022-25647 com.google.code.gson: com.google.code.gson: Untrusted Data of com.google.code.gson |
第 7 章 已知问题
本节列出了 OpenShift 中 AMQ Streams 2.2 的已知问题。
7.1. IPv6 集群上的 AMQ Streams Cluster Operator
AMQ Streams Cluster Operator 在 Internet Protocol 版本 6(IPv6)集群中不会启动。
临时解决方案
这个问题有两个临时解决方案。
临时解决方案:设置 KUBERNETES_MASTER 环境变量
显示 OpenShift Container Platform 集群的 Kubernetes master 节点地址:
oc cluster-info Kubernetes master is running at <master_address> # ...复制 master 节点的地址。
列出所有 Operator 订阅:
oc get subs -n <operator_namespace>编辑 AMQ Streams 的
订阅资源:oc edit sub amq-streams -n <operator_namespace>在
spec.config.env中,添加KUBERNETES_MASTER环境变量,设置为 Kubernetes master 节点的地址。例如:apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: amq-streams namespace: <operator_namespace> spec: channel: amq-streams-1.8.x installPlanApproval: Automatic name: amq-streams source: mirror-amq-streams sourceNamespace: openshift-marketplace config: env: - name: KUBERNETES_MASTER value: MASTER-ADDRESS
- 保存并退出编辑器。
检查
订阅是否已更新:oc get sub amq-streams -n <operator_namespace>检查 Cluster Operator
Deployment是否已更新为使用新的环境变量:oc get deployment <cluster_operator_deployment_name>
临时解决方案二:禁用主机名验证
列出所有 Operator 订阅:
oc get subs -n <operator_namespace>编辑 AMQ Streams 的
订阅资源:oc edit sub amq-streams -n <operator_namespace>在
spec.config.env中,添加KUBERNETES_DISABLE_HOSTNAME_VERIFICATION环境变量,设为true。例如:apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: amq-streams namespace: <operator_namespace> spec: channel: amq-streams-1.8.x installPlanApproval: Automatic name: amq-streams source: mirror-amq-streams sourceNamespace: openshift-marketplace config: env: - name: KUBERNETES_DISABLE_HOSTNAME_VERIFICATION value: "true"- 保存并退出编辑器。
检查
订阅是否已更新:oc get sub amq-streams -n <operator_namespace>检查 Cluster Operator
Deployment是否已更新为使用新的环境变量:oc get deployment <cluster_operator_deployment_name>
7.2. Cruise Control CPU 使用率估算
对 AMQ Streams 的 Cruise Control 存在一个已知问题,与计算 CPU 使用率估算相关。CPU 使用率计算为代理 pod 定义的容量的百分比。当在不同 CPU 内核的节点上运行 Kafka 代理时,会出现这个问题。例如,node1 可能有 2 个 CPU 内核数,node2 可能有 4 个 CPU 内核。在这种情况下,Cruise Control 可能会最小化和排除代理的 CPU 负载。问题可在 pod 负载过重时防止集群重新平衡。
临时解决方案
这个问题有两个临时解决方案。
临时解决方案:Equal CPU 请求和限值
您可以在 Kafka.spec.kafka.resources 中设置 CPU 请求等于 CPU 限值。这样,所有 CPU 资源都会预先保留,且始终可用。此配置允许 Cruise Control 在根据 CPU 目标准备重新平衡建议时正确评估 CPU 利用率。
临时解决方案:排除 CPU 目标
您可以从 Cruise Control 配置中指定的硬和默认目标排除 CPU 目标。
没有 CPU 目标的 Cruise Control 配置示例
apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
name: my-cluster
spec:
kafka:
# ...
zookeeper:
# ...
entityOperator:
topicOperator: {}
userOperator: {}
cruiseControl:
brokerCapacity:
inboundNetwork: 10000KB/s
outboundNetwork: 10000KB/s
config:
hard.goals: >
com.linkedin.kafka.cruisecontrol.analyzer.goals.RackAwareGoal,
com.linkedin.kafka.cruisecontrol.analyzer.goals.MinTopicLeadersPerBrokerGoal,
com.linkedin.kafka.cruisecontrol.analyzer.goals.ReplicaCapacityGoal,
com.linkedin.kafka.cruisecontrol.analyzer.goals.DiskCapacityGoal,
com.linkedin.kafka.cruisecontrol.analyzer.goals.NetworkInboundCapacityGoal,
com.linkedin.kafka.cruisecontrol.analyzer.goals.NetworkOutboundCapacityGoal
default.goals: >
com.linkedin.kafka.cruisecontrol.analyzer.goals.RackAwareGoal,
com.linkedin.kafka.cruisecontrol.analyzer.goals.MinTopicLeadersPerBrokerGoal,
com.linkedin.kafka.cruisecontrol.analyzer.goals.ReplicaCapacityGoal,
com.linkedin.kafka.cruisecontrol.analyzer.goals.DiskCapacityGoal,
com.linkedin.kafka.cruisecontrol.analyzer.goals.NetworkInboundCapacityGoal,
com.linkedin.kafka.cruisecontrol.analyzer.goals.NetworkOutboundCapacityGoal,
com.linkedin.kafka.cruisecontrol.analyzer.goals.ReplicaDistributionGoal,
com.linkedin.kafka.cruisecontrol.analyzer.goals.PotentialNwOutGoal,
com.linkedin.kafka.cruisecontrol.analyzer.goals.DiskUsageDistributionGoal,
com.linkedin.kafka.cruisecontrol.analyzer.goals.NetworkInboundUsageDistributionGoal,
com.linkedin.kafka.cruisecontrol.analyzer.goals.NetworkOutboundUsageDistributionGoal,
com.linkedin.kafka.cruisecontrol.analyzer.goals.TopicReplicaDistributionGoal,
com.linkedin.kafka.cruisecontrol.analyzer.goals.LeaderReplicaDistributionGoal,
com.linkedin.kafka.cruisecontrol.analyzer.goals.LeaderBytesInDistributionGoal
如需更多信息,请参阅 Insufficient CPU 容量。
7.3. 用户 Operator 可扩展性
User Operator 可以同时创建多个用户时超时。协调可能需要太长时间。
临时解决方案
如果您遇到这个问题,请减少您要同时创建的用户数量。并等待他们准备就绪,然后再创建更多用户。
第 8 章 支持的与红帽产品集成
AMQ Streams 2.2 支持与以下红帽产品集成:
- 红帽单点登录
- 提供 OAuth 2.0 身份验证和 OAuth 2.0 授权。
- Red Hat 3scale API Management
- 保护 Kafka Bridge 并提供额外的 API 管理功能。
- Red Hat Debezium
- 监控数据库并创建事件流。
- Red Hat Service Registry
- 为数据流提供集中的服务模式存储。
有关这些产品可引入到 AMQ Streams 部署的功能信息,请参阅产品文档。
第 9 章 重要链接
更新于 2023-04-06