OpenShift 上的 AMQ Streams 2.6 发行注记

OpenShift Container Platform 4.11 到 4.14 支持 AMQ Streams 2.6。

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

AMQ Streams 现在支持并使用 Apache Kafka 版本 3.6.0。仅支持由红帽构建的 Kafka 发行版本。

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

如需更多信息，请参阅 Kafka 3.6.0 发行注记。

Kafka 3.5.x 仅支持升级到 AMQ Streams 2.6。

所有自定义资源的 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 版本升级：

StableConnectIdentities 功能门进入 beta 版本的成熟度，现在默认启用。

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

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

env:
  - name: STRIMZI_FEATURE_GATES
    value: -StableConnectIdentities

请参阅 StableConnectIdentities 功能门。

现在，如果代理仍在使用，AMQ Streams 会阻止缩减集群。默认情况下，AMQ Streams 会执行检查，以确保在 Kafka 集群上启动缩减操作前，代理中没有分区副本。如果缩减已被阻止，您必须恢复操作，或者尽快移动 residual 分区，以便 Cluster Operator 可以继续管理集群。

然而，在有些情况下，您可能想要绕过此阻塞机制。例如，在忙碌的集群中禁用检查可能很有用。要做到这一点，您可以通过设置 strimzi.io/skip-broker-scaledown-check="true" 来注解 Kafka 资源。

请参阅 对缩减操作进行跳过检查。

现在，您可以停止 Kafka Connect 或 Kafka MirrorMaker 2 连接器。与暂停状态相比，连接器和任务保持实例化，当只停止连接器的配置但实际上没有运行时。从运行停止连接器可能更适合长时间，而不是只暂停。暂停的连接器会加快恢复速度，但已停止的连接器可以释放内存和资源。

KafkaConnectorSpec 模式和 KafkaMirrorMaker2ConnectorSpec 模式的 pause 属性已弃用。相反，两个模式现在都包含一个新的 state 属性。state 属性允许您配置以下值之一： 运行、暂停 和停止。

例如，如果要停止 Kafka Connect 连接器资源，您可以将 状态更改为 在配置中 停止。

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnector
metadata:
  name: my-source-connector
  labels:
    strimzi.io/cluster: my-connect-cluster
spec:
  class: org.apache.kafka.connect.file.FileStreamSourceConnector
  tasksMax: 2
  config:
    file: "/opt/kafka/LICENSE"
    topic: my-topic
  state: stopped
    # ...

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaMirrorMaker2
metadata:
  name: my-mirror-maker2
spec:
  version: 3.6.0
  replicas: 3
  connectCluster: "my-cluster-target"
  clusters:
    # ...
  mirrors:
  - sourceCluster: "my-cluster-source"
    targetCluster: "my-cluster-target"
    sourceConnector:
      tasksMax: 10
      autoRestart:
        enabled: true
      state: stopped
  # ...

使用以下 REST 端点，Kafka Connect REST API （没有启用 KafkaConnector Operator 时）也支持停止和暂停操作：

PUT /connectors/<connector_name>/resume 请求重启已停止并暂停的连接器。

请参阅 KafkaConnectorSpec 模式参考 和 KafkaMirrorMaker2ConnectorSpec 模式参考。

现在，您可以运行以 KRaft 模式（使用 Kafka Raft 元数据）操作的并行 Kafka 集群，或使用 ZooKeeper 进行集群管理。

因为 KRaft 模式是一个 开发者预览 （开发者预览）,才能在 KRaft 模式下使用集群，您必须执行以下操作：

当启用 UseKRaft 功能门并设置了注解时，Kafka 集群在没有 ZooKeeper 的情况下部署，并以 KRaft 模式运行。如果没有应用这些设置，Cluster Operator 会将 Kafka 资源作为基于 ZooKeeper 的集群进行管理。

要以 KRaft 模式部署 Kafka 集群，现在您必须启用 UseKRaft 和 KafkaNodePools 功能门。作为技术预览，这两个功能都不适用于生产环境。KRaft 模式只支持使用 KafkaNodePool 资源来管理 Kafka 节点的配置。如果使用 KRaft 模式，您可以为节点池中的所有节点指定角色，以作为代理、控制器或两者运行。如果使用 ZooKeeper，您仍然可以使用节点池，但节点只能设置为代理。

请参阅 第 4.1 节 “UseKRaft 功能门”。

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

现在，当主题 Operator 以单向模式运行时(开发人员预览)时，可以暂停 KafkaTopic 资源的协调。要暂停协调，您可以使用 strimzi.io/pause-reconciliation="true" 注解 KafkaTopic 资源。

请参阅 暂停自定义资源的协调。

现在，指标可用于以单向模式运行的主题 Operator (技术预览)。默认情况下，strimzi operator 会自动公开 Prometheus 指标。

除了标准 JVM 指标外，还提供以下自定义指标：

请参阅 介绍指标。

启用 StableConnectIdentities 功能门后，您现在可以触发 Kafka Connect 和 Kafka MirrorMaker 2 pod 的手动滚动更新。

您可以注解 StrimziPodSet 资源，该资源管理您要使用 strimzi.io/manual-rolling-update=true 手动更新的 pod 来执行滚动更新：

oc annotate strimzipodset <cluster_name>-connect strimzi.io/manual-rolling-update=true

oc annotate strimzipodset <cluster_name>-mirrormaker2 strimzi.io/manual-rolling-update=true

或者您可以更新实际的 Pod 资源：

oc annotate pod <cluster_name>-connect-<index_number> strimzi.io/manual-rolling-update=true

oc annotate pod <cluster_name>-mirrormaker2-<index_number> strimzi.io/manual-rolling-update=true

