OpenShift 上的 AMQ Streams 2.1 发行注记

Red Hat AMQ Streams 2.1

OpenShift Container Platform 中 AMQ Streams 发行版本的主要新功能及变化信息

摘要

本发行注记概述了 AMQ Streams 2.1 版本中引入的新功能、功能增强和修复。

使开源包含更多

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。我们从这四个术语开始:master、slave、黑名单和白名单。由于此项工作十分艰巨,这些更改将在即将推出的几个发行版本中逐步实施。有关更多详情,请参阅我们的首席技术官 Chris Wright 提供的消息

第 1 章 功能

AMQ Streams 2.1 介绍了本节所述的功能。

AMQ Streams 版本 2.1 基于 Strimzi 0.28.x。

注意

要查看此版本中已解决的所有增强和错误,请查看 AMQ Streams Jira 项目

1.1. OpenShift Container Platform 支持

OpenShift Container Platform 4.6 升级到 4.10 支持 AMQ Streams 2.1。

有关支持的平台版本的更多信息,请参阅 AMQ Streams 支持的配置

1.2. Kafka 3.1.0 支持

AMQ Streams 现在支持 Apache Kafka 版本 3.1.0。

AMQ Streams 使用 Kafka 3.1.0。仅支持由红帽构建的 Kafka 发行版本。

您必须将 Cluster Operator 升级到 AMQ Streams 版本 2.1,然后才能将代理和客户端应用程序升级到 Kafka 3.1.0。有关升级说明,请参阅升级 AMQ Streams

如需更多信息,请参阅 Kafka 3.0.0Kafka 3.1.0 发行注记。

注意

Kafka 3.0.x 仅支持升级到 AMQ Streams 2.1。

有关支持的版本的更多信息,请参阅 AMQ Streams 组件详情

Kafka 3.1.0 需要 ZooKeeper 版本 3.6.3,它与 Kafka 3.0.0 版本相同。因此,当您从 AMQ Streams 2.0 升级到 AMQ Streams 2.1 时,Cluster Operator 不会执行 ZooKeeper 升级。

1.3. 支持 v1beta2 API 版本

所有自定义资源的 v1beta2 API 版本都由 AMQ Streams 1.7 引入。对于 AMQ Streams 1.8、v1alpha1v1beta1 API 版本已从所有 AMQ Streams 自定义资源中删除,除了 KafkaTopicKafkaUser 之外。

将自定义资源升级到 v1beta2 以准备 AMQ Streams 用于迁移到 Kubernetes CRD v1,这是 Kubernetes v1.22 所必需的。

如果您要从 1.7 版本之前的 AMQ Streams 版本升级:

  1. 先升级到 AMQ Streams 1.7
  2. 将自定义资源转换为 v1beta2
  3. 升级到 AMQ Streams 1.8
重要

在升级到 AMQ Streams 版本 2.1 之前,您必须将自定义资源升级到使用 API 版本 v1beta2

请参阅 部署和升级 AMQ Streams

1.3.1. 将自定义资源升级到 v1beta2

为了支持将自定义资源升级到 v1beta2,AMQ Streams 提供了 API 转换工具,您可以从 AMQ Streams 软件下载页面

您可以在两个步骤中执行自定义资源升级。

步骤一:转换自定义资源的格式

使用 API 转换工具,您可以将自定义资源的格式转换为适用于 v1beta2 的格式:

  • 转换描述 AMQ Streams 自定义资源配置的 YAML 文件
  • 在集群中直接转换 AMQ Streams 自定义资源

另外,您可以手动将每个自定义资源转换为适用于 v1beta2 的格式。文档中提供了手动转换自定义资源的说明。

步骤 2:将 CRD 升级到 v1beta2

接下来,在 crd-upgrade 命令中使用 API 转换工具,您必须将 v1beta2 设置为 CRD 中的 storage API 版本。您不能手动执行此步骤。

有关完整说明,请参阅升级 AMQ Streams

1.4. 支持 IBM Z 和 LinuxONE 架构

AMQ Streams 2.1 支持在 IBM Z 和 LinuxONE s390x 架构上运行。

对 IBM Z 和 LinuxONE 的支持适用于在 OpenShift Container Platform 4.10 上运行的 Kafka 3.1.0 的 AMQ Streams。AMQ Streams 2.0 和更早的版本附带的 Kafka 版本不包含 s390x 二进制文件。

1.4.1. IBM Z 和 LinuxONE 的要求

  • OpenShift Container Platform 4.10
  • Kafka 3.1.0

1.4.2. 不支持 IBM Z 和 LinuxONE

  • Kafka 3.0.0 或更早版本
  • AMQ Streams 升级和降级,因为这是 s390x 的第一个发行版本
  • 断开连接的 OpenShift Container Platform 环境中的 AMQ Streams
  • AMQ Streams OPA 集成

