OpenShift 上的 AMQ Streams 2.5 发行注记

AMQ Streams 2.5.x 是 AMQ Streams 的 Long Term Support (LTS)产品。

最新的补丁版本是 AMQ Streams 2.5.2。AMQ Streams 产品镜像已改为 2.5.2 版本。虽然支持的 Kafka 版本被列为 3.5.0，但它包含了 Kafka 3.5.2 的更新和改进。

有关 LTS 术语和日期的详情，请查看 AMQ Streams LTS 支持策略。

OpenShift Container Platform 4.12 及更新的版本支持 AMQ Streams 2.5。

如需更多信息，请参阅 第 11 章 支持的配置。

AMQ Streams 支持并使用 Apache Kafka 版本 3.5.0。Kafka 3.5.2 的更新会包括在 2.5.2 补丁版本中。仅支持由红帽构建的 Kafka 发行版本。

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

如需了解更多信息，请参阅 Kafka 3.5.0、Kafka 3.5.1 和 Kafka 3.5.2 发行注记。

Kafka 3.4.x 仅支持升级到 AMQ Streams 2.5。

所有自定义资源的 v1beta2 API 版本都由 AMQ Streams 1.7 引入。对于 AMQ Streams 1.8、v1alpha1 和 v1beta1 API 版本已从所有 AMQ Streams 自定义资源中删除，除了 KafkaTopic 和 KafkaUser 之外。

将自定义资源升级到 v1beta2 准备 AMQ Streams 移至 Kubernetes CRD v1，这是 Kubernetes 1.22 所需的。

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

此发行版本引入了 KafkaNodePools 功能门和新的 KafkaNodePool 自定义资源，该资源启用配置不同的 Apache Kafka 节点池。此功能门达到 alpha 成熟度，这意味着它默认是禁用的，应被视为 开发人员预览。

节点池指的是 Kafka 集群中不同的 Kafka 节点组。KafkaNodePool 自定义资源仅代表节点池中的节点的配置。每个池都有自己的唯一的配置，其中包括强制设置，如副本数、存储配置和分配的角色列表。由于您可以为节点池中的节点分配角色，您可以尝试使用 ZooKeeper 进行集群管理或 KRaft 模式的 Kafka 集群的功能。

要启用 KafkaNodePools 功能门，在 Cluster Operator 配置中的 STRIMZI_FEATURE_GATES 环境变量中指定 +KafkaNodePools。

env:
  - name: STRIMZI_FEATURE_GATES
    value: +KafkaNodePools

env:
  - name: STRIMZI_FEATURE_GATES
    value: +KafkaNodePools

请参阅配置节点池。

此发行版本还包含 UnidirectionalTopicOperator 功能门，它引入了一个单向主题管理模式。使用单向模式，您可以使用 KafkaTopic 资源创建 Kafka 主题，然后由 Topic Operator 管理。此功能门达到 alpha 程度，应被视为开发者预览。

要启用 UnidirectionalTopicOperator 功能门，在 Cluster Operator 配置中的 STRIMZI_FEATURE_GATES 环境变量中指定 +UnidirectionalTopicOperator。

env:
  - name: STRIMZI_FEATURE_GATES
    value: +UnidirectionalTopicOperator

env:
  - name: STRIMZI_FEATURE_GATES
    value: +UnidirectionalTopicOperator

对于这个版本，使用 Topic Operator 管理主题的唯一方法是双向模式，它与使用 ZooKeeper 进行集群管理兼容。单向模式不需要 ZooKeeper 用于集群管理，这是 Kafka 移动以使用 KRaft 模式来管理集群的重要开发。

请参阅使用主题 Operator。

report.sh 诊断工具是由红帽提供的脚本，用于收集 OpenShift 上 AMQ Streams 部署故障排除的基本数据。它收集相关的日志、配置文件和其他诊断数据，以帮助识别和解决问题。运行脚本时，您可以使用其他参数来检索特定数据。

该工具需要 OpenShift oc 命令行工具来建立与正在运行的集群的连接。之后，您可以打开终端并运行工具来检索组件中的数据。