请参阅 使用 pod 管理注解 执行滚动更新，并使用 pod 注解执行滚动更新。

当在 KafkaConnector 或 KafkaMirrorMaker2 自定义资源中启用 auto-restart 功能时，它现在继续无限期重启连接器，而不是在 7 重启后停止。

如果要使用原始行为，请使用 .spec.autoRestart.maxRestarts 选项来配置重启的最大数量。

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnector
metadata:
  name: my-source-connector
  labels:
    strimzi.io/cluster: my-connect-cluster
spec:
  class: org.apache.kafka.connect.file.FileStreamSourceConnector
  tasksMax: 2
  autoRestart:
      enabled: true
      maxRestarts: 7
    # ...

请参阅部署 KafkaConnector 资源 和配置 Kafka MirrorMaker 2。

Cruise Control 中的 CPU 容量现在使用以下优先级顺序的配置值决定，优先级最高的：

这个优先级顺序是决定 Kafka 代理的实际容量限制时需要考虑不同配置值的顺序。例如，特定于代理的覆盖优先于所有代理的容量限制。如果没有指定任何 CPU 容量配置，则 Kafka 代理的默认 CPU 容量被设置为 1 个 CPU 内核。

请参阅 CruiseControlSpec 模式参考。

includeAcceptHeader 配置属性已添加为 OAuth 2.0 服务器端和客户端配置选项。有些授权服务器在客户端发送 Accept: application/json 标头时遇到问题。通过设置 includeAcceptHeader: false，不会发送标头。默认设置为 true。

请参阅为 Kafka 代理配置 OAuth 2.0 支持、为 Kafka 组件配置 OAuth 2.0 支持，以及配置 OAuth 2.0 授权支持。

现在，在 ppc64le (IBM Power)和 s390x (IBM Z 和 IBM® LinuxONE)构架中支持 FIPS。

现在，您可以在 ppc64le (IBM Power)和 s390x (IBM Z 和 IBM® LinuxONE)架构在断开连接的环境中运行 Red Hat OpenShift Container Platform。

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

请参阅配置节点池。

UnidirectionalTopicOperator 功能门引入了单向主题管理模式。使用单向模式，您可以使用 KafkaTopic 资源创建 Kafka 主题，然后由 Topic Operator 管理。此功能门达到 alpha 程度，应被视为技术预览。

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

env:
  - name: STRIMZI_FEATURE_GATES
    value: +UnidirectionalTopicOperator

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

请参阅使用主题 Operator。

使用 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

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

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

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

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

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

AMQ Streams 提供了一个示例连接器配置文件，其中包含部署文件连接器所需的配置作为 KafkaConnector 资源：

请参阅部署示例 KafkaConnector 资源，并使用连接器插件扩展 Kafka 连接。

您可以使用配置供应商为所有 Kafka 组件从外部来源加载配置数据，包括生成者和消费者。

在以前的版本中，您可以使用组件的 spec 配置中的 config.providers 属性启用 secrets.io.strimzi.kafka.EnvVarConfigProvider 环境变量配置供应商。但是，这个供应商现已弃用，并将在以后的版本中删除。因此，建议您更新您的实现以使用 Kafka 自己的环境变量配置供应商(org.apache.kafka.common.config.provider.EnvVarConfigProvider)提供配置属性作为环境变量。

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnect
metadata:
  name: my-connect
  annotations:
    strimzi.io/use-connector-resources: "true"
spec:
  # ...
  config:
    # ...
    config.providers: env
    config.providers.env.class: org.apache.kafka.common.config.provider.EnvVarConfigProvider
  # ...

ListenerStatus 模式中的 type 属性已弃用，不再使用。它已被 name 属性替代。name 属性在 Kafka 资源的状态中提供监听程序的名称。

status:
  clusterId: Y_RJQDGKRXmNF7fEcWldJQ
  conditions:
    - lastTransitionTime: '2023-11-29T14:59:37.113630Z'
      status: 'True'
      type: Ready
  kafkaVersion: 3.6.0
  listeners:
    # ...
    - addresses:
        - host: >-
            a8d4a6fb363bf44...
          port: 9094
      bootstrapServers: >-
        a8d4a6fb363bf447fb6e475...
      certificates:
        - |
          -----BEGIN CERTIFICATE-----

          -----END CERTIFICATE-----
      name: external3
  observedGeneration: 2
  operatorLastSuccessfulVersion: 2.6
 # ...

KafkaConnectorSpec 模式的 pause 属性现已弃用。相反，新的 state 属性允许您选择状态值。

请参阅 第 1.6 节 “支持停止运行连接器”。

UseStrimziPodSets 功能门现已永久启用且无法禁用。因此，不再支持 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 已经替换了 OpenTracing 以进行分布式追踪。

请参阅分布式追踪介绍。

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

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 属性现已弃用。属性将被忽略，并将在以后的版本中删除。

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

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

新的停止连接器的支持 无法在 MirrorMaker 2 中工作，因为状态没有传递给连接器 Operator。这将在 AMQ Streams 的下一个发行版本中解决。

如果 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

如需更多信息，请参阅 Insufficient CPU 容量。

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

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

OpenShift Local 是 Red Hat OpenShift Container Platform (OCP)的一个有限版本。仅用于开发和评估某些功能可能不可用。

AMQ Streams 仅支持由红帽构建的客户端库。目前，AMQ Streams 只提供 Java 客户端库。在以下操作系统和构架中支持在 AMQ Streams 2.6 中使用客户端：

客户端使用 Open JDK 11 和 17 进行测试。IBM JDK 被支持，但不在每个发行版本中定期测试。Open JDK 8、Oracle JDK 8 和 11 和 IBM JDK 8 不被支持。

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

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

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 产品文档。

更新于 2023-12-20