1.5. 支持 IBM Power 架构

AMQ Streams 2.1 支持在 IBM Power ppc64le 架构上运行。

对 IBM Power 的支持适用于在 OpenShift Container Platform 4.9 及更新的版本上运行的 Kafka 3.0.0 及之后的版本运行的 AMQ Streams。AMQ Streams 1.8 和更早的版本提供的 Kafka 版本 不包含 ppc64le 二进制文件。

1.5.1. IBM Power 的要求

  • OpenShift Container Platform 4.9 及更新的版本
  • Kafka 3.0.0 及更新的版本

1.5.2. 不支持 IBM Power

  • Kafka 2.8.0 及更早版本
  • 断开连接的 OpenShift Container Platform 环境中的 AMQ Streams

1.6. 自定义 CA 证书的续订

Cluster Operator 现在可以检测用户提供的自定义 CA 证书。当您续订自定义证书时,Cluster Operator 将执行 ZooKeeper、Kafka 和其他组件的滚动更新以信任新的 CA 证书。

如果您使用自己的证书,Cluster Operator 不会自动续订它们。相反,您需要编辑现有的 Secret 来添加新的 CA 证书并更新证书生成注解值。该注解被设置为一个更高的增量值,以便 Cluster Operator 在续订过程中使用最新的证书。

使用新 CA 证书更新的 secret 配置示例

apiVersion: v1
kind: Secret
data:
  ca.crt: GCa6LS3RTHeKFiFDGBOUDYFAZ0F... 1
metadata:
  annotations:
    strimzi.io/ca-cert-generation: "1" 2
  labels:
    strimzi.io/cluster: my-cluster
    strimzi.io/kind: Kafka
  name: my-cluster-cluster-ca-cert
  #...
type: Opaque

1
base64 编码的 CA 证书
2
CA 证书生成注解值

请参阅 续订您自己的 CA 证书

1.7. 用于更改数据捕获集成的 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.8. 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.1 增加了很多改进。

2.1. Kafka 3.1.0 的改进

有关 Kafka 3.1.0 中引入的增强功能概述,请参阅 Kafka 3.1.0 发行注记

2.2. 在启用了 FIPS 的集群中运行 AMQ Streams

现在,您可以在启用了 FIPS 的集群中运行 AMQ Streams,但目前没有在 FIPS 兼容配置中。

AMQ Streams 容器镜像中使用的 OpenJDK 会自动切换到启用了 FIPS 的集群中的 FIPS 模式。这可防止 AMQ Streams 在集群中运行。

要在启用了 FIPS 的集群中运行 AMQ Streams,您可以通过在 Cluster Operator 部署配置中禁用 FIPS_MODE 环境变量来禁用 OpenJDK FIPS 模式。AMQ Streams 部署不兼容 FIPS,但 AMQ Streams operator 及其所有操作对象都可以在启用了 FIPS 的 Kubernetes 集群中运行。

Cluster Operator 的 FIPS 配置示例

apiVersion: apps/v1
kind: Deployment
spec:
  # ...
  template:
    spec:
      serviceAccountName: strimzi-cluster-operator
      containers:
        # ...
        env:
        # ...
        - name: "FIPS_MODE"
          value: "disabled" 1
  # ...

1
禁用 FIPS 模式。

请参阅在 Cluster Operator 中配置 FIPS 模式

2.3. Cruise Control in-broker 磁盘平衡

注意

Cruise Control 仍为技术预览。

如果您正在运行一个使用 JBOD 存储且在同一代理上有多个磁盘的 Kafka 部署,Cruise Control 可以在磁盘间平衡分区。

您可以使用 rebalanceDisk 配置选项。要执行 intra-broker 磁盘平衡,您可以在 KafkaRebalance.spec 下将 rebalanceDisk 设置为 true

请参阅 重新平衡性能调整

2.4. 功能门移至 beta 成熟度

功能门 ControlPlaneListenerServiceAccountPatching 迁移到 beta 成熟度。这意味着它们都默认启用。

测试了测试于测试产品测试的功能门,其功能不太可能改变。

请参阅配置 功能门 和功能增强发行版本

重要

当从或降级到 AMQ Streams 1.7 及更早的版本时,必须禁用 ControlPlaneListener 功能门。

2.5. LoadBalancer Listener bootstrap 服务

新的监听程序配置属性可让您控制是否为 loadBalancer 类型的监听程序创建 bootstrap 服务。Kafka 集群默认创建一个 <cluster_name> -kafka-external-bootstrap bootstrap 服务。您可以通过在监听器配置中将 createBootstrapService 属性设置为 false 来选择为 loadbalancer 创建服务。