在以下请求中，数据会在 Kafka 集群、Kafka Bridge 集群以及 secret 密钥和数据值上收集：

./report.sh --namespace=my-amq-streams-namespace --cluster=my-kafka-cluster --bridge=my-bridge-component --secrets=all --out-dir=~/reports

./report.sh --namespace=my-amq-streams-namespace --cluster=my-kafka-cluster --bridge=my-bridge-component --secrets=all --out-dir=~/reports

数据输出到指定目录。

请参阅 检索诊断和故障排除数据。

OpenTelemetry 用于分布式追踪已变为 GA。您可以在指定的追踪系统中使用 OpenTelemetry。OpenTelemetry 已经替换了 OpenTracing 以进行分布式追踪。对 OpenTracing 的支持已弃用。

默认情况下，OpenTelemetry 使用 OTLP (OpenTelemetry 协议) exporter 进行追踪。带有 OpenTelemetry 的 AMQ Streams 与 Jaeger exporter 一起使用，但您可以指定 OpenTelemetry 支持的其他追踪系统。AMQ Streams 计划默认迁移到使用 OTLP exporter 的 OpenTelemetry，它支持 Jaeger exporter。

请参阅分布式追踪简介。

AMQ Streams 2.5.x 发行版本支持 Kafka 3.5.0。升级到 2.5.2 补丁版本包含来自 Kafka 3.5.2 的更新和改进。

有关 Kafka 3.5.x 中引入的增强功能概述，请参阅 Kafka 3.5.0、Kafka 3.5.1 和 Kafka 3.5.2 发行注记。

UseStrimziPodSets 功能门已移到 GA，这意味着它现已永久启用且无法禁用。

StrimziPodSet 资源现在用于管理 pod，而不是 StatefulSet 资源。这意味着 AMQ Streams 处理 pod 的创建和管理，而不是 OpenShift，从而提供更多对功能的控制。

请参阅 UseStrimziPodSets 功能门 和功能增强发行版本。

要以 KRaft 模式部署 Kafka 集群，现在您必须启用 UseStrimziPodSets 和 KafkaNodePools 功能门。KRaft 模式只支持使用 KafkaNodePool 资源来管理 Kafka 节点的配置。

如需更多信息，请参阅以下：

由 AMQ Streams 提供的 Red Hat Single Sign-On 授权器的 KeycloakRBACAuthorizer 已被 KeycloakAuthorizer 替代。新的授权器与 ZooKeeper 集群管理或 KRaft 模式使用 AMQ Streams 兼容。与前面的授权器一样，您可以使用 Red Hat Single Sign-On 提供的 Authorization Services 的 Red Hat Single Sign-On REST 端点，您可以在 Kafka 代理上配置 KeycloakAuthorizer。使用带有 ZooKeeper 集群管理的 AMQ Streams 时仍可使用 KeycloakRBACAuthorizer，但您应该迁移到新的授权器。

现在，您可以使用其他配置从授权服务器管理 OAuth 2.0 授予。

如果您使用 Red Hat Single Sign-On 进行 OAuth 2.0 授权，您可以在 Kafka 代理的授权配置中添加以下属性：

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    authorization:
      type: keycloak
      tokenEndpointUri: <https://<auth_server_-_address>/auth/realms/external/protocol/openid-connect/token>
      clientId: kafka
      # ...
      grantsMaxIdleSeconds: 300
      grantsGcPeriodSeconds: 300
      grantsAlwaysLatest: false
    #...

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    authorization:
      type: keycloak
      tokenEndpointUri: <https://<auth_server_-_address>/auth/realms/external/protocol/openid-connect/token>
      clientId: kafka
      # ...
      grantsMaxIdleSeconds: 300
      grantsGcPeriodSeconds: 300
      grantsAlwaysLatest: false
    #...

请参阅配置 OAuth 2.0 授权支持。

要在 Kafka 集群中使用 OAuth 2.0 身份验证，您可以使用身份验证方法 oauth 在 Kafka 自定义资源中指定监听程序配置。在配置侦听器属性时，现在可以使用 JsonPath 查询从正在使用的授权服务器中提取用户名。您可以使用 JsonPath 查询来为 userNameClaim 和 fallbackUserNameClaim 属性在侦听器中指定 username extraction 选项。这可让您通过访问嵌套数据结构中的特定值从令牌中提取用户名。例如，您可能有一个包含在 JSON 令牌数据结构中的 user info 数据结构的用户名。

下例演示了如何在使用内省端点配置令牌验证时将 JsonPath 查询与属性搭配使用。

- name: external
  port: 9094
  type: loadbalancer
  tls: true
  authentication:
    type: oauth
    validIssuerUri: <https://<auth-server-address>/auth/realms/external>
    introspectionEndpointUri: <https://<auth-server-address>/auth/realms/external/protocol/openid-connect/token/introspect>
    clientId: kafka-broker
    clientSecret:
      secretName: my-cluster-oauth
      key: clientSecret
    userNameClaim: "['user.info'].['user.id']" 
    maxSecondsWithoutReauthentication: 3600
    fallbackUserNameClaim: "['client.info'].['client.id']" 
    fallbackUserNamePrefix: client-account-
    # ...

- name: external
  port: 9094
  type: loadbalancer
  tls: true
  authentication:
    type: oauth
    validIssuerUri: <https://<auth-server-address>/auth/realms/external>
    introspectionEndpointUri: <https://<auth-server-address>/auth/realms/external/protocol/openid-connect/token/introspect>
    clientId: kafka-broker
    clientSecret:
      secretName: my-cluster-oauth
      key: clientSecret
    userNameClaim: "['user.info'].['user.id']" 

    maxSecondsWithoutReauthentication: 3600
    fallbackUserNameClaim: "['client.info'].['client.id']" 

    fallbackUserNamePrefix: client-account-
    # ...

请参阅 为 Kafka 代理配置 OAuth 2.0 支持。

支持 Kafka Exporter 部署配置引入了新的属性，以便从从 Kafka 代理中提取的指标中排除指定的主题和消费者组。

您可以在 Kafka Exporter 规格中使用以下属性：

在以下示例配置中，两个属性 排除了以前缀 exclude- 开头的主题和消费者组。

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  # ...
  kafkaExporter:
    image: my-registry.io/my-org/my-exporter-cluster:latest
    groupRegex: ".*"
    topicRegex: ".*"
    groupExcludeRegex: "^excluded-.*"
    topicExcludeRegex: "^excluded-.*"
# ...

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  # ...
  kafkaExporter:
    image: my-registry.io/my-org/my-exporter-cluster:latest
    groupRegex: ".*"
    topicRegex: ".*"
    groupExcludeRegex: "^excluded-.*"
    topicExcludeRegex: "^excluded-.*"
# ...

请参阅 KafkaExporterSpec 模式参考。

Kafka Bridge 的最新版本包括以下更改：

请参阅使用 AMQ Streams Kafka Bridge。

使用 Kafka Static Quota 插件的技术预览，在 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

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 静态配额插件的代理设置限制。

要使用 KafkaNodePool 资源来管理 Kafka 节点池的配置，请尝试 KafkaNodePools 功能门。

如需更多信息，请参阅 第 3.5 节 “（预览）用于管理 Kafka 集群中节点节点池”。

要设置 Topic Operator，使其只管理与 KafkaTopic 资源关联的 Kafka 主题，请尝试 UnidirectionalTopicOperator 功能门。

如需更多信息，请参阅 第 3.6 节 “（预览）使用 Topic Operator 的统一方向主题管理”。

要使用 StrimziPodSet 资源来管理 Kafka Connect 和 Kafka MirrorMaker 2 pod，请尝试 StableConnectIdentities 功能门。

StableConnectIdentities 功能门控制使用 StrimziPodSet 资源来管理 Kafka Connect 和 Kafka MirrorMaker 2 pod，而不是使用 OpenShift Deployment 资源。这有助于最小化连接器任务的重新平衡数量。