没有创建 bootrap 服务的 loadbalancer 外部监听程序配置示例

listeners:
  #...
  - name: external
    port: 9094
    type: loadbalancer
    tls: true
    authentication:
      type: tls
    configuration:
      createBootstrapService: false
      # ...
# ...

请参阅 GenericKafkaListenerConfiguration 模式属性

2.6. OAuth 配置选项

OAuth 身份验证配置中引入了新的 OAuth 配置属性。

与超时和提取组信息相关的属性。

Timout 属性

  • connectTimeoutSeconds 指定在超时前连接到授权服务器的最大时间(以秒为单位)。
  • readTimeoutSeconds 指定超时之前从授权服务器读取的最长时间(以秒为单位)。

默认值为 6ty 秒。

组属性

  • groupsClaim 指定 JsonPath 查询,用于从 JWT 令牌或内省端点响应中提取组信息。默认情况下不设置。
  • groupsClaimDelimiter 指定在返回为单个分隔字符串时解析组信息的分隔符。默认值为 ','(comma)。

Kafka 代理监听程序的 OAuth 配置示例

#...
- name: external
  port: 9094
  type: loadbalancer
  tls: true
  authentication:
    type: oauth
    # ...
    connectTimeoutSeconds: 60
    readTimeoutSeconds: 60
    groupsClaim: "$.groups"
    groupsClaimDelimiter: ","

请参阅 KafkaListenerAuthenticationOAuth 模式参考KafkaClientAuthenticationOAuth 模式属性

第 3 章 技术预览

重要

技术预览功能不被红帽产品服务级别协议(SLA)支持,且可能无法完成。因此,红帽不推荐在生产环境中实施任何技术预览功能。此技术预览功能为您提供对即将推出的产品创新的早期访问,允许您在开发过程中测试并提供反馈。如需有关支持范围的更多信息,请参阅 技术预览功能支持范围

3.1. Kafka 静态配额插件配置

使用 Kafka 静态配额插件在 Kafka 集群中的代理上设置吞吐量和存储限制。您可以通过配置 Kafka 资源来启用插件和设置限制。您可以设置字节阈值和存储配额,以在与代理交互的客户端上放置限制。

Kafka 静态配额插件配置示例

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

请参阅有关使用 Kafka 静态配额插件的代理设置限制

3.2. Cruise Control 用于集群重新平衡

您可以部署 Cruise Control,并使用它在 CPU、磁盘、网络负载等 优化目标 TOKEN 定义限制来重新平衡 Kafka 集群。在均衡 Kafka 集群中,工作负载更加均匀地分布在代理 pod 中。

作为 Kafka 资源的一部分,Tithise Control 被配置和部署。您可以使用默认优化目标或修改它们以符合您的要求。用于 Cruise Control 的 YAML 配置文件示例在 /cruise-control/ 中提供。

当部署了 Cruise Control 时,您可以创建 KafkaRebalance 自定义资源:

  • 从多个优化目标生成优化效果
  • 基于优化建议重新平衡 Kafka 集群

目前不支持其他 Cruise 控制功能,包括异常检测、通知、写入目标以及更改主题复制因素。

请参阅 Cruise Control for cluster 重新平衡

第 4 章 已弃用的功能

本发行版本中弃用的功能,以及之前的 AMQ Streams 版本中所支持的功能如下所示。

4.1. 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。

4.2. 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 ),请将 KafkaMirrorMaker2 自定义资源与 IdentityReplicationPolicy 搭配使用。MirrorMaker 2.0 将复制的主题重命名为目标集群。IdentityReplicationPolicy 配置会覆盖自动重命名。使用它生成与 MirrorMaker 1 相同的主动/被动单向复制。

请参阅 Kafka MirrorMaker 2.0 集群配置

4.3. 身份复制策略

身份复制策略用于 MirrorMaker 2.0 来覆盖远程主题的自动重命名。该主题不会用源集群的名称来附加名称,而是保留其原始名称。此可选设置可用于主动/被动备份和数据迁移。

AMQ Streams Identity Replication Policy 类 (io.strimzi.kafka.connect.mirror.IdentityReplicationPolicy) 现已弃用,并将在以后的发行版本中删除。您可以更新以使用 Kafka 自身的 Identity Replication Policy (class org.apache.kafka.connect.mirror.IdentityReplicationPolicy)。

请参阅 Kafka MirrorMaker 2.0 集群配置

4.4. ListenerStatus 类型属性

ListenerStatustype 属性已被弃用,并将在以后的版本中删除。ListenerStatus 用于指定内部和外部监听器的地址。地址现在通过 name 来指定,而不是使用 type

请参阅 ListenerStatus 模式参考

4.5. 崩溃控制容量配置