要启用 StableConnectIdentities 功能门，请指定 +StableConnectIdentities 作为 Cluster Operator 配置中的 STRIMZI_FEATURE_GATES 环境变量的值。

env:
  - name: STRIMZI_FEATURE_GATES
    value: +StableConnectIdentities

env:
  - name: STRIMZI_FEATURE_GATES
    value: +StableConnectIdentities

请参阅 StableConnectIdentities 功能门。

Apache Kafka 处于对 ZooKeeper 的需求。启用新的 UseKRaft 功能门后，您可以尝试在 KRaft (Kafka Raft metadata)模式下部署 Kafka 集群，而无需 ZooKeeper。

要使用 KRaft 模式，还必须使用 KafkaNodePool 资源来管理节点组的配置。要启用 UseKRaft 功能门，请指定 +UseKRaft,+KafkaNodePools 作为 Cluster Operator 配置中的 STRIMZI_FEATURE_GATES 环境变量的值。

env:
  - name: STRIMZI_FEATURE_GATES
    value: +UseKRaft,+KafkaNodePools

env:
  - name: STRIMZI_FEATURE_GATES
    value: +UseKRaft,+KafkaNodePools

目前，AMQ Streams 中的 KRaft 模式有以下主要限制：

请参见以下信息：

Kafka 不再在其 CLASSPATH 和 plugin.path 中包含示例文件连接器 FileStreamSourceConnector 和 FileStreamSinkConnector。AMQ Streams 已更新，您仍然可以使用这些示例连接器。现在，必须将示例添加到插件路径中，如任何连接器。

提供了两个连接器配置文件示例：

请参见以下信息：

AMQ Streams 2.5.x 中弃用了对 RHEL 7 的支持。AMQ Streams 2.5.x (LTS)是支持 RHEL 7 的最后一个 LTS 版本。

在本发行版本中，UseStrimziPodSets 功能门变为 GA，这意味着它现已永久启用且无法禁用。因此，不再支持 StatefulSet 资源来管理 pod。

Kafka 自定义资源(.spec.zookeeper.template.statefulSet 和 .spec.kafka.template.statefulSet.statefulSet)中的 StatefulSet 模板属性已弃用并忽略。您应该从自定义资源中删除它们。

Kafka 3.0.0 和 AMQ Streams 2.0 中已弃用对 Java 8 的支持。AMQ Streams 2.4.0 中删除了对 Java 8 的支持。这适用于所有 AMQ Streams 组件，包括客户端。

AMQ Streams 支持 Java 11 和 Java 17。在开发新应用程序时使用 Java 11 或 17。计划将当前使用 Java 8 的任何应用程序迁移到 Java 11 或 17。

如果您要继续使用 Java 8 一段时间，AMQ Streams 2.2 提供了 Long Term Support (LTS)。有关 LTS 术语和日期的详情，请查看 AMQ Streams LTS 支持策略。

对 type: jaeger tracing 的支持已被弃用。

Jaeger 客户端现已停用，OpenTracing 项目存档。因此，我们不能保证其对将来的 Kafka 版本的支持。我们基于 OpenTelemetry 项目推出新的追踪实施。

用于配置 ACL 规则操作的 operation 属性已弃用。现在，提供了一个使用 operations 属性的新的、更无缝的配置格式。

authorization:
  type: simple
  acls:
    - resource:
        type: topic
        name: my-topic
      operations:
        - Read
        - Describe
        - Create
        - Write

authorization:
  type: simple
  acls:
    - resource:
        type: topic
        name: my-topic
      operations:
        - Read
        - Describe
        - Create
        - Write

使用旧配置格式的 operation 属性已弃用，但仍受支持。

身份复制策略是 MirrorMaker 2 的一个功能，用于覆盖远程主题的自动重命名。主题不会使用源集群的名称添加名称，而是保留其原始名称。此设置对主动/被动备份和数据迁移场景特别有用。

要实现身份复制策略，您必须在 MirrorMaker 2 配置中指定复制策略类(replication.policy.class)。在以前的版本中，您可以指定 AMQ Streams mirror-maker-2-extensions 组件中包含的 io.strimzi.kafka.connect.mirror.IdentityReplicationPolicy 类。但是，这个组件现已弃用，并将在以后的版本中删除。因此，建议您更新您的实现以使用 Kafka 自己的复制策略类(org.apache.kafka.connect.mirror.IdentityReplicationPolicy)。

请参阅配置 Kafka MirrorMaker 2。

Kafka MirrorMaker 在两个或更多活跃 Kafka 集群之间复制数据，并在数据中心之间复制数据。Kafka MirrorMaker 1 在 Kafka 3.0.0 中已弃用，并将在 Kafka 4.0.0 中删除。MirrorMaker 2 将是唯一可用的版本。MirrorMaker 2 基于 Kafka Connect 框架，连接器管理集群之间的数据传输。

因此，用于部署 Kafka MirrorMaker 1 的 AMQ Streams KafkaMirrorMaker 自定义资源已被弃用。当使用 Kafka 4.0.0 时，KafkaMirrorMaker 资源将从 AMQ Streams 中删除。

如果您使用 MirrorMaker 1 （称为 AMQ Streams 文档中的 MirrorMaker ），使用带有 IdentityReplicationPolicy 类的 KafkaMirrorMaker2 自定义资源。MirrorMaker 2 将复制的主题重命名为目标集群。IdentityReplicationPolicy 配置会覆盖自动重命名。使用它生成与 MirrorMaker 1 相同的主动/被动单向复制。

请参阅配置 Kafka MirrorMaker 2。

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

请参阅 ListenerStatus 模式参考。

已删除了 Cruise Control TLS sidecar。因此，.spec.cruiseControl.tlsSidecar 和 .spec.cruiseControl.template.tlsSidecar 属性现已弃用。属性将被忽略，并将在以后的版本中删除。

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

请参阅使用 Kafka 配置和部署 Cruise Control。

AMQ Streams 2.5.2 (Long Term Support)是最新的补丁版本。补丁版本包含 Kafka 3.5.2 更新。

有关 Kafka 3.5.1 和 3.5.2 中修复的问题的详情，请参考 Kafka 3.5.1 和 Kafka 3.5.2 发行注记。

有关 AMQ Streams 2.5.2 中解决问题的更多详细信息，请参阅 AMQ Streams 2.5.x 解决问题。

有关此问题的更多信息，请参阅 Kafka 3.5.2 发行注记。

有关 AMQ Streams 2.5.1 中解决问题的详情，请参阅 AMQ Streams 2.5.x 解决问题。

在 OpenShift Container Platform (OCP)版本 4.16 上部署 Kafka 实例会触发在 Kafka 命名空间中持续创建 dockercfg secret。

此问题是由将 openshift.io/internal-registry-pull-secret-ref 注解添加到服务帐户导致的，这会导致 Apache Kafka 和 OpenShift 的协调循环来重复重写注解。随着时间的推移，这会产生数千种不必要的 secret。

如果无法立即升级，则每个服务帐户手动配置 openshift.io/internal-registry-pull-secret-ref 注解以防止协调循环。

template:
  serviceAccount:
    metadata:
      annotations:
        openshift.io/internal-registry-pull-secret-ref: my-cluster-entity-operator-dockercfg-qxwxd

template:
  serviceAccount:
    metadata:
      annotations:
        openshift.io/internal-registry-pull-secret-ref: my-cluster-entity-operator-dockercfg-qxwxd

如果 Kafka Bridge 启用了 Cross-Origin Resource Sharing (CORS)，则在发送 HTTP 请求以生成消息时会返回一个 400 bad request error。

要使用 CORS，您可以为 Kafka Bridge 部署 Red Hat 3scale。

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