磁盘CPUUtilization 容量配置属性已弃用,忽略,并将在以后的版本中删除。该属性用于设置容量限制,以优化方法来确定基于资源的优化目标是否被破坏。现在,AMQ Streams 会自动生成磁盘和 CPU 容量限制。

请参阅 Cruise Control configuration

第 5 章 修复的问题

下表中显示了 AMQ Streams 2.1 中修复的问题。有关 Kafka 3.1.0 中修复的问题的详情,请参考 Kafka 3.1.0 发行注记

问题号描述

ENTMQST-3595

Cluster operator 缺少要传递给 Kafka 网桥的 Java 选项

ENTMQST-3835

当设置了 tasks.max 时,连接器都会在每次协调时重启

ENTMQST-3763

扩展 ZooKeeper 节点时出错

ENTMQST-3422

在启用了 FIPS 的集群中运行失败

ENTMQST-3417

修复 ZooKeeperScaler 中的泄漏密钥存储/信任存储

ENTMQST-3583

Cluster Operator 提供的 JVM 选项会被忽略

ENTMQST-3345

Kafka 升级,带有代理协议和日志消息格式 M.m.p 时失败,并显示误导错误

ENTMQST-3411

kafkaExporter, CruiseControl 和 EntityOperator pod 在客户端 CA 续订时推出

ENTMQST-3325

KafkaMirrorMaker2 条件没有反映 MM2 连接器的状态

ENTMQST-3504

因为 CPU 使用率无效

ENTMQST-3585

将 Java 系统属性传递给 Cruise Control

ENTMQST-3856

机架感知不适用于连接器

ENTMQST-3354

在自定义资源中指定时,在 Kafka Connect Build 中正确设置基础镜像

ENTMQST-3826

/tmp 卷对于压缩库不够大

ENTMQST-3584

当 Kafka 相关命名空间被删除时,strimzi_resources{kind="Kafka"} 指标不会被删除

ENTMQST-3839

在 ZooKeeper 断开连接后,代理会处于不一致的状态

ENTMQST-2331

zookeeper、Kafka 和 EntityOperator 证书没有使用您自己的集群 CA 证书续订

表 5.1. 修复的常见漏洞和风险(CVE)

问题号描述

ENTMQST-2851

CVE-2021-3520 lz4: 内存崩溃,因为 memmove 参数导致的整数溢出错误

ENTMQST-3631

CVE-2021-43797 netty: 控制标头名称中的 chars 可能会导致 HTTP 请求 smuggling

第 6 章 已知问题

本节列出了 AMQ Streams 2.1 的已知问题。

6.1. IPv6 集群上的 AMQ Streams Cluster Operator

AMQ Streams Cluster Operator 不会在互联网协议版本 6 (IPv6)集群中启动。

临时解决方案

这个问题有两个临时解决方案。

临时解决方案:设置 KUBERNETES_MASTER 环境变量

  1. 显示 OpenShift Container Platform 集群的 Kubernetes master 节点地址:

    oc cluster-info
    Kubernetes master is running at <master_address>
    # ...

    复制 master 节点的地址。

  2. 列出所有 Operator 订阅:

    oc get subs -n <operator_namespace>
  3. 编辑 AMQ Streams 的订阅资源 :

    oc edit sub amq-streams -n <operator_namespace>
  4. 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
  5. 保存并退出编辑器。
  6. 检查 订阅 是否已更新:

    oc get sub amq-streams -n <operator_namespace>
  7. 检查 Cluster Operator Deployment 是否已更新为使用新环境变量:

    oc get deployment <cluster_operator_deployment_name>

临时解决方案:禁用主机名验证

  1. 列出所有 Operator 订阅:

    oc get subs -n OPERATOR-NAMESPACE
  2. 编辑 AMQ Streams 的订阅资源 :

    oc edit sub amq-streams -n <operator_namespace>
  3. 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"
  4. 保存并退出编辑器。
  5. 检查 订阅 是否已更新:

    oc get sub amq-streams -n <operator_namespace>
  6. 检查 Cluster Operator Deployment 是否已更新为使用新环境变量:

    oc get deployment <cluster_operator_deployment_name>

6.2. 崩溃控制 CPU 利用率估算

Cruise Control for AMQ Streams 存在一个已知问题,与 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 章 支持的集成产品

AMQ Streams 2.1 支持与以下红帽产品集成。

红帽单点登录
提供 OAuth 2.0 身份验证和 OAuth 2.0 授权。
Red Hat 3scale API Management
保护 Kafka Bridge 并提供额外的 API 管理功能。
Red Hat Debezium
监控数据库并创建事件流。
Red Hat Service Registry
为数据流提供服务架构的集中存储。

有关这些产品可引入您的 AMQ Streams 部署的功能信息,请参阅产品文档。