Cruise Control for AMQ Streams 存在一个已知问题，与 CPU 使用率估算的计算相关。CPU 使用率计算为代理 pod 定义容量的百分比。在运行具有不同 CPU 内核的节点中的 Kafka 代理时，会出现这个问题。例如，node1 可能有 2 个 CPU 内核，node2 有 4 个 CPU 内核。在这种情况下，Cruise Control 可能会低估或高估了 CPU 的负载。这个问题可能会在 pod 负载过重时导致集群无法重新平衡。

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

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

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 容量。

当在启用了 JMX 身份验证的 FIPS 模式下运行 AMQ Streams 时，客户端可能会失败。要临时解决这个问题，在以 FIPS 模式运行时不要启用 JMX 身份验证。我们正在调查此问题，并在以后进行解决。

以下平台测试了在 OpenShift 声明版本中使用 Kafka 运行的 AMQ Streams 2.5。

在 AMQ Streams 中，只支持从 Apache Software Foundation 直接发布的以下组件：

另请参阅 第 13 章 支持的与红帽产品集成。

Kafka 需要块存储；NFS 等文件存储选项不兼容。

AMQ Streams 支持通过 Red Hat Single Sign-On Authorization Services 使用基于 OAuth 2.0 令牌的授权，它允许您集中管理安全策略和权限。

如果在 OpenShift Container Platform 上部署了 Kafka Bridge，您可以在 3scale 中使用它。3scale API 管理可以使用 TLS 保护 Kafka Bridge，并提供身份验证和授权。与 3scale 集成还意味着可以使用 metrics、速率限制和计费等额外功能。

有关部署 3scale 的详情，请参考在 AMQ Streams Kafka Bridge 中使用 3scale API 管理。

红帽构建的 Debezium 是一个分布式更改数据捕获平台。它捕获数据库中的行级更改，创建更改事件记录，并将记录流传输到 Kafka 主题。Debezium 基于 Apache Kafka 构建。您可以将红帽构建的 Debezium 与 AMQ Streams 一起部署并集成。部署 AMQ Streams 后，您可以通过 Kafka Connect 将 Debezium 部署为连接器配置。Debezium 将更改事件记录传递到 OpenShift 上的 AMQ Streams。应用程序可以读取 这些更改事件流，并按发生更改事件的顺序访问更改事件。

Debezium 具有多个用途，包括：

Debezium 为以下通用数据库提供连接器（基于 Kafka Connect）：

有关使用 AMQ Streams 部署 Debezium 的更多信息，请参阅 红帽构建的 Debezium 产品文档。

您可以使用红帽构建的 Apicurio Registry 作为数据流的服务架构的集中存储。对于 Kafka，您可以使用红帽构建的 Apicurio Registry 来存储 Apache Avro 或 JSON 模式。

Apicurio Registry 提供 REST API 和 Java REST 客户端，用于通过服务器端端点从客户端应用注册和查询架构。

使用 Apicurio Registry 将管理模式的过程与客户端应用程序配置分离。您可以通过在客户端代码中指定 URL 来启用应用程序从 registry 中使用 schema。

例如，消息序列化和反序列化的架构可以存储在注册表中，后者随后从使用它们的应用程序引用，以确保它们发送和接收的消息与这些模式兼容。

Kafka 客户端应用程序可以在运行时从 Apicurio Registry 中推送或拉取其模式。

有关使用带有 AMQ Streams 的红帽构建的 Apicurio Registry 的更多信息，请参阅 红帽构建的 Apicurio Registry 的产品文档。

红帽构建的 Apache Camel K 是一个轻量级集成框架，从 Apache Camel K 构建，它在 OpenShift 上的云中原生运行。Camel K 支持无服务器集成，允许开发和部署集成任务，而无需管理底层基础架构。您可以使用 Camel K 在 AMQ Streams 环境中构建并集成事件驱动的应用程序。对于在不同系统或数据库之间需要实时数据同步的情况，Camel K 可用于捕获和转换事件的变化，并将其发送到 AMQ Streams 以分发到其他系统。

有关在 AMQ Streams 中使用 Camel K 的更多信息，请参阅 红帽构建的 Apache Camel K 产品文档。

更新于 2024-09-10