在 OpenShift 中配置 AMQ Streams


Red Hat AMQ Streams 2.2

在 OpenShift Container Platform 中配置和管理 AMQ Streams 2.2 的部署

摘要

配置使用 AMQ Streams 部署的 operator 和 Kafka 组件,以构建大规模消息传递网络。

使开源包含更多

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

第 1 章 配置概述

AMQ Streams 简化了在 OpenShift 集群中运行 Apache Kafka 的过程。

本指南介绍了如何配置和管理 AMQ Streams 部署。

1.1. 配置自定义资源

使用自定义资源配置 AMQ Streams 部署。

您可以使用自定义资源配置和创建以下组件的实例:

  • Kafka 集群
  • Kafka Connect 集群
  • Kafka MirrorMaker
  • Kafka Bridge
  • Sything Control

您还可以使用自定义资源配置来管理实例,或修改部署以引入其他功能。这可能包括支持以下的配置:

  • 保护对 Kafka 代理的客户端访问
  • 从集群外部访问 Kafka 代理
  • 创建主题
  • 创建用户(客户端)
  • 控制功能门
  • 更改日志频率
  • 分配资源限值和请求
  • 介绍这些功能,如 AMQ Streams Drain Cleaner、Cruise Control 或 distributed tracing。

自定义资源 API 引用 描述了您可以在配置中使用的属性。

1.2. 配置监听程序以连接到 Kafka 代理

监听器用于连接 Kafka 代理。AMQ Streams 提供了一个通用 GenericKafkaListener 模式,它带有属性来配置通过 Kafka 资源配置监听程序。

GenericKafkaListener 提供了灵活的监听程序配置方法。您可以指定属性来配置用于在 OpenShift 集群内连接的 内部 监听程序,或为在 OpenShift 集群外部连接 的外部 监听程序配置内部监听程序。

每个侦听器都 定义为 Kafka 资源 中的数组。您可以根据需要配置任意数量的监听程序,只要其名称和端口是唯一的。

您可能需要配置多个外部监听器,例如处理需要不同验证机制的网络的访问。或者,您可能需要将 OpenShift 网络加入到外部网络。在这种情况下,您可以配置内部监听程序(使用 useServiceDnsDomain 属性),以便不使用 OpenShift 服务 DNS 域(通常是 .cluster.local)。

有关监听器配置选项的更多信息,请参阅 通用KafkaListener 模式参考

配置监听程序以保证对 Kafka 代理的访问

您可以使用身份验证为安全连接配置监听程序。如需更多信息,请参阅 保护对 Kafka 代理的访问

为 OpenShift 外部的客户端访问配置外部监听程序

您可以使用指定的连接机制(如负载均衡器)为 OpenShift 环境外的客户端访问配置外部监听程序。如需有关连接外部客户端的配置选项的更多信息,请参阅从 OpenShift 集群外部客户端访问 Kafka

侦听器证书

您可以为启用了 TLS 加密的 TLS 监听器或外部监听程序提供自己的服务器证书,称为 Kafka 侦听器证书。如需更多信息,请参阅 Kafka 侦听器证书

注意

如果您在使用外部监听程序时扩展 Kafka 集群,可能会触发所有 Kafka 代理的滚动更新。这取决于配置。

1.3. 文档约定

user-replaced 值

user-replaced 值(也称为 replaceables )在 italics 中带有 angle brackets (< >)。下划线(_)用于多词语值。如果值引用代码或命令,则使用 monospace

例如,在以下代码中,您要将 < my_namespace& gt; 替换为命名空间的名称:

sed -i 's/namespace: .*/namespace: <my_namespace>/' install/cluster-operator/*RoleBinding*.yaml

1.4. 其他资源

第 2 章 在 OpenShift 部署中配置 AMQ Streams

使用自定义资源配置 AMQ Streams 部署。AMQ Streams 提供 示例配置文件,它可在为部署构建自己的 Kafka 组件配置时用作起点。

注意

应用到自定义资源的标签也会应用到 OpenShift 资源,构成其集群。这为要根据需要标记的资源提供了一种方便的机制。

监控 AMQ Streams 部署

您可以使用 Prometheus 和 Grafana 监控 AMQ Streams 部署。如需更多信息,请参阅将指标引入到 Kafka

2.1. 使用标准 Kafka 配置属性

使用标准 Kafka 配置属性配置 Kafka 组件。

属性提供控制和调优以下 Kafka 组件配置的选项:

  • 代理(Broker)
  • 主题
  • 客户端(生产者和消费者)
  • 管理客户端
  • Kafka Connect
  • Kafka Streams

代理和客户端参数包括用于配置授权、身份验证和加密的选项。

注意

对于 OpenShift 上的 AMQ Streams,一些配置属性完全由 AMQ Streams 管理,且无法更改。

有关 Kafka 配置属性以及如何使用属性调整部署的详情,请查看以下指南:

2.2. Kafka 集群配置

本节论述了如何在 AMQ Streams 集群中配置 Kafka 部署。Kafka 集群使用 ZooKeeper 集群部署。部署还可以包括 topics Operator 和 User Operator,用于管理 Kafka 主题和用户。

您可以使用 Kafka 资源配置 Kafka。配置选项也可用于 Kafka 资源中的 ZooKeeper 和 Entity Operator。Entity Operator 包含主题 Operator 和 User Operator。

Kafka 资源的完整 schema 包括在 第 12.2.1 节 “Kafka 模式参考” 中。有关 Apache Kafka 的更多信息,请参阅 Apache Kafka 文档

侦听器配置

您可以配置监听程序,将客户端连接到 Kafka 代理。有关为连接代理配置监听程序的更多信息,请参阅 Listener 配置

授权访问 Kafka

您可以配置 Kafka 集群,以允许或拒绝用户执行的操作。如需更多信息,请参阅 保护对 Kafka 代理的访问

管理 TLS 证书

在部署 Kafka 时,Cluster Operator 会自动设置并更新 TLS 证书,以便在集群中启用加密和身份验证。如果需要,您可以在续订周期结束前手动续订集群和客户端 CA 证书。您还可以替换集群和客户端 CA 证书所使用的密钥。如需更多信息,请参阅 手动更新 CA 证书并替换私钥

2.2.1. 配置 Kafka

使用 Kafka 资源的属性来配置 Kafka 部署。

另外,还可以配置 Kafka,添加 ZooKeeper 和 AMQ Streams Operator 的配置。常见配置属性(如日志记录和健康检查)会为每个组件独立配置。

此过程仅显示一些可能的配置选项,但特别重要的配置选项包括:

  • 资源请求(CPU/内存)
  • 用于最大和最小内存分配的 JVM 选项
  • 监听器(以及客户端的身份验证)
  • 身份验证
  • 存储
  • 机架感知
  • 指标
  • 用于集群重新平衡的 Cruise Control

Kafka 版本

Kafka configinter.broker.protocol.version 属性必须是指定的 Kafka 版本 (spec.kafka.version) 支持的版本。属性表示 Kafka 集群中使用的 Kafka 协议版本。

从 Kafka 3.0.0,当 inter.broker.protocol.version 设置为 3.0 或更高版本时,logging.message.format.version 选项会被忽略,不需要设置。

升级 Kafka 版本时需要对 inter.broker.protocol.version 的更新。如需更多信息,请参阅升级 Kafka

先决条件

  • OpenShift 集群
  • 正在运行的 Cluster Operator

有关部署说明 ,请参阅 OpenShift 中的部署和升级 AMQ Streams 指南:

流程

  1. 编辑 Kafka 资源的 spec 属性。

    您可以在以下示例配置中显示您可以配置的属性:

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    metadata:
      name: my-cluster
    spec:
      kafka:
        replicas: 3 1
        version: 3.2.3 2
        logging: 3
          type: inline
          loggers:
            kafka.root.logger.level: "INFO"
        resources: 4
          requests:
            memory: 64Gi
            cpu: "8"
          limits:
            memory: 64Gi
            cpu: "12"
        readinessProbe: 5
          initialDelaySeconds: 15
          timeoutSeconds: 5
        livenessProbe:
          initialDelaySeconds: 15
          timeoutSeconds: 5
        jvmOptions: 6
          -Xms: 8192m
          -Xmx: 8192m
        image: my-org/my-image:latest 7
        listeners: 8
          - name: plain 9
            port: 9092 10
            type: internal 11
            tls: false 12
            configuration:
              useServiceDnsDomain: true 13
          - name: tls
            port: 9093
            type: internal
            tls: true
            authentication: 14
              type: tls
          - name: external 15
            port: 9094
            type: route
            tls: true
            configuration:
              brokerCertChainAndKey: 16
                secretName: my-secret
                certificate: my-certificate.crt
                key: my-key.key
        authorization: 17
          type: simple
        config: 18
          auto.create.topics.enable: "false"
          offsets.topic.replication.factor: 3
          transaction.state.log.replication.factor: 3
          transaction.state.log.min.isr: 2
          default.replication.factor: 3
          min.insync.replicas: 2
          inter.broker.protocol.version: "3.2"
          ssl.cipher.suites: "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384" 19
          ssl.enabled.protocols: "TLSv1.2"
          ssl.protocol: "TLSv1.2"
        storage: 20
          type: persistent-claim 21
          size: 10000Gi 22
        rack: 23
          topologyKey: topology.kubernetes.io/zone
        metricsConfig: 24
          type: jmxPrometheusExporter
          valueFrom:
            configMapKeyRef: 25
              name: my-config-map
              key: my-key
        # ...
      zookeeper: 26
        replicas: 3 27
        logging: 28
          type: inline
          loggers:
            zookeeper.root.logger: "INFO"
        resources:
          requests:
            memory: 8Gi
            cpu: "2"
          limits:
            memory: 8Gi
            cpu: "2"
        jvmOptions:
          -Xms: 4096m
          -Xmx: 4096m
        storage:
          type: persistent-claim
          size: 1000Gi
        metricsConfig:
          # ...
      entityOperator: 29
        tlsSidecar: 30
          resources:
            requests:
              cpu: 200m
              memory: 64Mi
            limits:
              cpu: 500m
              memory: 128Mi
        topicOperator:
          watchedNamespace: my-topic-namespace
          reconciliationIntervalSeconds: 60
          logging: 31
            type: inline
            loggers:
              rootLogger.level: "INFO"
          resources:
            requests:
              memory: 512Mi
              cpu: "1"
            limits:
              memory: 512Mi
              cpu: "1"
        userOperator:
          watchedNamespace: my-topic-namespace
          reconciliationIntervalSeconds: 60
          logging: 32
            type: inline
            loggers:
              rootLogger.level: INFO
          resources:
            requests:
              memory: 512Mi
              cpu: "1"
            limits:
              memory: 512Mi
              cpu: "1"
      kafkaExporter: 33
        # ...
      cruiseControl: 34
        # ...
    1
    副本节点的数量。如果您的集群已定义了主题,您可以 扩展集群
    2
    Kafka 版本,可按照升级过程 更改为受支持的版本。
    3
    Kafka 日志记录器和日志级别 直接(内联)或通过 ConfigMap 间接添加(外部)。自定义 ConfigMap 必须放在 log4j.properties 键下。对于 Kafka kafka.root.logger.level logger,您可以将日志级别设置为 INFO、ERROR、WARN、WARN、TRACE、DEBAL 或 OFF。
    4
    用于保留 支持的资源、当前 cpu 和内存 的请求,以及指定可消耗的最大资源数量。
    5
    状况检查,了解何时重启容器(持续)以及容器是否可以接受流量(就绪状态)。
    6
    用于优化运行 Kafka 的虚拟机(VM)性能的 JVM 配置选项
    7
    ADVANCED OPTION: 容器镜像配置,这只在特殊情况下建议。
    8
    侦听器配置客户端如何通过 bootstrap 地址连接到 Kafka 集群。监听器 配置为内部外部监听程序,用于从 OpenShift 集群内部或外部 进行连接
    9
    用于标识监听程序的名称。必须在 Kafka 集群中唯一。
    10
    Kafka 内监听器使用的端口号。端口号必须在给定的 Kafka 集群中唯一。允许的端口号为 9092 及更高版本,除了端口 9404 和 9999 除外,后者已用于 Prometheus 和 JMX。根据监听程序类型,端口号可能与连接 Kafka 客户端的端口号不同。
    11
    监听程序类型指定为 internal,或者如果为外部监听程序,指定为 route, loadbalancer, nodeportingress
    12
    为每个监听程序启用 TLS 加密。默认为 false路由 监听器不需要 TLS 加密。
    13
    定义是否分配完全限定的 DNS 名称,包括集群服务后缀(通常为 .cluster.local)。
    14
    15
    16
    由外部证书颁发机构管理的 Kafka 侦听器证书的 可选配置。brokerCertChainAndKey 指定包含服务器证书和私钥的 Secret。您可以在任何使用启用 TLS 加密的监听程序上配置 Kafka 侦听器证书。
    17
    授权 在 Kafka 代理上启用了 simple、OAUTH 2.0 或 OPA 授权。简单授权使用 AclAuthorizer Kafka 插件。
    18
    19
    20
    存储配置为 临时persistent-claimjbod
    21
    22
    永久存储具有额外的配置选项,如用于动态卷调配的存储 idclass
    23
    机架感知 配置,将副本分散到不同的机架、数据中心或可用性区域。topologyKey 必须与包含机架 ID 的节点标签匹配。此配置中使用的示例使用标准 topology.kubernetes.io/zone 标签指定区。
    24
    启用 Prometheus 指标。在本例中,为 Prometheus JMX Exporter 配置指标(默认指标导出器)。
    25
    Prometheus 规则用于通过 Prometheus JMX Exporter 将指标导出到 Grafana 仪表板,并通过引用包含 Prometheus JMX exporter 配置的 ConfigMap 来启用。您可以启用指标,而无需进一步配置,使用对 metricsConfig.valueFrom.configMapKeyRef.key 下包含空文件的 ConfigMap 的引用。
    26
    特定于 zookeeper 的配置,其包含与 Kafka 配置类似的属性。
    27
    ZooKeeper 节点数量。ZooKeeper 集群通常有奇数个节点,一般为三个、五个或七个。大多数节点都必须可用才能保持有效的仲裁。如果 ZooKeeper 集群丢失了仲裁,它将停止对客户端进行响应,并且 Kafka 代理将停止工作。拥有稳定且高度可用的 ZooKeeper 集群对于 AMQ Streams 至关重要。
    28
    29
    30
    实体 Operator TLS sidecar 配置。实体 Operator 使用 TLS sidecar 进行与 ZooKeeper 的安全通信。
    31
    指定 topics Operator 日志记录器和日志级别。这个示例使用 内联 日志记录。
    32
    33
    Kafka 导出器配置.Kafka Exporter 是一个可选组件,用于从 Kafka 代理中提取指标数据。
    34
    Cruise Control 的可选配置,用于 重新平衡 Kafka 集群
  2. 创建或更新资源:

    oc apply -f <kafka_configuration_file>

2.2.2. 配置 Entity Operator

Entity Operator 管理正在运行的 Kafka 集群中与 Kafka 相关的实体。

Entity Operator 包括:

  • 用于管理 Kafka 主题的主题 Operator
  • 用户 Operator 来管理 Kafka 用户

通过 Kafka 资源配置,Cluster Operator 在部署 Kafka 集群时,包括一个或多个 Operator。

Operator 会自动配置为管理 Kafka 集群的主题和用户。主题 Operator 和 User Operator 只能监视单个命名空间。更多信息请参阅 第 6.1 节 “使用 AMQ Streams operator 监视命名空间”

注意

部署之后,实体 Operator pod 会根据部署配置包含 Operator。

2.2.2.1. 实体 Operator 配置属性

使用 Kafka.spec 中的 entityOperator 属性配置 Entity Operator。

entityOperator 属性支持几个子操作:

  • tlsSidecar
  • topicOperator
  • userOperator
  • 模板

tlsSidecar 属性包含 TLS sidecar 容器的配置,用于与 ZooKeeper 进行通信。

template 属性包含 Entity Operator pod 的配置,如标签、注解、关联性和容限。有关配置模板的详情请参考 第 2.8 节 “自定义 OpenShift 资源”

topicOperator 属性包含主题 Operator 的配置。当缺少这个选项时,在没有 Topic Operator 的情况下部署 Entity Operator。

userOperator 属性包含 User Operator 的配置。当缺少这个选项时,在没有用户 Operator 的情况下部署 Entity Operator。

有关配置 Entity Operator 的属性的更多信息,请参阅 EntityUserOperatorSpec 模式参考

启用这两个 Operator 的基本配置示例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
  zookeeper:
    # ...
  entityOperator:
    topicOperator: {}
    userOperator: {}

如果将空对象({})用于 topicOperatoruserOperator,则所有属性都使用它们的默认值。

当缺少 topicOperatoruserOperator 属性时,实体 Operator 不会被部署。

2.2.2.2. 主题 Operator 配置属性

主题 Operator 部署可使用 topicOperator 对象内的附加选项进行配置。支持以下属性:

watchedNamespace
主题 Operator 监视 KafkaTopic 资源的 OpenShift 命名空间。default 是部署 Kafka 集群的命名空间。
reconciliationIntervalSeconds
定期协调间隔(以秒为单位)。默认 120
zookeeperSessionTimeoutSeconds
ZooKeeper 会话超时(以秒为单位)。默认 18
topicMetadataMaxAttempts
从 Kafka 获取主题元数据时的尝试次数。每次尝试之间的时间都定义为 exponential back-off。当主题创建数量或副本的原因可能需要更多时间时,请考虑增大这个值。默认 6
image
image 属性可用于配置要使用的容器镜像。有关配置自定义容器镜像的详情,请参考 第 12.1.6 节 “image
资源
resources 属性配置分配给 Topic Operator 的资源数量。有关资源请求和限制配置的详情,请参阅 第 12.1.5 节 “资源
logging
logging 属性配置 Topic Operator 的日志记录。如需了解更多详细信息,请参阅 第 12.2.45.1 节 “logging

主题 Operator 配置示例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
  zookeeper:
    # ...
  entityOperator:
    # ...
    topicOperator:
      watchedNamespace: my-topic-namespace
      reconciliationIntervalSeconds: 60
    # ...

2.2.2.3. 用户 Operator 配置属性

可以使用 userOperator 对象中的附加选项来配置用户 Operator 部署。支持以下属性:

watchedNamespace
User Operator 监视 KafkaUser 资源的 OpenShift 命名空间。default 是部署 Kafka 集群的命名空间。
reconciliationIntervalSeconds
定期协调间隔(以秒为单位)。默认 120
image
image 属性可用于配置要使用的容器镜像。有关配置自定义容器镜像的详情,请参考 第 12.1.6 节 “image
资源
resources 属性配置分配给 User Operator 的资源数量。有关资源请求和限制配置的详情,请参阅 第 12.1.5 节 “资源
logging
logging 属性配置 User Operator 的日志记录。如需了解更多详细信息,请参阅 第 12.2.45.1 节 “logging
secretPrefix
secretPrefix 属性添加一个前缀到从 KafkaUser 资源创建的所有 Secret 的名称中。例如,secretPrefix: kafka- 会为所有带有 kafka- 的 Secret 名称添加前缀。因此,名为 my-user 的 KafkaUser 创建名为 kafka-my-user 的 Secret。

User Operator 配置示例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
  zookeeper:
    # ...
  entityOperator:
    # ...
    userOperator:
      watchedNamespace: my-user-namespace
      reconciliationIntervalSeconds: 60
    # ...

2.2.3. Kafka 和 ZooKeeper 存储类型

作为有状态应用程序,Kafka 和 ZooKeeper 需要存储数据。AMQ Streams 支持这些数据的三种存储类型:

  • Ephemeral
  • 持久性
  • JBOD 存储
注意

JBOD 存储仅支持 Kafka,不适用于 ZooKeeper。

在配置 Kafka 资源时,您可以指定 Kafka 代理及其对应的 ZooKeeper 节点使用的存储类型。您可以使用以下资源中的 storage 属性配置存储类型:

  • Kafka.spec.kafka
  • Kafka.spec.zookeeper

存储类型在 type 字段中配置。

有关存储配置属性的更多信息,请参阅架构引用:

警告

部署 Kafka 集群后无法更改存储类型。

2.2.3.1. 数据存储注意事项

有效的数据存储基础架构对于 AMQ Streams 的最佳性能至关重要。

块存储是必需的。文件存储(如 NFS)无法用于 Kafka。

从块存储的以下选项之一中选择:

注意

AMQ Streams 不需要 OpenShift 原始块卷。

2.2.3.1.1. 文件系统

Kafka 使用文件系统来存储信息。AMQ Streams 与 XFS 和 ext4 文件系统兼容,它们通常用于 Kafka。选择和设置文件系统时,请考虑部署的底层架构和要求。

如需更多信息,请参阅 Kafka 文档中的 Filesystem Selection

2.2.3.1.2. Apache Kafka 和 ZooKeeper 存储

为 Apache Kafka 和 ZooKeeper 使用单独的磁盘。

支持三种类型的数据存储:

  • Ephemeral (推荐只在开发时使用)
  • 持久性
  • JBOD (Just a Bunch Disks,仅适用于 Kafka)

如需更多信息,请参阅 Kafka 和 ZooKeeper 存储

固态驱动器(SSD)虽然不需要提高数据在从多个主题发送并从多个主题接收的大型集群中的 Kafka 的性能。SSD 特别适用于 ZooKeeper,这需要快速、低延迟数据访问。

注意

您不需要置备复制存储,因为 Kafka 和 ZooKeeper 内置数据复制。

2.2.3.2. 临时存储

临时存储使用 emptyDir 卷来存储数据。要使用临时存储,请将 type 字段设置为 ephemeral

重要

emptyDir 卷不是持久性的,在 pod 重启时,存储数据存储在其中的数据。新 pod 启动后,它必须从集群的其他节点中恢复所有数据。临时存储不适用于单节点 ZooKeeper 集群或带有 1 复制因素的 Kafka 主题。此配置将导致数据丢失。

临时存储示例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    storage:
      type: ephemeral
    # ...
  zookeeper:
    # ...
    storage:
      type: ephemeral
    # ...

2.2.3.2.1. 日志目录

Kafka 代理使用临时卷作为挂载到以下路径的日志目录:

/var/lib/kafka/data/kafka-logIDX

其中 IDX 是 Kafka 代理 pod 索引。例如 /var/lib/kafka/data/kafka-log0

2.2.3.3. 持久性存储

持久性存储使用持久性卷声明 来置备持久性卷来存储数据。持久卷声明可用于调配各种类型的卷,具体取决于要置备卷的存储类。可用于持久性卷声明的数据类型包括许多类型的 SAN 存储以及本地 持久性卷

要使用持久性存储,必须将 type 设置为 persistent-claim。持久性存储支持额外的配置选项:

ID (可选)
存储识别号.对于在 JBOD 存储声明中定义的存储卷,此选项是必需的。默认值为 0。
size (必需)
定义持久性卷声明的大小,如 "1000Gi"。
class (可选)
用于动态卷置备的 OpenShift Storage Class
selector (可选)
允许选择要使用的特定持久性卷。它包含代表选择此类卷的标签的 key:value 对。
deleteClaim (optional)
布尔值值,指定在集群被取消部署时必须删除持久卷声明。默认为 false
警告

只有在 AMQ Streams 集群中增加持久性卷的大小仅在支持持久性卷大小的 OpenShift 版本中被支持。要重新定义持久性卷的大小必须使用支持卷扩展的存储类。对于不支持卷扩展的其他版本的 OpenShift 和存储类,您必须在部署集群前决定必要的存储大小。无法减少现有持久性卷的大小。

具有 1000Gi 大小的持久性存储配置的片段示例

# ...
storage:
  type: persistent-claim
  size: 1000Gi
# ...

以下示例演示了如何使用存储类。

使用特定存储类的持久性存储配置的片段示例

# ...
storage:
  type: persistent-claim
  size: 1Gi
  class: my-storage-class
# ...

最后,可以使用 选择器来 选择特定标记的持久卷,以提供 SSD 等必要功能。

使用选择器的持久性存储配置的片段示例

# ...
storage:
  type: persistent-claim
  size: 1Gi
  selector:
    hdd-type: ssd
  deleteClaim: true
# ...

2.2.3.3.1. 存储类覆盖

您可以为一个或多个 Kafka 代理或 ZooKeeper 节点指定不同的存储类,而不是使用默认存储类。例如,如果存储类仅限于不同的可用区或数据中心,这很有用。您可以使用 overrides 字段来实现这一目的。

在本例中,默认存储类命名为 my-storage-class

使用存储类覆盖的 AMQ Streams 集群示例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  labels:
    app: my-cluster
  name: my-cluster
  namespace: myproject
spec:
  # ...
  kafka:
    replicas: 3
    storage:
      deleteClaim: true
      size: 100Gi
      type: persistent-claim
      class: my-storage-class
      overrides:
        - broker: 0
          class: my-storage-class-zone-1a
        - broker: 1
          class: my-storage-class-zone-1b
        - broker: 2
          class: my-storage-class-zone-1c
  # ...
  zookeeper:
    replicas: 3
    storage:
      deleteClaim: true
      size: 100Gi
      type: persistent-claim
      class: my-storage-class
      overrides:
        - broker: 0
          class: my-storage-class-zone-1a
        - broker: 1
          class: my-storage-class-zone-1b
        - broker: 2
          class: my-storage-class-zone-1c
  # ...

由于配置的 覆盖 属性,卷使用以下存储类:

  • ZooKeeper 节点 0 的持久性卷将使用 my-storage-class-zone-1a
  • ZooKeeper 节点 1 的持久性卷将使用 my-storage-class-zone-1b
  • ZooKeeepr 节点 2 的持久性卷将使用 my-storage-class-zone-1c
  • Kafka 代理 0 的持久性卷将使用 my-storage-class-zone-1a
  • Kafka 代理 1 的持久性卷将使用 my-storage-class-zone-1b
  • Kafka 代理 2 的持久性卷将使用 my-storage-class-zone-1c

overrides 属性目前只用于覆盖存储类配置。目前还不支持覆盖其他存储配置字段。目前还不支持存储配置的其他字段。

2.2.3.3.2. 持久性卷声明命名

当使用持久性存储时,它会使用以下内容创建持久性卷声明:

data-cluster-name-kafka-idx
用于为 Kafka 代理 pod idx 存储数据的卷持久性卷声明。
data-cluster-name-zookeeper-idx
用于存储 ZooKeeper 节点 pod idx 数据的卷的持久性卷声明。
2.2.3.3.3. 日志目录

Kafka 代理使用持久性卷作为挂载到以下路径的日志目录:

/var/lib/kafka/data/kafka-logIDX

其中 IDX 是 Kafka 代理 pod 索引。例如 /var/lib/kafka/data/kafka-log0

2.2.3.4. 重新定义持久性卷大小

您可以通过增加现有 AMQ Streams 集群使用的持久性卷的大小来置备更高的存储容量。集群中支持使用单个持久性卷或 JBOD 存储配置中的多个持久性卷的集群调整持久性卷大小。

注意

您可以增加,但不能缩小持久性卷的大小。OpenShift 当前不支持减少持久性卷的大小。

先决条件

  • 个 OpenShift 集群,支持卷大小调整。
  • Cluster Operator 正在运行。
  • 使用支持卷扩展的存储类创建的持久性卷的 Kafka 集群。

流程

  1. Kafka 资源中,增大分配给 Kafka 集群的持久性卷的大小、ZooKeeper 集群或两者。

    • 要增加分配给 Kafka 集群的卷大小,请编辑 spec.kafka.storage 属性。
    • 要增加分配给 ZooKeeper 集群的卷大小,请编辑 spec.zookeeper.storage 属性。

      例如,将卷的大小从 1000Gi 增加到 2000Gi

      apiVersion: kafka.strimzi.io/v1beta2
      kind: Kafka
      metadata:
        name: my-cluster
      spec:
        kafka:
          # ...
          storage:
            type: persistent-claim
            size: 2000Gi
            class: my-storage-class
          # ...
        zookeeper:
          # ...
  2. 创建或更新资源:

    oc apply -f <kafka_configuration_file>

    OpenShift 增加所选持久性卷的容量,以响应 Cluster Operator 的请求。调整大小完成后,Cluster Operator 会重启所有使用调整大小的持久性卷的 pod。这会自动发生。

其他资源

2.2.3.5. JBOD 存储概述

您可以将 AMQ Streams 配置为使用 JBOD,这是多个磁盘或卷的数据存储配置。JBOD 是为 Kafka 代理提供增加数据存储的方法。它还可以提高性能。

JBOD 配置由一个或多个卷描述,每个卷可以是 临时或 持久的。JBOD 卷声明的规则和约束与用于临时存储的规则和限制相同。例如,在置备后无法缩小持久性存储卷的大小,或者当 type=ephemeral 时无法更改 sizeLimit 的值。

2.2.3.5.1. JBOD 配置

要将 JBOD 与 AMQ Streams 搭配使用,存储类型 必须设置为 jbodvolumes 属性允许您描述组成 JBOD 存储阵列或配置的磁盘。以下片段显示了一个 JBOD 配置示例:

# ...
storage:
  type: jbod
  volumes:
  - id: 0
    type: persistent-claim
    size: 100Gi
    deleteClaim: false
  - id: 1
    type: persistent-claim
    size: 100Gi
    deleteClaim: false
# ...

创建 JBOD 卷后无法更改 ID。

用户可以从 JBOD 配置中添加或删除卷。

2.2.3.5.2. JBOD 和持久性卷声明

当使用持久性存储声明 JBOD 卷时,生成的持久性卷声明的命名方案如下:

data-id-cluster-name-kafka-idx
其中 id 是用于存储 Kafka 代理 pod idx 的数据的卷 ID。
2.2.3.5.3. 日志目录

Kafka 代理将使用 JBOD 卷作为挂载到以下路径的日志目录:

/var/lib/kafka/data-id/kafka-log_idx_
其中 id 是用于存储 Kafka 代理 pod idx 的数据的卷 ID。例如 /var/lib/kafka/data-0/kafka-log0
2.2.3.6. 添加卷到 JBOD 存储

此流程描述了如何将卷添加到配置为使用 JBOD 存储的 Kafka 集群。它不适用于配置为使用任何其他存储类型的 Kafka 集群。

注意

当在过去和移除的 id 下添加新卷时,您必须确保之前使用的 PersistentVolumeClaim 已被删除。

先决条件

  • OpenShift 集群
  • 正在运行的 Cluster Operator
  • 带有 JBOD 存储的 Kafka 集群

流程

  1. 编辑 Kafka 资源中的 spec.kafka.storage.volumes 属性。将新卷添加到 阵列中。例如,添加新卷,其 ID 为 2:

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    metadata:
      name: my-cluster
    spec:
      kafka:
        # ...
        storage:
          type: jbod
          volumes:
          - id: 0
            type: persistent-claim
            size: 100Gi
            deleteClaim: false
          - id: 1
            type: persistent-claim
            size: 100Gi
            deleteClaim: false
          - id: 2
            type: persistent-claim
            size: 100Gi
            deleteClaim: false
        # ...
      zookeeper:
        # ...
  2. 创建或更新资源:

    oc apply -f <kafka_configuration_file>
  3. 创建新主题或将现有分区重新分配给新磁盘。

其他资源

有关重新分配主题的更多信息,请参阅 第 2.2.4.2 节 “分区重新分配工具”

2.2.3.7. 从 JBOD 存储中删除卷

此流程描述了如何从配置为使用 JBOD 存储的 Kafka 集群中删除卷。它不适用于配置为使用任何其他存储类型的 Kafka 集群。JBOD 存储总必须至少包含一个卷。

重要

为了避免数据丢失,您必须在删除卷前移动所有分区。

先决条件

  • OpenShift 集群
  • 正在运行的 Cluster Operator
  • 带有两个或多个卷的 JBOD 存储的 Kafka 集群

流程

  1. 从您要删除的磁盘中分配所有分区。分区中的任何数据仍会分配给要删除的磁盘中的数据可能会丢失。
  2. 编辑 Kafka 资源中的 spec.kafka.storage.volumes 属性。从 volumes 阵列中删除一个或多个卷。例如,删除 ID 为 12 的卷:

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    metadata:
      name: my-cluster
    spec:
      kafka:
        # ...
        storage:
          type: jbod
          volumes:
          - id: 0
            type: persistent-claim
            size: 100Gi
            deleteClaim: false
        # ...
      zookeeper:
        # ...
  3. 创建或更新资源:

    oc apply -f <kafka_configuration_file>

其他资源

有关重新分配主题的更多信息,请参阅 第 2.2.4.2 节 “分区重新分配工具”

2.2.4. 扩展集群

通过添加或删除代理来扩展 Kafka 集群。如果集群已经定义了主题,还必须重新分配分区。

您可以使用 kafka-reassign-partitions.sh 工具重新分配分区。该工具使用一个重新分配 JSON 文件来指定要重新分配主题。

如果要移动特定分区,可以生成重新分配 JSON 文件或手动创建文件。

2.2.4.1. 代理扩展配置

您可以配置 Kafka.spec.kafka.replicas 配置来添加或减少代理数。

代理添加

增加主题吞吐量的主要方法是增加该主题的分区数量。这是因为额外分区允许在集群中的不同代理间共享主题。但是,当每个代理被使用更多分区的特定资源(通常是 I/O)的限制时,则会导致吞吐量增加。反之,您需要将代理添加到集群中。

当您向集群添加额外代理时,Kafka 不会自动为其分配任何分区。您必须决定从现有代理重新分配给新代理的分区。

在所有代理之间重新分布分区后,会减少每个代理的资源使用。

代理删除

如果您使用 StatefulSets 管理代理 pod,则无法从集群中删除 任何 pod。您只能从集群中删除一个或多个最高数量的 pod。例如,在 12 个代理集群中,pod 被命名为 cluster-name-kafka-0 up to cluster-name-kafka-11。如果您决定缩减一个代理,则会删除 cluster-name-kafka-11

从集群中删除代理前,请确保不会将其分配给任何分区。您还应该决定哪些剩余的代理将负责停用代理中的每个分区。代理没有分配的分区后,可以安全地缩减集群。

2.2.4.2. 分区重新分配工具

Topic Operator 目前不支持将副本重新分配给不同的代理,因此需要直接连接到代理 pod 以重新分配给代理 pod。

在代理 pod 中,kafka-reassign-partitions.sh 工具可让您将分区重新分配给不同的代理。

它有三种不同的模式:

--generate
取一组主题和代理,并生成 重新分配 JSON 文件,该文件将导致这些代理所分配给这些主题的分区。由于这在整个主题上运行,因此只有在您只想重新分配一些主题时,无法使用它。
--execute
取一个 重新分配 JSON 文件,并将其应用到集群中的分区和文件系统。获取分区的代理会成为分区的领导者。对于给定分区,当新代理发现并加入 ISR (同步副本)后,旧代理将停止成为后续代理,并将删除其副本。
--verify
使用与 --execute 步骤相同的 重新分配 JSON 文件,-- verify 检查 文件中所有分区是否已移至预期的代理中。如果重新分配完成后,-- verify 也会移除所有生效的流量节流(--throttle)。除非被删除,否则节流将继续影响集群,即使重新分配完成后也是如此。

只能在任何给定时间在集群中运行一个重新分配,且无法取消一个正在运行的重新分配。如果您需要取消重新分配,请等待它完成,然后执行另一个重新分配来还原第一个重新分配的效果。kafka-reassign-partitions.sh 将打印这个 reversion 的重新分配 JSON 作为其输出的一部分。非常大的重新分配应该被分为几个较小的重新分配。

2.2.4.2.1. 分区重新分配 JSON 文件

重新分配 JSON 文件 有特定的结构:

{
  "version": 1,
  "partitions": [
    <PartitionObjects>
  ]
}

其中 <PartitionObjects > 是一个以逗号分隔的对象列表,如下所示:

{
  "topic": <TopicName>,
  "partition": <Partition>,
  "replicas": [ <AssignedBrokerIds> ]
}
注意

虽然 Kafka 还支持 "log_dirs" 属性,但在 AMQ Streams 中不应该使用它。

以下是一个示例重新分配 JSON 文件,它将主题 topic-a 的分区 4 分配给代理 2, 47;主题 topic-b 的分区 2 分配给代理 1, 57

分区重新分配文件示例

{
  "version": 1,
  "partitions": [
    {
      "topic": "topic-a",
      "partition": 4,
      "replicas": [2,4,7]
    },
    {
      "topic": "topic-b",
      "partition": 2,
      "replicas": [1,5,7]
    }
  ]
}

没有包括在 JSON 中的分区不会被更改。

2.2.4.2.2. 分区在 JBOD 卷之间重新分配

在 Kafka 集群中使用 JBOD 存储时,您可以选择重新分配特定卷及其日志目录(每个卷具有单个日志目录)之间的分区。要将分区重新分配给特定卷,请在重新分配 JSON 文件的 < PartitionObjects& gt; 中添加 log_dirs 选项。

{
  "topic": <TopicName>,
  "partition": <Partition>,
  "replicas": [ <AssignedBrokerIds> ],
  "log_dirs": [ <AssignedLogDirs> ]
}

log_dirs 对象应包含与 replicas 对象中指定的副本数相同的日志目录数量。该值应该是日志目录的绝对路径,或者任何 关键字。

指定日志目录的分区重新分配文件示例

{
      "topic": "topic-a",
      "partition": 4,
      "replicas": [2,4,7].
      "log_dirs": [ "/var/lib/kafka/data-0/kafka-log2", "/var/lib/kafka/data-0/kafka-log4", "/var/lib/kafka/data-0/kafka-log7" ]
}

分区重新分配节流

分区重新分配可能会很慢,因为它涉及在代理之间传输大量数据。为了避免对客户端造成负面影响,您可以限制重新分配过程。使用带有 kafka-reassign-partitions.sh 工具的 --throttle 参数来限制重新分配。对于在代理之间移动分区,每秒指定最大阈值(以字节/秒为单位)。例如,-- throttle 5000000 为移动分区设置最大阈值 50 MBps。

节流可能会导致重新分配需要更长的时间来完成。

  • 如果节流太低,则新分配的代理将无法跟上要发布的记录,并且重新分配永远不会完成。
  • 如果节流过高,客户端将会受到影响。

例如,对于生产者而言,这可以比一般延迟等待被确认而大于正常延迟。对于消费者,这可能会以较低的吞吐量的形式进行清单,导致轮询之间的延迟更高。

2.2.4.3. 生成重新分配 JSON 文件

这个步骤描述了如何生成重新分配 JSON 文件。使用带有 kafka-reassign-partitions.sh 工具的重新分配文件,在扩展 Kafka 集群后重新分配分区。

这些步骤描述了使用 TLS 的安全重新分配进程。您需要一个使用 TLS 加密和身份验证的 Kafka 集群。

先决条件

  • 您有一个正在运行的 Cluster Operator。
  • 您有一个正在运行的 Kafka 集群,它基于配置了内部 TLS 身份验证和加密的 Kafka 资源。

    使用 TLS 的 Kafka 配置

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    metadata:
      name: my-cluster
    spec:
      kafka:
        # ...
        listeners:
          # ...
          - name: tls
            port: 9093
            type: internal
            tls: true 1
            authentication:
              type: tls 2
        # ...

    1
    为内部监听程序启用 TLS 加密。
    2
  • 正在运行的 Kafka 集群包含一组要重新分配的主题和分区。

    my-topic的主题配置示例

    apiVersion: kafka.strimzi.io/v1beta2
    kind: KafkaTopic
    metadata:
      name: my-topic
      labels:
        strimzi.io/cluster: my-cluster
    spec:
      partitions: 10
      replicas: 3
      config:
        retention.ms: 7200000
        segment.bytes: 1073741824
        # ...

  • 有一个 KafkaUser 配置了一个 ACL 规则,用于指定从 Kafka 代理生成和使用主题的权限。

    带有 ACL 规则的 Kafka 用户配置示例,允许在 my-topicmy-cluster上执行操作

    apiVersion: kafka.strimzi.io/v1beta2
    kind: KafkaUser
    metadata:
      name: my-user
      labels:
        strimzi.io/cluster: my-cluster
    spec:
      authentication: 1
        type: tls
      authorization:
        type: simple 2
        acls:
          - resource:
              type: topic
              name: my-topic
              patternType: literal
            operation: Write
            host: "*"
          - resource:
              type: topic
              name: my-topic
              patternType: literal
            operation: Create
            host: "*"
          - resource:
              type: topic
              name: my-topic
              patternType: literal
            operation: Describe
            host: "*"
          - resource:
              type: cluster
              name: my-cluster
              patternType: literal
            operation: Alter
            host: "*"
          # ...
      # ...

    1
    用户身份验证机制定义为 mutual tls
    2
    ACL 规则的简单授权和附带列表。
    注意

    需要 描述操作的权限,作为对主题的 TLS 访问的最低权限。

流程

  1. 从 Kafka 集群的 < cluster_name&gt; -cluster-ca-cert Secret 中提取集群 CA 证书和密码。

    oc get secret <cluster_name>-cluster-ca-cert -o jsonpath='{.data.ca\.p12}' | base64 -d > ca.p12
    oc get secret <cluster_name>-cluster-ca-cert -o jsonpath='{.data.ca\.password}' | base64 -d > ca.password

    <cluster_name > 替换为 Kafka 集群的名称。当您使用 Kafka 资源部署 Kafka 时,会使用 Kafka 集群名称( <cluster_name> -cluster-ca-cert )创建带有集群CA 证书的 Secret。例如,my-cluster-cluster-ca-cert

  2. 使用 AMQ Streams Kafka 镜像运行一个新的交互式 pod 容器,以连接到正在运行的 Kafka 代理。

    oc run --restart=Never --image=registry.redhat.io/amq7/amq-streams-kafka-32-rhel8:2.2.2 <interactive_pod_name> -- /bin/sh -c "sleep 3600"

    <interactive_pod_name > 替换为 pod 的名称。

  3. 将集群 CA 证书复制到互动 pod 容器中。

    oc cp ca.p12 <interactive_pod_name>:/tmp
  4. 从可访问 Kafka 代理的 Kafka 用户的 Secret 中提取用户 CA 证书和密码。

    oc get secret <kafka_user> -o jsonpath='{.data.user\.p12}' | base64 -d > user.p12
    oc get secret <kafka_user> -o jsonpath='{.data.user\.password}' | base64 -d > user.password

    <kafka_user > 替换为 Kafka 用户的名称。当使用 KafkaUser 资源创建 Kafka 用户时,会使用 Kafka 用户名创建一个带有用户 CA 证书的 Secret。例如,my-user

  5. 将用户 CA 证书复制到交互式 pod 容器。

    oc cp user.p12 <interactive_pod_name>:/tmp

    CA 证书允许交互式 pod 容器使用 TLS 连接到 Kafka 代理。

  6. 创建 config.properties 文件,以指定用于验证与 Kafka 集群的连接的 truststore 和密钥存储。

    使用您在前面的步骤中提取的证书和密码。

    bootstrap.servers=<kafka_cluster_name>-kafka-bootstrap:9093 1
    security.protocol=SSL 2
    ssl.truststore.location=/tmp/ca.p12 3
    ssl.truststore.password=<truststore_password> 4
    ssl.keystore.location=/tmp/user.p12 5
    ssl.keystore.password=<keystore_password> 6
    1
    连接到 Kafka 集群的 bootstrap 服务器地址。使用您自己的 Kafka 集群名称替换 < kafka_cluster_name>
    2
    使用 TLS 进行加密时的安全协议选项。
    3
    truststore 位置包含 Kafka 集群的公钥证书(ca.p12)。
    4
    用于访问信任存储的密码(ca.password)。
    5
    密钥存储位置包含 Kafka 用户的公钥证书(user.p12)。
    6
    用于访问密钥存储的密码(user.password)。
  7. config.properties 文件复制到交互式 pod 容器中。

    oc cp config.properties <interactive_pod_name>:/tmp/config.properties
  8. 准备名为 topics.json 的 JSON 文件,以指定要移动的主题。

    将主题名称指定为用逗号分开的列表。

    用于重新分配 topic-atopic-b的所有分区的 JSON 文件示例

    {
      "version": 1,
      "topics": [
        { "topic": "topic-a"},
        { "topic": "topic-b"}
      ]
    }

  9. topics.json 文件复制到交互式 pod 容器中。

    oc cp topics.json <interactive_pod_name>:/tmp/topics.json
  10. 在互动 pod 容器中启动 shell 进程。

    oc exec -n <namespace> -ti <interactive_pod_name> /bin/bash

    <namespace > 替换为运行 pod 的 OpenShift 命名空间。

  11. 使用 kafka-reassign-partitions.sh 命令生成重新分配 JSON。

    示例以将 topic-atopic-b 的所有分区移动到代理 012

    bin/kafka-reassign-partitions.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 \
      --command-config /tmp/config.properties \
      --topics-to-move-json-file /tmp/topics.json \
      --broker-list 0,1,2 \
      --generate

2.2.4.4. 扩展 Kafka 集群

使用重新分配文件来增加 Kafka 集群中的代理数。

重新分配文件应描述分区如何重新分配给放大 Kafka 集群中的代理。

这个步骤描述了使用 TLS 的安全扩展过程。您需要一个使用 TLS 加密和身份验证的 Kafka 集群。

先决条件

  • 您有一个正在运行的 Kafka 集群,它基于配置了内部 TLS 身份验证和加密的 Kafka 资源。
  • 您已生成了一个名为 rement .json 的重新分配 JSON 文件。
  • 您要运行一个连接到正在运行的 Kafka 代理的交互式 pod 容器。
  • 您使用 ACL 规则配置的 KafkaUser 连接,指定管理 Kafka 集群及其主题的权限。

请参阅生成 JSON 文件

流程

  1. 通过增加 Kafka.spec.kafka.replicas 配置选项,根据需要添加多个新代理。
  2. 验证新代理 pod 是否已启动。
  3. 如果没有这样做,请运行交互式 pod 容器来生成一个重新分配 JSON 文件,名为 reassignment.json
  4. reassignment.json 文件复制到交互式 pod 容器中。

    oc cp reassignment.json <interactive_pod_name>:/tmp/reassignment.json

    <interactive_pod_name > 替换为 pod 的名称。

  5. 在互动 pod 容器中启动 shell 进程。

    oc exec -n <namespace> -ti <interactive_pod_name> /bin/bash

    <namespace > 替换为运行 pod 的 OpenShift 命名空间。

  6. 使用交互式 pod 容器中的 kafka-reassign-partitions.sh 脚本来重新分配分区。

    bin/kafka-reassign-partitions.sh --bootstrap-server
     <cluster_name>-kafka-bootstrap:9093 \
     --command-config /tmp/config.properties \
     --reassignment-json-file /tmp/reassignment.json \
     --execute

    <cluster_name > 替换为 Kafka 集群的名称。例如: my-cluster-kafka-bootstrap:9093

    如果要节流复制,也可以将 --throttle 选项传递给一个 inter-broker throttled 速率(以每秒字节为单位)。例如:

    bin/kafka-reassign-partitions.sh --bootstrap-server
      <cluster_name>-kafka-bootstrap:9093 \
      --command-config /tmp/config.properties \
      --reassignment-json-file /tmp/reassignment.json \
      --throttle 5000000 \
      --execute

    此命令将输出两个重新分配 JSON 对象。第一个记录所移动分区的当前分配。如果稍后需要恢复重新分配,您应该将其保存到本地文件(而不是 pod 中的文件)。第二个 JSON 对象是您在重新分配 JSON 文件中传递的目标重新分配。

    如果您需要在重新分配时更改节流,您可以使用不同的节流率相同的命令。例如:

    bin/kafka-reassign-partitions.sh --bootstrap-server
      <cluster_name>-kafka-bootstrap:9093 \
      --command-config /tmp/config.properties \
      --reassignment-json-file /tmp/reassignment.json \
      --throttle 10000000 \
      --execute
  7. 验证重新分配已使用来自任何代理 pod 的 kafka-reassign-partitions.sh 命令行工具完成。这与上一步中的命令相同,但使用 --verify 选项而不是 --execute 选项。

    bin/kafka-reassign-partitions.sh --bootstrap-server
      <cluster_name>-kafka-bootstrap:9093 \
      --command-config /tmp/config.properties \
      --reassignment-json-file /tmp/reassignment.json \
      --verify

    --verify 命令报告每个分区都成功完成时,重新分配过程已被重新分配。最后 --verify 还会导致删除任何重新分配节流的效果。

  8. 现在,如果保存了 JSON 以将分配恢复到其原始代理,您可以删除恢复的文件。
2.2.4.5. 缩减 Kafka 集群

使用重新分配文件来减少 Kafka 集群中的代理数。

重新分配文件必须描述如何将分区重新分配给 Kafka 集群中的剩余代理。首先删除最高数量最高的 pod 中的代理。

这个步骤描述了使用 TLS 的安全扩展过程。您需要一个使用 TLS 加密和身份验证的 Kafka 集群。

先决条件

  • 您有一个正在运行的 Kafka 集群,它基于配置了内部 TLS 身份验证和加密的 Kafka 资源。
  • 您已生成了一个名为 rement .json 的重新分配 JSON 文件。
  • 您要运行一个连接到正在运行的 Kafka 代理的交互式 pod 容器。
  • 您使用 ACL 规则配置的 KafkaUser 连接,指定管理 Kafka 集群及其主题的权限。

请参阅生成 JSON 文件

流程

  1. 如果没有这样做,请运行交互式 pod 容器来生成一个重新分配 JSON 文件,名为 reassignment.json
  2. reassignment.json 文件复制到交互式 pod 容器中。

    oc cp reassignment.json <interactive_pod_name>:/tmp/reassignment.json

    <interactive_pod_name > 替换为 pod 的名称。

  3. 在互动 pod 容器中启动 shell 进程。

    oc exec -n <namespace> -ti <interactive_pod_name> /bin/bash

    <namespace > 替换为运行 pod 的 OpenShift 命名空间。

  4. 使用交互式 pod 容器中的 kafka-reassign-partitions.sh 脚本来重新分配分区。

    bin/kafka-reassign-partitions.sh --bootstrap-server
     <cluster_name>-kafka-bootstrap:9093 \
     --command-config /tmp/config.properties \
     --reassignment-json-file /tmp/reassignment.json \
     --execute

    <cluster_name > 替换为 Kafka 集群的名称。例如: my-cluster-kafka-bootstrap:9093

    如果要节流复制,也可以将 --throttle 选项传递给一个 inter-broker throttled 速率(以每秒字节为单位)。例如:

    bin/kafka-reassign-partitions.sh --bootstrap-server
      <cluster_name>-kafka-bootstrap:9093 \
      --command-config /tmp/config.properties \
      --reassignment-json-file /tmp/reassignment.json \
      --throttle 5000000 \
      --execute

    此命令将输出两个重新分配 JSON 对象。第一个记录所移动分区的当前分配。如果稍后需要恢复重新分配,您应该将其保存到本地文件(而不是 pod 中的文件)。第二个 JSON 对象是您在重新分配 JSON 文件中传递的目标重新分配。

    如果您需要在重新分配时更改节流,您可以使用不同的节流率相同的命令。例如:

    bin/kafka-reassign-partitions.sh --bootstrap-server
      <cluster_name>-kafka-bootstrap:9093 \
      --command-config /tmp/config.properties \
      --reassignment-json-file /tmp/reassignment.json \
      --throttle 10000000 \
      --execute
  5. 验证重新分配已使用来自任何代理 pod 的 kafka-reassign-partitions.sh 命令行工具完成。这与上一步中的命令相同,但使用 --verify 选项而不是 --execute 选项。

    bin/kafka-reassign-partitions.sh --bootstrap-server
      <cluster_name>-kafka-bootstrap:9093 \
      --command-config /tmp/config.properties \
      --reassignment-json-file /tmp/reassignment.json \
      --verify

    --verify 命令报告每个分区都成功完成时,重新分配过程已被重新分配。最后 --verify 还会导致删除任何重新分配节流的效果。

  6. 现在,如果保存了 JSON 以将分配恢复到其原始代理,您可以删除恢复的文件。
  7. 当所有分区重新分配完成后,被删除的代理不应该负责集群中的任何分区。您可以通过检查代理的数据日志目录是否包含任何实时分区日志来验证这一点。如果代理上的日志目录包含一个与扩展的正则表达式 \.[a-z0-9]-delete$ 不匹配的目录,则代理仍然具有实时分区,且不应停止。

    您可以通过执行命令来检查这一点:

    oc exec my-cluster-kafka-0 -c kafka -it -- \
      /bin/bash -c \
      "ls -l /var/lib/kafka/kafka-log_<n>_ | grep -E '^d' | grep -vE '[a-zA-Z0-9.-]+\.[a-z0-9]+-delete$'"

    其中 n 是要删除的 pod 的数量。

    如果上述命令打印任何输出,则代理仍然具有实时分区。在这种情况下,重新分配过程没有完成,或者重新分配 JSON 文件不正确。

  8. 当您确认代理没有实时分区时,您可以编辑 Kafka 资源的 Kafka.spec.kafka.replicas 属性来减少代理数量。

2.2.5. 用于滚动更新的维护时间窗

通过维护时间窗口,您可以调度 Kafka 和 ZooKeeper 集群的某些滚动更新,以便在方便的时间启动。

2.2.5.1. 维护时间窗概述

在大多数情况下,Cluster Operator 只更新 Kafka 或 ZooKeeper 集群以响应对应的 Kafka 资源。这可让您在将更改应用到 Kafka 资源时计划,以最小化对 Kafka 客户端应用程序的影响。

但是,如果没有对 Kafka 资源进行任何对应的更改,可能会发生对 Kafka 和 ZooKeeper 集群的一些更新。例如,如果其管理的 CA (Certificate Authority)证书已接近到期,则需要执行滚动重启。

虽然 pod 的滚动重启应该不会影响服务的可用性 (假设正确的代理和主题配置),但它可能会影响 Kafka 客户端应用程序的性能。通过维护时间窗口,您可以调度 Kafka 和 ZooKeeper 集群的启动,以便在方便的时间启动。如果没有为集群配置维护时间窗口,则这种初始滚动更新可能会在高负载的可预测期间发生。

2.2.5.2. 维护时间窗定义

您可以通过在 Kafka.spec.maintenanceTimeWindows 属性中输入字符串数组来配置维护时间窗。每个字符串都是一个 cron 表达式 在 UTC 中(Coordinated Universal Time),其实际用途与 Greenwich Mean Time 相同。

以下示例配置一个维护时间窗,该窗口在午夜开始,于 01:59am (UTC)结束,周日、星期二、星期二、周三和星期四:

# ...
maintenanceTimeWindows:
  - "* * 0-1 ? * SUN,MON,TUE,WED,THU *"
# ...

在实践中,维护窗口应当与 Kafka 资源的 Kafka.spec.clusterCa.renewalDaysKafka.spec.clientsCa.renewalDays 属性一起设置,以确保在配置的维护时间窗口中完成必要的 CA 证书续订。

注意

AMQ Streams 不会根据给定窗口精确调度维护操作。相反,对于每个协调,它会检查维护窗口当前是否"open"。这意味着,在一个给定时间窗内开始维护操作会延迟到 Cluster Operator 协调间隔。因此,维护时间窗口必须至少如此长。

其他资源

2.2.5.3. 配置维护时间窗

您可以为支持的进程触发的滚动更新配置维护时间窗。

先决条件

  • OpenShift 集群。
  • Cluster Operator 正在运行。

流程

  1. Kafka 资源中添加或编辑 maintenanceTimeWindows 属性。例如,允许 0800 到 1059 到 1400 到 1559 之间的维护,您可以设置 maintenanceTimeWindows,如下所示:

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    metadata:
      name: my-cluster
    spec:
      kafka:
        # ...
      zookeeper:
        # ...
      maintenanceTimeWindows:
        - "* * 8-10 * * ?"
        - "* * 14-15 * * ?"
  2. 创建或更新资源:

    oc apply -f <kafka_configuration_file>

其他资源

执行滚动更新:

2.2.6. 从一个终端连接到 ZooKeeper

大多数 Kafka CLI 工具可以直接连接到 Kafka,因此当一般情况下,您不需要连接到 ZooKeeper。zookeeper 服务通过加密和身份验证进行保护,并不能供不属于 AMQ Streams 的外部应用程序使用。

但是,如果要使用需要连接到 ZooKeeper 的 Kafka CLI 工具,您可以使用 ZooKeeper 容器内的终端,并连接到 localhost:12181 作为 ZooKeeper 地址。

先决条件

  • OpenShift 集群可用。
  • Kafka 集群正在运行。
  • Cluster Operator 正在运行。

流程

  1. 使用 OpenShift 控制台打开终端,或者从 CLI 运行 exec 命令。

    例如:

    oc exec -ti my-cluster-zookeeper-0 -- bin/kafka-topics.sh --list --zookeeper localhost:12181

    务必使用 localhost:12181

    现在,您可以在 ZooKeeper 中运行 Kafka 命令。

2.2.7. 手动删除 Kafka 节点

这个步骤描述了如何使用 OpenShift 注解删除现有 Kafka 节点。删除 Kafka 节点包括删除运行 Kafka 代理的 Pod 以及相关的 PersistentVolumeClaim (如果集群已部署了持久性存储)。删除后,Pod 及其相关的 PersistentVolumeClaim 会自动重新创建。

警告

删除 PersistentVolumeClaim 可能会导致持久性数据丢失。只有在遇到存储问题时才会执行以下步骤。

先决条件

有关运行的信息 ,请参阅 OpenShift 中的部署和升级 AMQ Streams 指南:

流程

  1. 查找您要删除的 Pod 的名称。

    Kafka 代理 pod 的名称为 & lt;cluster-name&gt; -kafka-<index & gt;,其中 <index> 从零开始,结尾是 replicas减一总数。例如,my-cluster-kafka-0

  2. 注解 OpenShift 中的 Pod 资源。

    使用 oc annotate:

    oc annotate pod cluster-name-kafka-index strimzi.io/delete-pod-and-pvc=true
  3. 当注解的具有底层持久性卷声明的 pod 被删除后再重新创建时,等待下一次协调。

2.2.8. 手动删除 ZooKeeper 节点

此流程描述了如何使用 OpenShift 注解删除现有 ZooKeeper 节点。删除 ZooKeeper 节点包括删除运行 ZooKeeper 的 Pod 以及相关的 PersistentVolumeClaim (如果集群已部署了持久性存储)。删除后,Pod 及其相关的 PersistentVolumeClaim 会自动重新创建。

警告

删除 PersistentVolumeClaim 可能会导致持久性数据丢失。只有在遇到存储问题时才会执行以下步骤。

先决条件

有关运行的信息 ,请参阅 OpenShift 中的部署和升级 AMQ Streams 指南:

流程

  1. 查找您要删除的 Pod 的名称。

    zookeeper pod 的名称为 < cluster-name>-zookeeper-<index &gt ;,其中 <index > 从零开始,结尾是 replicas minus 总数。例如,my-cluster-zookeeper-0

  2. 注解 OpenShift 中的 Pod 资源。

    使用 oc annotate:

    oc annotate pod cluster-name-zookeeper-index strimzi.io/delete-pod-and-pvc=true
  3. 当注解的具有底层持久性卷声明的 pod 被删除后再重新创建时,等待下一次协调。

2.2.9. Kafka 集群资源列表

以下资源由 OpenShift 集群中的 Cluster Operator 创建:

共享资源

cluster-name-cluster-ca
带有用于加密集群通信的集群 CA 私钥的 secret。
cluster-name-cluster-ca-cert
使用集群 CA 公钥的 secret。这个密钥可以用来验证 Kafka 代理的身份。
cluster-name-clients-ca
带有用于为用户证书签名的客户端 CA 私钥的 secret
cluster-name-clients-ca-cert
使用客户端 CA 公钥的 secret。这个密钥可以用来验证 Kafka 用户的身份。
cluster-name-cluster-operator-certs
带有集群 operator 键与 Kafka 和 ZooKeeper 通信的 secret。

Zookeeper 节点

cluster-name-zookeeper

提供给以下 ZooKeeper 资源的名称:

  • StatefulSet 或 StrimziPodSet (如果启用了 UseStrimziPodSets 功能门 )用于管理 ZooKeeper 节点 Pod。
  • ZooKeeper 节点使用的服务帐户。
  • 为 ZooKeeper 节点配置的 PodDisruptionBudget。
cluster-name-zookeeper-idx
ZooKeeper StatefulSet 或 StrimziPodSet 创建的 Pod。
cluster-name-zookeeper-nodes
无头服务需要使 DNS 直接解析 ZooKeeper pod IP 地址。
cluster-name-zookeeper-client
Kafka 代理使用的服务作为客户端连接到 ZooKeeper 节点。
cluster-name-zookeeper-config
包含 ZooKeeper 辅助配置的 ConfigMap,并被 ZooKeeper 节点 Pod 作为一个卷挂载。
cluster-name-zookeeper-nodes
使用 ZooKeeper 节点键的 secret。
cluster-name-network-policy-zookeeper
网络策略管理对 ZooKeeper 服务的访问。
data-cluster-name-zookeeper-idx
用于存储 ZooKeeper 节点 pod idx 数据的卷的持久性卷声明。只有在为置备持久性卷置备持久性卷选择了持久性存储时,才会创建此资源。

Kafka 代理

cluster-name-kafka

提供给以下 Kafka 资源的名称:

  • StatefulSet 或 StrimziPodSet (如果启用了 UseStrimziPodSets 功能门 )用于管理 Kafka 代理 pod。
  • Kafka pod 使用的服务帐户。
  • 为 Kafka 代理配置的 PodDisruptionBudget。
cluster-name-kafka-idx

提供给以下 Kafka 资源的名称:

  • 由 Kafka StatefulSet 或 StrimziPodSet 创建的 Pod。
  • 带有 Kafka 代理配置的 ConfigMap (如果启用了 UseStrimziPodSets 功能门 )。
cluster-name-kafka-brokers
服务需要 DNS 解析 Kafka 代理 pod IP 地址。
cluster-name-kafka-bootstrap
服务可用作从 OpenShift 集群内部连接的 Kafka 客户端的 bootstrap 服务器。
cluster-name-kafka-external-bootstrap
从 OpenShift 集群外部连接的客户端的 bootstrap 服务。只有在启用外部监听程序时,才会创建此资源。当监听器名称是 外部 并且端口为 9094 时,旧服务名称将用于向后兼容。
cluster-name-kafka-pod-id
用于将流量从 OpenShift 集群外部路由到各个容器集的服务。只有在启用外部监听程序时,才会创建此资源。当监听器名称是 外部 并且端口为 9094 时,旧服务名称将用于向后兼容。
cluster-name-kafka-external-bootstrap
从 OpenShift 集群外部连接的客户端的 bootstrap 路由。只有在启用外部监听器并且设置为类型 路由 时才会创建此资源。当监听器名称是 外部 并且端口为 9094 时,旧路由名称将用于向后兼容。
cluster-name-kafka-pod-id
将来自 OpenShift 集群外的流量路由到各个容器集。只有在启用外部监听器并且设置为类型 路由 时才会创建此资源。当监听器名称是 外部 并且端口为 9094 时,旧路由名称将用于向后兼容。
cluster-name-kafka-listener-name-bootstrap
从 OpenShift 集群外部连接的客户端的 bootstrap 服务。只有在启用外部监听程序时,才会创建此资源。新的服务名称将用于所有其他外部监听程序。
cluster-name-kafka-listener-name-pod-id
用于将流量从 OpenShift 集群外部路由到各个容器集的服务。只有在启用外部监听程序时,才会创建此资源。新的服务名称将用于所有其他外部监听程序。
cluster-name-kafka-listener-name-bootstrap
从 OpenShift 集群外部连接的客户端的 bootstrap 路由。只有在启用外部监听器并且设置为类型 路由 时才会创建此资源。新路由名称将用于所有其他外部监听程序。
cluster-name-kafka-listener-name-pod-id
将来自 OpenShift 集群外的流量路由到各个容器集。只有在启用外部监听器并且设置为类型 路由 时才会创建此资源。新路由名称将用于所有其他外部监听程序。
cluster-name-kafka-config
包含 Kafka 辅助配置的 ConfigMap,并由 Kafka 代理 pod 挂载为卷。
cluster-name-kafka-brokers
带有 Kafka 代理密钥的 secret。
cluster-name-network-policy-kafka
网络策略管理对 Kafka 服务的访问。
strimzi-namespace-name-cluster-name-kafka-init
Kafka 代理使用的集群角色绑定。
cluster-name-jmx
用于保护 Kafka 代理端口的 JMX 用户名和密码的 secret。只有在 Kafka 中启用了 JMX 时,这个资源才会被创建。
data-cluster-name-kafka-idx
用于为 Kafka 代理 pod idx 存储数据的卷持久性卷声明。只有在为置备持久性卷置备持久性卷选择了持久性存储时,才会创建此资源。
data-id-cluster-name-kafka-idx
id 的持久性卷声明用于存储 Kafka 代理 pod idx 的数据。只有在置备持久性卷以存储数据时为 JBOD 卷选择持久性存储时,才会创建此资源。

Entity Operator

只有在使用 Cluster Operator 部署 Entity Operator 时,才会创建这些资源。

cluster-name-entity-operator

提供给以下实体 Operator 资源的名称:

  • 使用主题和用户操作员进行部署.
  • Entity Operator 使用的服务帐户。
cluster-name-entity-operator-random-string
由 Entity Operator 部署创建的 Pod。
cluster-name-entity-topic-operator-config
带有主题 Operator 配置的 ConfigMap。
cluster-name-entity-user-operator-config
使用用户 Operator 的辅助配置 ConfigMap。
cluster-name-entity-topic-operator-certs
带有主题 Operator 密钥用于与 Kafka 和 ZooKeeper 通信的 secret。
cluster-name-entity-user-operator-certs
带有用户 Operator 密钥(用于与 Kafka 和 ZooKeeper 的通信)的 secret。
strimzi-cluster-name-entity-topic-operator
Entity Topic Operator 使用的角色绑定。
strimzi-cluster-name-entity-user-operator
Entity User Operator 使用的角色绑定。

Kafka Exporter

只有在使用 Cluster Operator 部署 Kafka 导出器时才会创建这些资源。

cluster-name-kafka-exporter

提供给以下 Kafka 导出器资源的名称:

  • 使用 Kafka 导出器进行部署。
  • 用于收集消费者 lag 指标的服务。
  • Kafka 导出器使用的服务帐户。
cluster-name-kafka-exporter-random-string
由 Kafka Exporter 部署创建的 Pod。

Sything Control

只有在使用 Cluster Operator 部署有 Cruise Control 时,才会创建这些资源。

cluster-name-cruise-control

给定以下 Cruise 控制资源的名称:

  • 使用 Cruise 控制进行部署.
  • 用于与 Cruise 控制通信的服务。
  • 断路器控制使用的服务帐户。
cluster-name-cruise-control-random-string
由 Cruise Control 部署创建的 Pod。
cluster-name-cruise-control-config
包含 Cruise 控制辅助配置的 ConfigMap,并被 Cruise Control pod 作为一个卷挂载。
cluster-name-cruise-control-certs
带有 Cruise 控制密钥的 secret 用于与 Kafka 和 ZooKeeper 通信。
cluster-name-network-policy-cruise-control
网络策略管理对 Cruise Control 服务的访问。

2.3. Kafka Connect 集群配置

这部分论述了如何在 AMQ Streams 集群中配置 Kafka Connect 部署。

Kafka Connect 是一个使用连接器插件在 Kafka 代理和其他系统间流传输数据的集成工具包。Kafka Connect 提供了一个框架,用于将 Kafka 与外部数据源或目标(如数据库)集成,如数据库,用于使用连接器导入或导出数据。连接器是提供所需的连接配置的插件。KafkaConnect 资源的完整 schema 包括在 第 12.2.59 节 “KafkaConnect 模式参考” 中。

如需有关部署连接器插件的更多信息,请参阅 使用连接器插件扩展 Kafka 连接

2.3.1. 配置 Kafka 连接

使用 Kafka Connect 为 Kafka 集群设置外部数据连接。使用 KafkaConnect 资源的属性来配置 Kafka Connect 部署。

KafkaConnector 配置

KafkaConnector 资源允许您以 OpenShift 原生的方式创建和管理 Kafka Connect 的连接器实例。

在 Kafka Connect 配置中,您可以通过添加 strimzi.io/use-connector-resources 注解来为 Kafka Connect 集群启用 KafkaConnectors。您还可以添加 构建配置,以便 AMQ Streams 使用您数据连接所需的连接器插件自动构建容器镜像。Kafka Connect 连接器的外部配置通过 externalConfiguration 属性指定。

要管理连接器,您可以使用 Kafka Connect REST API,或使用 KafkaConnector 自定义资源。KafkaConnector 资源必须部署到它们所链接的 Kafka Connect 集群相同的命名空间中。有关使用这些方法创建、重新配置或删除连接器的更多信息,请参阅创建和管理连接器

连接器配置作为 HTTP 请求的一部分传递给 Kafka Connect,并存储在 Kafka 本身中。ConfigMap 和机密是用于存储配置和机密数据的标准 OpenShift 资源。您可以使用 ConfigMap 和 Secret 来配置连接器的特定元素。然后,您可以引用 HTTP REST 命令中的配置值,以便在需要时保持独立且更安全的配置。此方法尤其适用于机密数据,如用户名、密码或证书。

处理大量消息

您可以调整配置来处理大量消息。更多信息请参阅 第 2.7 节 “处理大量消息”

先决条件

  • OpenShift 集群
  • 正在运行的 Cluster Operator

有关运行的信息 ,请参阅 OpenShift 中的部署和升级 AMQ Streams 指南:

流程

  1. 编辑 KafkaConnect 资源的 spec 属性。

    您可以在以下示例配置中显示您可以配置的属性:

    apiVersion: kafka.strimzi.io/v1beta2
    kind: KafkaConnect 1
    metadata:
      name: my-connect-cluster
      annotations:
        strimzi.io/use-connector-resources: "true" 2
    spec:
      replicas: 3 3
      authentication: 4
        type: tls
        certificateAndKey:
          certificate: source.crt
          key: source.key
          secretName: my-user-source
      bootstrapServers: my-cluster-kafka-bootstrap:9092 5
      tls: 6
        trustedCertificates:
          - secretName: my-cluster-cluster-cert
            certificate: ca.crt
          - secretName: my-cluster-cluster-cert
            certificate: ca2.crt
      config: 7
        group.id: my-connect-cluster
        offset.storage.topic: my-connect-cluster-offsets
        config.storage.topic: my-connect-cluster-configs
        status.storage.topic: my-connect-cluster-status
        key.converter: org.apache.kafka.connect.json.JsonConverter
        value.converter: org.apache.kafka.connect.json.JsonConverter
        key.converter.schemas.enable: true
        value.converter.schemas.enable: true
        config.storage.replication.factor: 3
        offset.storage.replication.factor: 3
        status.storage.replication.factor: 3
      build: 8
        output: 9
          type: docker
          image: my-registry.io/my-org/my-connect-cluster:latest
          pushSecret: my-registry-credentials
        plugins: 10
          - name: debezium-postgres-connector
            artifacts:
              - type: tgz
                url: https://repo1.maven.org/maven2/io/debezium/debezium-connector-postgres/1.3.1.Final/debezium-connector-postgres-1.3.1.Final-plugin.tar.gz
                sha512sum: 962a12151bdf9a5a30627eebac739955a4fd95a08d373b86bdcea2b4d0c27dd6e1edd5cb548045e115e33a9e69b1b2a352bee24df035a0447cb820077af00c03
          - name: camel-telegram
            artifacts:
              - type: tgz
                url: https://repo.maven.apache.org/maven2/org/apache/camel/kafkaconnector/camel-telegram-kafka-connector/0.7.0/camel-telegram-kafka-connector-0.7.0-package.tar.gz
                sha512sum: a9b1ac63e3284bea7836d7d24d84208c49cdf5600070e6bd1535de654f6920b74ad950d51733e8020bf4187870699819f54ef5859c7846ee4081507f48873479
      externalConfiguration: 11
        env:
          - name: AWS_ACCESS_KEY_ID
            valueFrom:
              secretKeyRef:
                name: aws-creds
                key: awsAccessKey
          - name: AWS_SECRET_ACCESS_KEY
            valueFrom:
              secretKeyRef:
                name: aws-creds
                key: awsSecretAccessKey
      resources: 12
        requests:
          cpu: "1"
          memory: 2Gi
        limits:
          cpu: "2"
          memory: 2Gi
      logging: 13
        type: inline
        loggers:
          log4j.rootLogger: "INFO"
      readinessProbe: 14
        initialDelaySeconds: 15
        timeoutSeconds: 5
      livenessProbe:
        initialDelaySeconds: 15
        timeoutSeconds: 5
      metricsConfig: 15
        type: jmxPrometheusExporter
        valueFrom:
          configMapKeyRef:
            name: my-config-map
            key: my-key
      jvmOptions: 16
        "-Xmx": "1g"
        "-Xms": "1g"
      image: my-org/my-image:latest 17
      rack:
        topologyKey: topology.kubernetes.io/zone 18
      template: 19
        pod:
          affinity:
            podAntiAffinity:
              requiredDuringSchedulingIgnoredDuringExecution:
                - labelSelector:
                    matchExpressions:
                      - key: application
                        operator: In
                        values:
                          - postgresql
                          - mongodb
                  topologyKey: "kubernetes.io/hostname"
        connectContainer: 20
          env:
            - name: JAEGER_SERVICE_NAME
              value: my-jaeger-service
            - name: JAEGER_AGENT_HOST
              value: jaeger-agent-name
            - name: JAEGER_AGENT_PORT
              value: "6831"
    1
    使用 KafkaConnect
    2
    为 Kafka Connect 集群启用 KafkaConnectors。
    3
    运行任务的 worker 的副本数。
    4
    Kafka Connect 集群的身份验证,使用 TLS 机制,如此处所示,使用 OAuth bearer 令牌 或基于 SASL 的 SCRAM-SHA-256/SCRAM-SHA-512PLAIN 机制。默认情况下,Kafka Connect 使用纯文本连接连接到 Kafka 代理。
    5
    连接到 Kafka Connect 集群的 bootstrap 服务器
    6
    TLS 加密,使用密钥名称,其中 TLS 证书存储为集群的 X.509 格式。如果证书存储在同一 secret 中,可以多次列出它。
    7
    worker 的 Kafka 连接配置 (而非连接器)。可以提供标准 Apache Kafka 配置,仅限于不直接由 AMQ Streams 管理的属性。
    8
    构建配置属性,以使用连接器插件构建容器镜像。
    9
    (必需)推送新镜像的容器注册表的配置。
    10
    (必需)连接器插件列表及其要添加到新容器镜像的工件。每个插件必须至少配置一个 工件
    11
    Kafka 连接器的外部配置,如此处所示或卷。您还可以使用 配置供应商插件 从外部源 加载配置值
    12
    用于保留 支持的资源、当前 cpu 和内存 的请求,以及指定可消耗的最大资源数量。
    13
    指定的 Kafka Connect 日志记录器和日志级别 直接(内联)或通过 ConfigMap 间接添加(外部)。自定义 ConfigMap 必须放在 log4j.propertieslog4j2.properties 键下。对于 Kafka Connect log4j.rootLogger 日志记录器,您可以将日志级别设置为 INFO、ERROR、WARN、WARN、TRACE、DEBUG、FATAL 或 OFF。
    14
    状况检查,了解何时重启容器(持续)以及容器是否可以接受流量(就绪状态)。
    15
    Prometheus metrics,通过引用本例中的 Prometheus JMX JMX exporter 配置的 ConfigMap 来启用。您可以启用指标,而无需进一步配置,使用对 metricsConfig.valueFrom.configMapKeyRef.key 下包含空文件的 ConfigMap 的引用。
    16
    JVM 配置选项,用于优化运行 Kafka Connect 的虚拟机(VM)的性能。
    17
    ADVANCED OPTION: 容器镜像配置,这只在特殊情况下建议。
    18
    SPECIALIZED OPTION :对部署的意识 配置.这是用于在同一位置(而非跨地区)部署的专用选项。如果您希望连接器从最接近的副本而不是领导副本使用,则使用此选项。在某些情况下,消耗自最接近的副本可以提高网络利用率或降低成本。topologyKey 必须与包含机架 ID 的节点标签匹配。此配置中使用的示例使用标准 topology.kubernetes.io/zone 标签指定区。要从最接近的副本使用,请在 Kafka 代理配置中启用 RackAwareReplicaSelector
    19
    模板自定义。这里调度了带有反关联性的 pod,因此不会将 pod 调度到具有相同主机名的节点。
    20
    还使用 Jaeger 为分布式追踪 设置环境变量。
  2. 创建或更新资源:

    oc apply -f KAFKA-CONNECT-CONFIG-FILE
  3. 如果为 Kafka Connect 启用了授权,请配置 Kafka Connect Connect 用户以启用对 Kafka Connect consumer 组和主题的访问

2.3.2. 多个实例的 Kafka 连接配置

如果您运行多个 Kafka Connect 实例,您必须更改以下配置属性 的默认配置

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnect
metadata:
  name: my-connect
spec:
  # ...
  config:
    group.id: connect-cluster 1
    offset.storage.topic: connect-cluster-offsets 2
    config.storage.topic: connect-cluster-configs 3
    status.storage.topic: connect-cluster-status  4
    # ...
# ...
1
Kafka 中的 Kafka Connect 集群 ID。
2
存储连接器偏移的 Kafka 主题。
3
存储连接器和任务状态配置的 Kafka 主题。
4
存储连接器和任务状态更新的 Kafka 主题。
注意

这三个主题的值对于具有相同 组.id 的所有 Kafka 连接实例必须相同。

除非更改默认设置,否则每个 Kafka 连接实例都使用相同的值部署连接到同一 Kafka 集群。这是因为所有实例都联合在集群中运行,并使用相同的主题。

如果多个 Kafka Connect 集群尝试使用相同主题,则 Kafka Connect 将无法按预期工作,并生成错误。

如果要运行多个 Kafka Connect 实例,请更改每个实例的这些属性值。

2.3.3. 配置 Kafka Connect 用户授权

这个步骤描述了如何授权用户对 Kafka 连接的访问。

当在 Kafka 中使用任何类型的授权时,Kafka Connect 用户需要对使用者组和 Kafka Connect 的内部主题进行读/写访问权限。

consumer 组和内部主题的属性由 AMQ Streams 自动配置,也可以在 KafkaConnect 资源的 spec 中明确指定。

KafkaConnect 资源中的配置属性示例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnect
metadata:
  name: my-connect
spec:
  # ...
  config:
    group.id: my-connect-cluster 1
    offset.storage.topic: my-connect-cluster-offsets 2
    config.storage.topic: my-connect-cluster-configs 3
    status.storage.topic: my-connect-cluster-status 4
    # ...
  # ...

1
Kafka 中的 Kafka Connect 集群 ID。
2
存储连接器偏移的 Kafka 主题。
3
存储连接器和任务状态配置的 Kafka 主题。
4
存储连接器和任务状态更新的 Kafka 主题。

此流程演示了如何在 使用简单 授权时提供访问权限。

简单授权使用由 Kafka AclAuthorizer 插件处理的 ACL 规则来提供正确的访问权限级别。有关配置 KafkaUser 资源以使用简单授权的更多信息,请参阅 AclRule 模式参考

注意

先决条件

  • OpenShift 集群
  • 正在运行的 Cluster Operator

流程

  1. 编辑 KafkaUser 资源中的 authorization 属性,以为用户提供访问权限。

    在以下示例中,使用 字面 名称值为 Kafka Connect 主题和消费者组配置访问权限:

    属性名称

    offset.storage.topic

    connect-cluster-offsets

    status.storage.topic

    connect-cluster-status

    config.storage.topic

    connect-cluster-configs

    group

    connect-cluster

    apiVersion: kafka.strimzi.io/v1beta2
    kind: KafkaUser
    metadata:
      name: my-user
      labels:
        strimzi.io/cluster: my-cluster
    spec:
      # ...
      authorization:
        type: simple
        acls:
          # access to offset.storage.topic
          - resource:
              type: topic
              name: connect-cluster-offsets
              patternType: literal
            operation: Write
            host: "*"
          - resource:
              type: topic
              name: connect-cluster-offsets
              patternType: literal
            operation: Create
            host: "*"
          - resource:
              type: topic
              name: connect-cluster-offsets
              patternType: literal
            operation: Describe
            host: "*"
          - resource:
              type: topic
              name: connect-cluster-offsets
              patternType: literal
            operation: Read
            host: "*"
          # access to status.storage.topic
          - resource:
              type: topic
              name: connect-cluster-status
              patternType: literal
            operation: Write
            host: "*"
          - resource:
              type: topic
              name: connect-cluster-status
              patternType: literal
            operation: Create
            host: "*"
          - resource:
              type: topic
              name: connect-cluster-status
              patternType: literal
            operation: Describe
            host: "*"
          - resource:
              type: topic
              name: connect-cluster-status
              patternType: literal
            operation: Read
            host: "*"
          # access to config.storage.topic
          - resource:
              type: topic
              name: connect-cluster-configs
              patternType: literal
            operation: Write
            host: "*"
          - resource:
              type: topic
              name: connect-cluster-configs
              patternType: literal
            operation: Create
            host: "*"
          - resource:
              type: topic
              name: connect-cluster-configs
              patternType: literal
            operation: Describe
            host: "*"
          - resource:
              type: topic
              name: connect-cluster-configs
              patternType: literal
            operation: Read
            host: "*"
          # consumer group
          - resource:
              type: group
              name: connect-cluster
              patternType: literal
            operation: Read
            host: "*"
  2. 创建或更新资源。

    oc apply -f KAFKA-USER-CONFIG-FILE

2.3.4. Kafka Connect 集群资源列表

以下资源由 OpenShift 集群中的 Cluster Operator 创建:

connect-cluster-name-connect
用于创建 Kafka Connect worker 节点 pod 的部署。
connect-cluster-name-connect-api
此服务公开了管理 Kafka Connect 集群的 REST 接口。
connect-cluster-name-config
包含 Kafka Connect ancillary 配置的 ConfigMap,并由 Kafka 代理 pod 挂载为卷。
connect-cluster-name-connect
为 Kafka Connect worker 节点配置的 Pod Disruption Budget。

2.3.5. 与 Debezium 集成以更改数据捕获

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

Debezium 具有多个用途,包括:

  • 数据复制
  • 更新缓存和搜索索引
  • 简化单体式应用程序
  • 数据集成
  • 启用流查询

要捕获数据库更改,请使用 Debezium 数据库连接器部署 Kafka 连接。您可以配置 KafkaConnector 资源来定义连接器实例。

有关使用 AMQ Streams 部署 Debezium 的更多信息,请参阅 产品文档。Debezium 文档包括了 使用 Debezium 的入门指南,指导您完成设置服务的流程以及查看数据库更新更改事件记录所需的连接器。

2.4. Kafka MirrorMaker 集群配置

本章论述了如何在 AMQ Streams 集群中配置 Kafka MirrorMaker 部署,以便在 Kafka 集群间复制数据。

您可以使用带有 MirrorMaker 或 MirrorMaker 2.0 的 AMQ Streams。MirrorMaker 2.0 是最新版本,提供在 Kafka 集群间镜像数据更为有效的方法。

如果使用 MirrorMaker,请配置 KafkaMirrorMaker 资源。

重要

在 Apache Kafka 3.0.0 中已弃用 Kafka MirrorMaker 1 (正如文档中的 imagesMaker),并将在 Apache Kafka 4.0.0 中删除。因此,在 AMQ Streams 中还已弃用了用于部署 Kafka MirrorMaker 1 的 KafkaMirrorMaker 自定义资源。当使用 Apache Kafka 4.0.0 时,KafkaMirrorMaker 资源将从 AMQ Streams 中删除。作为替代方法,在 IdentityReplicationPolicy 中使用 KafkaMirrorMaker2 自定义资源。

以下步骤演示了如何配置资源:

KafkaMirrorMaker 资源的完整 schema 在 KafkaMirrorMaker 模式中描述。

2.4.1. 配置 Kafka MirrorMaker

使用 KafkaMirrorMaker 资源的属性来配置 Kafka MirrorMaker 部署。

您可以使用 TLS 或 SASL 身份验证为制作者和使用者配置访问控制。此流程演示了在使用者和生产端使用 TLS 加密和解密的配置。

先决条件

  • 有关运行的信息 ,请参阅 OpenShift 中的部署和升级 AMQ Streams 指南:

  • 源和目标集群必须可用

流程

  1. 编辑 KafkaMirrorMaker 资源的 spec 属性。

    您可以在以下示例配置中显示您可以配置的属性:

    apiVersion: kafka.strimzi.io/v1beta2
    kind: KafkaMirrorMaker
    metadata:
      name: my-mirror-maker
    spec:
      replicas: 3 1
      consumer:
        bootstrapServers: my-source-cluster-kafka-bootstrap:9092 2
        groupId: "my-group" 3
        numStreams: 2 4
        offsetCommitInterval: 120000 5
        tls: 6
          trustedCertificates:
          - secretName: my-source-cluster-ca-cert
            certificate: ca.crt
        authentication: 7
          type: tls
          certificateAndKey:
            secretName: my-source-secret
            certificate: public.crt
            key: private.key
        config: 8
          max.poll.records: 100
          receive.buffer.bytes: 32768
          ssl.cipher.suites: "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384" 9
          ssl.enabled.protocols: "TLSv1.2"
          ssl.protocol: "TLSv1.2"
          ssl.endpoint.identification.algorithm: HTTPS 10
      producer:
        bootstrapServers: my-target-cluster-kafka-bootstrap:9092
        abortOnSendFailure: false 11
        tls:
          trustedCertificates:
          - secretName: my-target-cluster-ca-cert
            certificate: ca.crt
        authentication:
          type: tls
          certificateAndKey:
            secretName: my-target-secret
            certificate: public.crt
            key: private.key
        config:
          compression.type: gzip
          batch.size: 8192
          ssl.cipher.suites: "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384" 12
          ssl.enabled.protocols: "TLSv1.2"
          ssl.protocol: "TLSv1.2"
          ssl.endpoint.identification.algorithm: HTTPS 13
      include: "my-topic|other-topic" 14
      resources: 15
        requests:
          cpu: "1"
          memory: 2Gi
        limits:
          cpu: "2"
          memory: 2Gi
      logging: 16
        type: inline
        loggers:
          mirrormaker.root.logger: "INFO"
      readinessProbe: 17
        initialDelaySeconds: 15
        timeoutSeconds: 5
      livenessProbe:
        initialDelaySeconds: 15
        timeoutSeconds: 5
      metricsConfig: 18
       type: jmxPrometheusExporter
       valueFrom:
         configMapKeyRef:
           name: my-config-map
           key: my-key
      jvmOptions: 19
        "-Xmx": "1g"
        "-Xms": "1g"
      image: my-org/my-image:latest 20
      template: 21
        pod:
          affinity:
            podAntiAffinity:
              requiredDuringSchedulingIgnoredDuringExecution:
                - labelSelector:
                    matchExpressions:
                      - key: application
                        operator: In
                        values:
                          - postgresql
                          - mongodb
                  topologyKey: "kubernetes.io/hostname"
        connectContainer: 22
          env:
            - name: JAEGER_SERVICE_NAME
              value: my-jaeger-service
            - name: JAEGER_AGENT_HOST
              value: jaeger-agent-name
            - name: JAEGER_AGENT_PORT
              value: "6831"
      tracing: 23
        type: jaeger
    1
    2
    面向消费者和生成器的 bootstrap 服务器
    3
    4
    5
    6
    TLS 加密,使用密钥名称,其中 TLS 证书存储为消费者或制作者的 X.509 格式。如果证书存储在同一 secret 中,可以多次列出它。
    7
    使用 TLS 机制的用于消费者或生成者的验证(如此处所示),使用 OAuth bearer tokens, 或一个基于 SASL 的 SCRAM-SHA-256/SCRAM-SHA-512PLAIN 机制。
    8
    consumerproducer 的 Kafka 配置选项。
    9
    使用 TLS 版本的特定 密码套件 运行外部监听程序的 SSL 属性
    10
    通过设置为 HTTPS 来启用主机名验证。空字符串禁用验证。
    11
    如果 abortOnSendFailure 属性设为 true,则 Kafka MirrorMaker 将退出,并且容器将因消息的发送失败而重启。
    12
    使用 TLS 版本的特定 密码套件 运行外部监听程序的 SSL 属性
    13
    通过设置为 HTTPS 来启用主机名验证。空字符串禁用验证。
    14
    15
    用于保留 支持的资源、当前 cpu 和内存 的请求,以及指定可消耗的最大资源数量。
    16
    通过 ConfigMap 直接添加(内联)或间接(外部)的指定 日志记录器和日志级别。自定义 ConfigMap 必须放在 log4j.propertieslog4j2.properties 键下。MirrorMaker 有一个名为 mirrormaker.root.logger 的单个日志记录器。您可以将日志级别设置为 INFO、ERROR、WARN、TRACE、DEBUG、FATAL 或 OFF。
    17
    状况检查,了解何时重启容器(持续)以及容器是否可以接受流量(就绪状态)。
    18
    Prometheus metrics,通过引用本例中的 Prometheus JMX JMX exporter 配置的 ConfigMap 来启用。您可以启用指标,而无需进一步配置,使用对 metricsConfig.valueFrom.configMapKeyRef.key 下包含空文件的 ConfigMap 的引用。
    19
    JVM 配置选项,用于优化运行 Kafka MirrorMaker 的虚拟机(VM)性能。
    20
    ADVANCED OPTION: 容器镜像配置,这只在特殊情况下建议。
    21
    模板自定义。这里调度了带有反关联性的 pod,因此不会将 pod 调度到具有相同主机名的节点。
    22
    还使用 Jaeger 为分布式追踪 设置环境变量。
    23
    警告

    abortOnSendFailure 属性设置为 false 时,生产者会尝试在主题中发送下一消息。原始消息可能会丢失,因为没有尝试重新发送失败的信息。

  2. 创建或更新资源:

    oc apply -f <your-file>

2.4.2. Kafka MirrorMaker 集群资源列表

以下资源由 OpenShift 集群中的 Cluster Operator 创建:

<mirror-maker-name>-mirror-maker
负责创建 Kafka MirrorMaker Pod 的部署。
<mirror-maker-name>-config
ConfigMap,包含 Kafka MirrorMaker 的辅助配置,并被 Kafka 代理 Pod 挂载为卷。
<mirror-maker-name>-mirror-maker
为 Kafka MirrorMaker worker 节点配置的 Pod Disruption Budget。

2.5. Kafka MirrorMaker 2.0 集群配置

本节论述了如何在 AMQ Streams 集群中配置 Kafka MirrorMaker 2.0 部署。

MirrorMaker 2.0 用于在两个或多个活跃的 Kafka 集群间复制数据。

集群中的数据复制支持需要的情况:

  • 在系统失败时恢复数据
  • 聚合数据进行分析
  • 特定集群的数据访问限制
  • 在特定位置置备数据以提高延迟

如果使用 MirrorMaker 2.0,请配置 KafkaMirrorMaker2 资源。KafkaMirrorMaker2 资源的完整 schema 在 KafkaMirrorMaker2 模式中描述。

MirrorMaker 2.0 引入了全新的方法来在集群间复制数据。

因此,资源配置与之前版本的 MirrorMaker 不同。如果您选择使用 MirrorMaker 2.0,目前还没有旧的支持,因此任何资源都必须手动转换为新格式。

2.5.1. MirrorMaker 2.0 数据复制

MirrorMaker 2.0 使用来自源 Kafka 集群的信息,并将其写入目标 Kafka 集群。

MirrorMaker 2.0 使用:

  • 源集群配置使用来自源集群的数据
  • 将数据输出到目标集群的目标集群配置

MirrorMaker 2.0 基于 Kafka Connect 框架,连接器 管理集群之间的数据传输。

MirrorMaker 2.0 使用以下连接器:

MirrorSourceConnector
源连接器将主题从源集群复制到目标集群。
MirrorCheckpointConnector
检查点连接器定期跟踪偏移。如果启用,它还会在源和目标集群之间同步消费者组偏移。
MirrorHeartbeatConnector
heartbeat 连接器会定期检查源和目标集群之间的连接。

镜像 从一个集群镜像到另一个集群的过程是异步的。推荐的模式是在本地和源 Kafka 集群一起生成信息,然后远程消耗到目标 Kafka 集群。

MirrorMaker 2.0 可以和多个源集群一起使用。

图 2.1. 在两个集群间复制

MirrorMaker 2.0 复制

默认情况下,每隔 10 分钟对源集群中的新主题进行一次检查。您可以通过在源连接器配置中添加 refresh.topics.interval.seconds 来更改频率。但是,增加操作的频率可能会影响整体性能。

2.5.2. 集群配置

您可以在主动/被动主动/主动集群配置中使用 MirrorMaker 2.0。

  • 主动/主动配置中,两个集群都处于活跃状态,并同时提供相同的数据,如果您需要在不同地理位置的本地都提供相同的数据,这个配置非常有用。
  • 主动/被动配置中,主动集群中的数据会在被动集群被复制,后者处于待机状态(例如在系统失败时进行数据恢复)。

预计生产者和消费者仅连接到活跃集群。

每个目标目的地都需要一个 MirrorMaker 2.0 集群。

2.5.2.1. 双向复制(主动/主动)

MirrorMaker 2.0 架构支持 主动/主动集群配置中 双向复制。

每个集群使用 源和目标 主题的概念复制其他 集群的数据。与每个集群中存储相同的主题,远程主题由 MirrorMaker 2.0 自动重命名来代表源集群。原始集群的名称前面是主题名称的前面。

图 2.2. 主题重命名

MirrorMaker 2.0 双向架构

通过标记原始集群,主题不会重新复制到该集群。

在配置需要数据聚合的构架时,通过远程 主题复制的概念非常有用。消费者可以订阅同一集群中的源和远程主题,而无需单独聚合集群。

2.5.2.2. 单向复制(主动/被动)

MirrorMaker 2.0 架构支持 主动/被动 集群配置中的单向复制。

您可以使用 主动/被动 集群配置进行备份或将数据迁移到另一个集群。在这种情况下,您可能不希望自动重命名远程主题。

您可以通过将 IdentityReplicationPolicy 添加到源连接器配置来覆盖自动重命名。应用此配置后,主题会保留其原始名称。

2.5.2.3. 主题配置同步

主题配置在源和目标集群之间自动同步。通过同步配置属性,减少了重新平衡的需求。

2.5.2.4. 数据完整性

MirrorMaker 2.0 监控源主题,并将任何配置更改传播到远程主题,检查和创建缺失的分区。只有 MirrorMaker 2.0 才能写入到远程主题。

2.5.2.5. 偏移跟踪

MirrorMaker 2.0 使用内部主题来跟踪消费者组的偏移量。

  • offset-syncs 主题从记录元数据映射复制主题分区的源和目标偏移。
  • checkpoints 主题映射源和目标集群中每个消费者组中复制的主题分区的最后提交偏移量

MirrorCheckpointConnector emits 检查点 用于偏移跟踪。检查点 主题的偏移是通过配置预先确定的间隔跟踪。这两个主题都可让复制从故障转移上的正确偏移位置完全恢复。

默认情况下,offset-syncs 主题的位置是 源集群。您可以使用 offset-syncs.topic.location 连接器配置将其更改为 目标集群。您需要对包含主题的集群进行读/写访问。使用目标集群作为 偏移同步 主题的位置,允许您使用 MirrorMaker 2.0,即使您只对源集群具有读取访问权限。

2.5.2.6. 同步消费者组偏移

__consumer_offsets 主题存储各个消费者组的提交偏移信息。偏移同步定期将源集群的使用者偏移量传输到目标集群的使用者偏移主题。

偏移同步在 主动/被动配置 中特别有用。如果活跃集群停机,使用者应用程序可以切换到被动(被动)集群,并从最后传输的偏移位置获取。

要使用主题偏移同步,通过在检查点连接器配置中添加 sync.group.offsets.enabled 来启用同步,并将 属性设为 true。默认禁用同步。

在源连接器中使用 IdentityReplicationPolicy 时,还必须在检查点连接器配置中配置。这样可确保为正确的主题应用镜像使用者偏移量。

使用者偏移仅为目标集群中不活动的消费者组同步。如果消费者组在目标集群中,则无法执行同步,并返回 UNKNOWN_MEMBER_ID 错误。

如果启用,将定期从源集群同步偏移。您可以通过在检查点连接器配置中添加 sync.group.offsets.secondsemit.checkpoints.interval.seconds 来更改频率。属性指定消费者组偏移的频率,以及针对偏移跟踪发出的检查点的频率。两个属性的默认值都是 60 秒。您还可以使用 refresh.groups.interval.seconds 属性更改新消费者组的检查频率,该属性默认为每 10 分钟执行一次。

因为同步是基于时间的,所以消费者到被动集群的任何交换机都可能会导致消息重复。

2.5.2.7. 连接检查

MirrorHeartbeatConnector 发出 heartbeats 来检查集群间的连接。

从源集群复制内部 心跳 主题。目标集群使用 heartbeat 主题来检查以下内容:

  • 管理集群间连接的连接器正在运行
  • 源集群可用

2.5.3. 连接器配置

将 Mirrormaker 2.0 连接器配置用于内部连接器,以编配 Kafka 集群之间的数据同步。

下表描述了连接器属性和您配置的连接器。

表 2.1. MirrorMaker 2.0 连接器配置属性
属性sourceConnectorcheckpointConnectorheartbeatConnector
admin.timeout.ms
管理任务的超时,如检测新主题。默认为 60000 (1 分钟)。

replication.policy.class
定义远程主题命名约定的策略。默认为 org.apache.kafka.connect.mirror.DefaultReplicationPolicy

replication.policy.separator
目标集群中用于主题命名的分隔符。默认为 (dot)。只有在 replication.policy.classDefaultReplicationPolicy 时,它才会被使用。

consumer.poll.timeout.ms
轮询源集群时的超时。默认值为 1000 (1 秒)。

 
offset-syncs.topic.location
offset-syncs 主题的位置,可以是 (默认)或 目标集群

 
topic.filter.class
主题过滤器,以选择要复制的主题。默认为 org.apache.kafka.connect.mirror.DefaultTopicFilter

 
config.property.filter.class
主题过滤器,选择要复制的主题配置属性。默认为 org.apache.kafka.connect.mirror.DefaultConfigPropertyFilter

  
config.properties.exclude
不应复制的主题配置属性。支持以逗号分隔的属性名称和正则表达式。

  
offset.lag.max
同步远程分区前最多允许(out-of-sync)偏移偏移量。默认值为 100

  
offset-syncs.topic.replication.factor
内部偏移同步 主题的复制因素。默认为 3

  
refresh.topics.enabled
启用检查新主题和分区。默认为 true

  
refresh.topics.interval.seconds
主题刷新频率。默认为 600 (10 分钟)。

  
replication.factor
新主题的复制因素。默认为 2

  
sync.topic.acls.enabled
在源集群中启用 ACL 同步。默认为 true。与 User Operator 不兼容。

  
sync.topic.acls.interval.seconds
ACL 同步频率。默认为 600 (10 分钟)。

  
sync.topic.configs.enabled
启用源集群中的主题配置同步。默认为 true

  
sync.topic.configs.interval.seconds
主题配置同步频率。默认 600 (10 分钟)。

  
checkpoints.topic.replication.factor
内部 检查点 主题的复制因素。默认为 3
 

 
emit.checkpoints.enabled
启用将消费者偏移同步到目标集群。默认为 true
 

 
emit.checkpoints.interval.seconds
消费者偏移同步的频率。默认为 60 (1 分钟)。
 

 
group.filter.class
组过滤器,以选择要复制的使用者组。默认为 org.apache.kafka.connect.mirror.DefaultGroupFilter
 

 
refresh.groups.enabled
为新的消费者组启用检查。默认为 true
 

 
refresh.groups.interval.seconds
消费者组刷新频率。默认为 600 (10 分钟)。
 

 
sync.group.offsets.enabled
启用将消费者组偏移同步到目标集群 __consumer_offsets 主题。默认为 false
 

 
sync.group.offsets.interval.seconds
消费者组偏移同步的频率。默认为 60 (1 分钟)。
 

 
emit.heartbeats.enabled
在目标集群中启用连接检查。默认为 true
  

emit.heartbeats.interval.seconds
连接检查的频率。默认为 1 ( 1 秒)。
  

heartbeats.topic.replication.factor
内部 心跳 主题的复制因素。默认为 3
  

2.5.4. 连接器制作者和消费者配置

MirrorMaker 2.0 连接器使用内部制作者和消费者。如果需要,您可以配置这些制作者和消费者来覆盖默认设置。

例如,您可以提高源制作者的 batch.size,该制作者会向目标 Kafka 集群发送主题以更好地容纳大量消息。

重要

生产者和使用者配置选项取决于 MirrorMaker 2.0 实施,可能会有所变化。

下表描述了每个连接器以及您可在其中添加配置的制作者和消费者。

表 2.2. 源连接器制作者和使用者
类型Description配置

制作者

将主题信息发送到目标 Kafka 集群。在处理大量数据时,请考虑调优此制作者的配置。

mirrors.sourceConnector.config: producer.override.*

制作者

写入 offset-syncs 主题,用于映射复制主题分区的源和目标偏移。

mirrors.sourceConnector.config: producer.*

消费者

从源 Kafka 集群检索主题信息。

mirrors.sourceConnector.config: consumer.*

表 2.3. Checkpoint 连接器制作者和消费者
类型Description配置

制作者

发送消费者偏移检查点。

mirrors.checkpointConnector.config: producer.override.*

消费者

加载 offset-syncs 主题。

mirrors.checkpointConnector.config: consumer.*

注意

您可以将 offset-syncs.topic.location 设置为 target 来使用目标 Kafka 集群作为 offset-syncs 主题的位置。

表 2.4. heartbeat 连接器制作器
类型Description配置

制作者

发送心跳.

mirrors.heartbeatConnector.config: producer.override.*

以下示例演示了如何配置制作者和使用者。

连接器制作者和消费者配置示例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaMirrorMaker2
metadata:
  name: my-mirror-maker2
spec:
  version: 3.2.3
  # ...
  mirrors:
  - sourceCluster: "my-cluster-source"
    targetCluster: "my-cluster-target"
    sourceConnector:
      tasksMax: 5
      config:
        producer.override.batch.size: 327680
        producer.override.linger.ms: 100
        producer.request.timeout.ms: 30000
        consumer.fetch.max.bytes: 52428800
        # ...
    checkpointConnector:
      config:
        producer.override.request.timeout.ms: 30000
        consumer.max.poll.interval.ms: 300000
        # ...
    heartbeatConnector:
      config:
        producer.override.request.timeout.ms: 30000
        # ...

2.5.5. 指定最多任务数

连接器创建负责在 Kafka 中和移出数据的任务。每个连接器都包含一个或多个任务,它们分布在一组运行任务的 worker pod 中。在复制大量分区或同步大量消费者组的偏移时,增加任务数量可帮助出现性能问题。

任务并行运行。为 worker 分配一个或多个任务。单个任务由一个 worker pod 处理,因此您不需要更多的 worker pod。如果任务数量超过 worker,worker 会处理多个任务。

您可以使用 tasksMax 属性指定 mirrorMaker 配置中的最大连接器任务数量。如果不指定最多任务数,则默认设置是一个单任务。

heartbeat 连接器始终使用单个任务。

为源和检查点连接器启动的任务数量是最大可能任务和 tasksMax 的值之间的低值。对于源连接器,可以最多的任务数是从源集群复制的每个分区。对于 checkpoint 连接器,可以为每个消费者组从源集群复制的最多任务数。当设置最多任务数时,请考虑分区的数量和支持该进程的硬件资源。

如果基础架构支持处理开销,增加任务数量可提高吞吐量和延迟。例如,添加更多任务可减少在有大量分区或消费者组时轮询源集群所需的时间。

当您有大量分区时,增加检查点连接器的任务数量会很有用。

为源连接器增加任务数量

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaMirrorMaker2
metadata:
  name: my-mirror-maker2
spec:
  # ...
  mirrors:
  - sourceCluster: "my-cluster-source"
    targetCluster: "my-cluster-target"
    sourceConnector:
      tasksMax: 10
  # ...

当您有大量消费者组时,增加检查点连接器的任务数量会很有用。

增加检查点连接器的任务数量

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaMirrorMaker2
metadata:
  name: my-mirror-maker2
spec:
  # ...
  mirrors:
  - sourceCluster: "my-cluster-source"
    targetCluster: "my-cluster-target"
    checkpointConnector:
      tasksMax: 10
  # ...

默认情况下,MirrorMaker 2.0 会每 10 分钟检查新的消费者组。您可以调整 refresh.groups.interval.seconds 配置以更改频率。在调整调整时要小心。更频繁的检查会对性能造成负面影响。

2.5.5.1. 检查连接器任务操作

如果使用 Prometheus 和 Grafana 监控部署,您可以检查 MirrorMaker 2.0 性能。AMQ Streams 提供的 MirrorMaker 2.0 Grafana 仪表板示例显示了与任务和延迟相关的以下指标。

  • 任务数量
  • 复制延迟
  • 偏移同步延迟

其他资源

2.5.6. ACL 规则同步

如果您不使用 User Operator,则可使用 ACL 访问远程主题。

如果使用 AclAuthorizer,但没有 User Operator,则管理对代理的访问的 ACL 规则也适用于远程主题。可以读取源主题的用户可以读取其远程等效功能。

注意

OAuth 2.0 授权不支持以这种方式访问远程主题。

2.5.7. Configuring Kafka MirrorMaker 2.0

使用 KafkaMirrorMaker2 资源的属性来配置 Kafka MirrorMaker 2.0 部署。使用 MirrorMaker 2.0 在 Kafka 集群间同步数据

配置必须指定:

  • 每个 Kafka 集群
  • 每个集群的连接信息,包括 TLS 身份验证
  • 复制流和方向

    • 集群到集群
    • 主题
注意

以前版本的 MirrorMaker 将继续被支持。如果要使用为之前的版本配置的资源,必须将其更新为 MirrorMaker 2.0 支持的格式。

MirrorMaker 2.0 为复制因素等属性提供默认配置值。最小配置(默认值保持不变)会类似以下示例:

MirrorMaker 2.0 的最小配置

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaMirrorMaker2
metadata:
  name: my-mirror-maker2
spec:
  version: 3.2.3
  connectCluster: "my-cluster-target"
  clusters:
  - alias: "my-cluster-source"
    bootstrapServers: my-cluster-source-kafka-bootstrap:9092
  - alias: "my-cluster-target"
    bootstrapServers: my-cluster-target-kafka-bootstrap:9092
  mirrors:
  - sourceCluster: "my-cluster-source"
    targetCluster: "my-cluster-target"
    sourceConnector: {}

您可以使用 TLS 或 SASL 身份验证为源和目标集群配置访问控制。此流程显示对源和目标集群使用 TLS 加密和身份验证的配置。

您可以在 KafkaMirrorMaker2 资源中指定要从源集群复制的主题和消费者组。您可以使用 topicsPatterngroupsPattern 属性进行此操作。您可以提供名称或使用正则表达式的列表。默认情况下,如果没有设置 topicsPatterngroupsPattern 属性,则会复制所有主题和消费者组。您还可以使用 ".*" 作为正则表达式来复制所有主题和消费者组。但是,尝试只指定您所需的主题和消费者组,以避免造成集群中的不必要的额外负载。

处理大量消息

您可以调整配置来处理大量消息。更多信息请参阅 第 2.7 节 “处理大量消息”

先决条件

  • AMQ Streams 处于运行状态
  • 源集群和目标 Kafka 集群可用

流程

  1. 编辑 KafkaMirrorMaker2 资源的 spec 属性。

    您可以在以下示例配置中显示您可以配置的属性:

    apiVersion: kafka.strimzi.io/v1beta2
    kind: KafkaMirrorMaker2
    metadata:
      name: my-mirror-maker2
    spec:
      version: 3.2.3 1
      replicas: 3 2
      connectCluster: "my-cluster-target" 3
      clusters: 4
      - alias: "my-cluster-source" 5
        authentication: 6
          certificateAndKey:
            certificate: source.crt
            key: source.key
            secretName: my-user-source
          type: tls
        bootstrapServers: my-cluster-source-kafka-bootstrap:9092 7
        tls: 8
          trustedCertificates:
          - certificate: ca.crt
            secretName: my-cluster-source-cluster-ca-cert
      - alias: "my-cluster-target" 9
        authentication: 10
          certificateAndKey:
            certificate: target.crt
            key: target.key
            secretName: my-user-target
          type: tls
        bootstrapServers: my-cluster-target-kafka-bootstrap:9092 11
        config: 12
          config.storage.replication.factor: 1
          offset.storage.replication.factor: 1
          status.storage.replication.factor: 1
          ssl.cipher.suites: "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384" 13
          ssl.enabled.protocols: "TLSv1.2"
          ssl.protocol: "TLSv1.2"
          ssl.endpoint.identification.algorithm: HTTPS 14
        tls: 15
          trustedCertificates:
          - certificate: ca.crt
            secretName: my-cluster-target-cluster-ca-cert
      mirrors: 16
      - sourceCluster: "my-cluster-source" 17
        targetCluster: "my-cluster-target" 18
        sourceConnector: 19
          tasksMax: 10 20
          config:
            replication.factor: 1 21
            offset-syncs.topic.replication.factor: 1 22
            sync.topic.acls.enabled: "false" 23
            refresh.topics.interval.seconds: 60 24
            replication.policy.separator: "" 25
            replication.policy.class: "org.apache.kafka.connect.mirror.IdentityReplicationPolicy" 26
        heartbeatConnector: 27
          config:
            heartbeats.topic.replication.factor: 1 28
        checkpointConnector: 29
          config:
            checkpoints.topic.replication.factor: 1 30
            refresh.groups.interval.seconds: 600 31
            sync.group.offsets.enabled: true 32
            sync.group.offsets.interval.seconds: 60 33
            emit.checkpoints.interval.seconds: 60 34
            replication.policy.class: "org.apache.kafka.connect.mirror.IdentityReplicationPolicy"
        topicsPattern: "topic1|topic2|topic3" 35
        groupsPattern: "group1|group2|group3" 36
      resources: 37
        requests:
          cpu: "1"
          memory: 2Gi
        limits:
          cpu: "2"
          memory: 2Gi
      logging: 38
        type: inline
        loggers:
          connect.root.logger.level: "INFO"
      readinessProbe: 39
        initialDelaySeconds: 15
        timeoutSeconds: 5
      livenessProbe:
        initialDelaySeconds: 15
        timeoutSeconds: 5
      jvmOptions: 40
        "-Xmx": "1g"
        "-Xms": "1g"
      image: my-org/my-image:latest 41
      rack:
        topologyKey: topology.kubernetes.io/zone 42
      template: 43
        pod:
          affinity:
            podAntiAffinity:
              requiredDuringSchedulingIgnoredDuringExecution:
                - labelSelector:
                    matchExpressions:
                      - key: application
                        operator: In
                        values:
                          - postgresql
                          - mongodb
                  topologyKey: "kubernetes.io/hostname"
        connectContainer: 44
          env:
            - name: JAEGER_SERVICE_NAME
              value: my-jaeger-service
            - name: JAEGER_AGENT_HOST
              value: jaeger-agent-name
            - name: JAEGER_AGENT_PORT
              value: "6831"
      tracing:
        type: jaeger 45
      externalConfiguration: 46
        env:
          - name: AWS_ACCESS_KEY_ID
            valueFrom:
              secretKeyRef:
                name: aws-creds
                key: awsAccessKey
          - name: AWS_SECRET_ACCESS_KEY
            valueFrom:
              secretKeyRef:
                name: aws-creds
                key: awsSecretAccessKey
    1
    Kafka Connect 和 Mirror Maker 2.0 版本,其始终相同。
    2
    运行任务的 worker 的副本数。
    3
    Kafka Connect 的 Kafka 集群别名,必须指定 目标 Kafka 集群。Kafka 连接使用 Kafka 集群作为其内部主题。
    4
    正在同步的 Kafka 集群的规格
    5
    源 Kafka 集群的集群别名
    6
    源集群的身份验证使用 TLS 机制,如此处所示,使用 OAuth bearer 令牌或基于 SASL 的 SCRAM-SHA-256/SCRAM-SHA-512PLAIN 机制。
    7
    8
    TLS 加密,使用密钥名称,其中 TLS 证书存储为源 Kafka 集群的 X.509 格式。如果证书存储在同一 secret 中,可以多次列出它。
    9
    目标 Kafka 集群的集群别名
    10
    目标 Kafka 集群的身份验证的配置方式与源 Kafka 集群相同。
    11
    12
    Kafka 连接配置.可以提供标准 Apache Kafka 配置,仅限于不直接由 AMQ Streams 管理的属性。
    13
    使用 TLS 版本的特定 密码套件 运行外部监听程序的 SSL 属性
    14
    通过设置为 HTTPS 来启用主机名验证。空字符串禁用验证。
    15
    目标 Kafka 集群的 TLS 加密配置方式与源 Kafka 集群相同。
    16
    17
    MirrorMaker 2.0 连接器使用的源集群 别名
    18
    MirrorMaker 2.0 连接器使用的目标 集群的集群别名
    19
    创建远程 主题的 MirrorSourceConnector配置配置 会覆盖默认配置选项。
    20
    连接器可能会创建的最大任务数量。任务处理数据复制并并行运行。如果基础架构支持处理开销,则增加这个值可提高吞吐量。Kafka Connect 在集群的成员之间分发任务。如果任务数量超过 worker,则 worker 会被分配多个任务。对于接收器连接器,旨在为每个消耗的主题分区有一个任务。对于源连接器,可以并行运行的任务数量也可能依赖于外部系统。如果无法实现并行,连接器会创建一个数量少于最大任务数量。
    21
    在目标集群中创建的镜像主题的复制因素。
    22
    MirrorSourceConnector offset-syncs 内部主题的复制因素,它映射源和目标集群的偏移量。
    23
    启用 ACL 规则同步后,ACL 将应用到同步主题。默认值是 true。此功能与 User Operator 不兼容。如果使用 User Operator,请将此属性设置为 false
    24
    可选设置,用于更改新主题的检查频率。默认值每 10 分钟进行一次检查。
    25
    定义用于重命名远程主题的分隔符。
    26
    添加可覆盖远程主题自动重命名的策略。该主题不会用源集群的名称来附加名称,而是保留其原始名称。此可选设置可用于主动/被动备份和数据迁移。要配置主题偏移同步,必须为 checkpointConnector.config 设置此属性。
    27
    执行连接检查的 MirrorHeartbeatConnector配置配置 会覆盖默认配置选项。
    28
    在目标集群中创建的 heartbeat 主题的复制因素。
    29
    用于跟踪偏移 MirrorCheckpointConnector配置配置 会覆盖默认配置选项。
    30
    在目标集群中创建的检查点主题的复制因素。
    31
    可选设置,用于更改新消费者组的检查频率。默认值每 10 分钟进行一次检查。
    32
    可选设置同步消费者组偏移,这对于在主动/被动配置中恢复非常有用。默认情况下不启用同步。
    33
    如果启用了消费者组偏移的同步,您可以调整同步的频率。
    34
    调整偏移跟踪的检查频率。如果更改偏移同步的频率,您可能需要调整这些检查的频率。
    35
    来自源集群的主题复制 ,定义为用逗号分开的列表或正则表达式模式。源连接器复制指定的主题。Checkpoint 连接器跟踪指定主题的偏移量。此处我们按名称请求三个主题。
    36
    来自源集群的消费者组复制 ,定义为以逗号分隔的列表或正则表达式模式。checkpoint 连接器复制指定的使用者组。此处我们根据名称请求三个消费者组。
    37
    用于保留 支持的资源、当前 cpu 和内存 的请求,以及指定可消耗的最大资源数量。
    38
    指定的 Kafka Connect 日志记录器和日志级别 直接(内联)或通过 ConfigMap 间接添加(外部)。自定义 ConfigMap 必须放在 log4j.propertieslog4j2.properties 键下。对于 Kafka Connect log4j.rootLogger 日志记录器,您可以将日志级别设置为 INFO、ERROR、WARN、WARN、TRACE、DEBUG、FATAL 或 OFF。
    39
    状况检查,了解何时重启容器(持续)以及容器是否可以接受流量(就绪状态)。
    40
    JVM 配置选项,用于优化运行 Kafka MirrorMaker 的虚拟机(VM)性能。
    41
    ADVANCED OPTION: 容器镜像配置,这只在特殊情况下建议。
    42
    SPECIALIZED OPTION :对部署的意识 配置.这是用于在同一位置(而非跨地区)部署的专用选项。如果您希望连接器从最接近的副本而不是领导副本使用,则使用此选项。在某些情况下,消耗自最接近的副本可以提高网络利用率或降低成本。topologyKey 必须与包含机架 ID 的节点标签匹配。此配置中使用的示例使用标准 topology.kubernetes.io/zone 标签指定区。要从最接近的副本使用,请在 Kafka 代理配置中启用 RackAwareReplicaSelector
    43
    模板自定义。这里调度了带有反关联性的 pod,因此不会将 pod 调度到具有相同主机名的节点。
    44
    还使用 Jaeger 为分布式追踪 设置环境变量。
    45
    46
    OpenShift Secret 的外部配置 作为环境变量挂载到 Kafka MirrorMaker。您还可以使用 配置供应商插件 从外部源 加载配置值
  2. 创建或更新资源:

    oc apply -f MIRRORMAKER-CONFIGURATION-FILE

2.5.8. 保护 Kafka MirrorMaker 2.0 部署

此流程描述了保护镜像Maker 2.0 部署所需的配置。

您需要对源 Kafka 集群和目标 Kafka 集群进行单独的配置。您还需要单独的用户配置来提供 MirrorMaker 连接到源和目标 Kafka 集群所需的凭证。

对于 Kafka 集群,您可以指定 OpenShift 集群内安全连接的内部监听程序,以及用于 OpenShift 集群外的连接的外部监听程序。

您可以配置身份验证和授权机制。为源和目标 Kafka 集群实施的安全选项必须与为 MirrorMaker 2.0 实施的安全选项兼容。

创建集群和用户身份验证凭据后,您可以在 mirrorMaker 配置中为安全连接指定它们。

注意

在这一流程中,会使用 Cluster Operator 生成的证书,但您可以 通过安装自己的证书 来替换它们。您还可以将监听程序 配置为使用由外部证书颁发机构管理的 Kafka 侦听器证书

开始前

在开始这个过程前,请查看 AMQ Streams 提供的示例配置文件。它们包括使用 TLS 或 SCRAM-SHA-512 身份验证保护镜像的 2.0 部署的示例。示例指定用于在 OpenShift 集群内连接的内部监听程序。

示例还显示 MirrorMaker 2.0 所需的 ACL,以允许在源和目标 Kafka 集群上操作。

先决条件

  • AMQ Streams 处于运行状态
  • 源和目标集群的独立命名空间

此流程假设将源和目标 Kafka 集群安装到单独的命名空间中,如果要使用 Topic Operator,您需要这样做。Topic Operator 只监视指定命名空间中的单个集群。

通过将集群划分为命名空间,您需要复制集群 secret,以便可以在命名空间外访问集群 secret。您需要在 imagesMaker 配置中引用 secret。

流程

  1. 配置两个 Kafka 资源,一个用于保护源 Kafka 集群,另一个来保护目标 Kafka 集群。

    您可以添加用于身份验证的监听程序配置并启用授权。

    在本例中,为使用 TLS 加密和身份验证的 Kafka 集群配置内部监听程序。启用 Kafka 简单 授权。

    使用 TLS 身份验证的源 Kafka 集群配置示例

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    metadata:
      name: my-source-cluster
    spec:
      kafka:
        version: 3.2.3
        replicas: 1
        listeners:
          - name: tls
            port: 9093
            type: internal
            tls: true
            authentication:
              type: tls
        authorization:
          type: simple
        config:
          offsets.topic.replication.factor: 1
          transaction.state.log.replication.factor: 1
          transaction.state.log.min.isr: 1
          default.replication.factor: 1
          min.insync.replicas: 1
          inter.broker.protocol.version: "3.2"
        storage:
          type: jbod
          volumes:
          - id: 0
            type: persistent-claim
            size: 100Gi
            deleteClaim: false
      zookeeper:
        replicas: 1
        storage:
          type: persistent-claim
          size: 100Gi
          deleteClaim: false
      entityOperator:
        topicOperator: {}
        userOperator: {}

    使用 TLS 身份验证的目标 Kafka 集群配置示例

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    metadata:
      name: my-target-cluster
    spec:
      kafka:
        version: 3.2.3
        replicas: 1
        listeners:
          - name: tls
            port: 9093
            type: internal
            tls: true
            authentication:
              type: tls
        authorization:
          type: simple
        config:
          offsets.topic.replication.factor: 1
          transaction.state.log.replication.factor: 1
          transaction.state.log.min.isr: 1
          default.replication.factor: 1
          min.insync.replicas: 1
          inter.broker.protocol.version: "3.2"
        storage:
          type: jbod
          volumes:
            - id: 0
              type: persistent-claim
              size: 100Gi
              deleteClaim: false
      zookeeper:
        replicas: 1
        storage:
          type: persistent-claim
          size: 100Gi
          deleteClaim: false
      entityOperator:
        topicOperator: {}
        userOperator: {}

  2. 在单独的命名空间中创建或更新 Kafka 资源。

    oc apply -f <kafka_configuration_file> -n <namespace>

    Cluster Operator 创建监听程序并设置集群和客户端证书颁发机构(CA)证书,以便在 Kafka 集群中启用身份验证。

    证书在 secret < cluster_name> -cluster-ca-cert 中创建。

  3. 配置两个 KafkaUser 资源,一个用于源 Kafka 集群的用户,一个用于目标 Kafka 集群的用户。

    1. 配置与对应的源和目标 Kafka 集群相同的身份验证和授权类型。例如,如果您在源 Kafka 集群的 Kafka 配置中使用了 tls 验证和 simple 授权类型,请在 KafkaUser 配置中使用相同的。
    2. 配置 MirrorMaker 2.0 所需的 ACL,以允许在源和目标 Kafka 集群上执行操作。

      ACL 由内部 MirrorMaker 连接器以及底层 Kafka 连接框架使用。

    TLS 客户端身份验证的源用户配置示例

    apiVersion: kafka.strimzi.io/v1beta2
    kind: KafkaUser
    metadata:
      name: my-source-user
      labels:
        strimzi.io/cluster: my-source-cluster
    spec:
      authentication:
        type: tls
      authorization:
        type: simple
        acls:
          # MirrorSourceConnector
          - resource: # Not needed if offset-syncs.topic.location=target
              type: topic
              name: mm2-offset-syncs.my-target-cluster.internal
            operation: Create
          - resource: # Not needed if offset-syncs.topic.location=target
              type: topic
              name: mm2-offset-syncs.my-target-cluster.internal
            operation: DescribeConfigs
          - resource: # Not needed if offset-syncs.topic.location=target
              type: topic
              name: mm2-offset-syncs.my-target-cluster.internal
            operation: Write
          - resource: # Needed for every topic which is mirrored
              type: topic
              name: "*"
            operation: Read
          - resource: # Needed for every topic which is mirrored
              type: topic
              name: "*"
            operation: DescribeConfigs
          # MirrorCheckpointConnector
          - resource:
              type: cluster
            operation: Describe
          - resource: # Needed for every group for which offsets are synced
              type: group
              name: "*"
            operation: Describe
          - resource: # Not needed if offset-syncs.topic.location=target
              type: topic
              name: mm2-offset-syncs.my-target-cluster.internal
            operation: Read

    TLS 客户端身份验证的目标用户配置示例

    apiVersion: kafka.strimzi.io/v1beta2
    kind: KafkaUser
    metadata:
      name: my-target-user
      labels:
        strimzi.io/cluster: my-target-cluster
    spec:
      authentication:
        type: tls
      authorization:
        type: simple
        acls:
          # Underlying Kafka Connect internal topics to store configuration, offsets, or status
          - resource:
              type: group
              name: mirrormaker2-cluster
            operation: Read
          - resource:
              type: topic
              name: mirrormaker2-cluster-configs
            operation: Read
          - resource:
              type: topic
              name: mirrormaker2-cluster-configs
            operation: Describe
          - resource:
              type: topic
              name: mirrormaker2-cluster-configs
            operation: DescribeConfigs
          - resource:
              type: topic
              name: mirrormaker2-cluster-configs
            operation: Write
          - resource:
              type: topic
              name: mirrormaker2-cluster-configs
            operation: Create
          - resource:
              type: topic
              name: mirrormaker2-cluster-status
            operation: Read
          - resource:
              type: topic
              name: mirrormaker2-cluster-status
            operation: Describe
          - resource:
              type: topic
              name: mirrormaker2-cluster-status
            operation: DescribeConfigs
          - resource:
              type: topic
              name: mirrormaker2-cluster-status
            operation: Write
          - resource:
              type: topic
              name: mirrormaker2-cluster-status
            operation: Create
          - resource:
              type: topic
              name: mirrormaker2-cluster-offsets
            operation: Read
          - resource:
              type: topic
              name: mirrormaker2-cluster-offsets
            operation: Write
          - resource:
              type: topic
              name: mirrormaker2-cluster-offsets
            operation: Describe
          - resource:
              type: topic
              name: mirrormaker2-cluster-offsets
            operation: DescribeConfigs
          - resource:
              type: topic
              name: mirrormaker2-cluster-offsets
            operation: Create
          # MirrorSourceConnector
          - resource: # Needed for every topic which is mirrored
              type: topic
              name: "*"
            operation: Create
          - resource: # Needed for every topic which is mirrored
              type: topic
              name: "*"
            operation: Alter
          - resource: # Needed for every topic which is mirrored
              type: topic
              name: "*"
            operation: AlterConfigs
          - resource: # Needed for every topic which is mirrored
              type: topic
              name: "*"
            operation: Write
          # MirrorCheckpointConnector
          - resource:
              type: cluster
            operation: Describe
          - resource:
              type: topic
              name: my-source-cluster.checkpoints.internal
            operation: Create
          - resource:
              type: topic
              name: my-source-cluster.checkpoints.internal
            operation: Describe
          - resource:
              type: topic
              name: my-source-cluster.checkpoints.internal
            operation: Write
          - resource: # Needed for every group for which the offset is synced
              type: group
              name: "*"
            operation: Read
          - resource: # Needed for every group for which the offset is synced
              type: group
              name: "*"
            operation: Describe
          - resource: # Needed for every topic which is mirrored
              type: topic
              name: "*"
            operation: Read
          # MirrorHeartbeatConnector
          - resource:
              type: topic
              name: heartbeats
            operation: Create
          - resource:
              type: topic
              name: heartbeats
            operation: Describe
          - resource:
              type: topic
              name: heartbeats
            operation: Write

    注意

    您可以通过将 type 设置为 tls-external 来使用 User Operator 外部发布的证书。如需更多信息,请参阅 用户身份验证

  4. 在您为源和目标集群创建的每个命名空间中创建或更新 KafkaUser 资源。

    oc apply -f <kafka_user_configuration_file> -n <namespace>

    User Operator 根据所选的身份验证类型创建代表客户端(MirrorMaker)和用于客户端身份验证的安全凭证的用户。

    User Operator 会创建一个与 KafkaUser 资源名称相同的新 secret。secret 包含用于 TLS 客户端身份验证的私钥和公钥。公钥包含在用户证书中,由客户端证书颁发机构(CA)签名。

  5. 使用身份验证详情配置 KafkaMirrorMaker2 资源,以连接到源和目标集群。

    带有 TLS 身份验证的 MirrorMaker 2.0 配置示例

    apiVersion: kafka.strimzi.io/v1beta2
    kind: KafkaMirrorMaker2
    metadata:
      name: my-mirror-maker-2
    spec:
      version: 3.2.3
      replicas: 1
      connectCluster: "my-target-cluster"
      clusters:
        - alias: "my-source-cluster"
          bootstrapServers: my-source-cluster-kafka-bootstrap:9093
          tls: 1
            trustedCertificates:
              - secretName: my-source-cluster-cluster-ca-cert
                certificate: ca.crt
          authentication: 2
            type: tls
            certificateAndKey:
              secretName: my-source-user
              certificate: user.crt
              key: user.key
        - alias: "my-target-cluster"
          bootstrapServers: my-target-cluster-kafka-bootstrap:9093
          tls: 3
            trustedCertificates:
              - secretName: my-target-cluster-cluster-ca-cert
                certificate: ca.crt
          authentication: 4
            type: tls
            certificateAndKey:
              secretName: my-target-user
              certificate: user.crt
              key: user.key
          config:
            # -1 means it will use the default replication factor configured in the broker
            config.storage.replication.factor: -1
            offset.storage.replication.factor: -1
            status.storage.replication.factor: -1
      mirrors:
        - sourceCluster: "my-source-cluster"
          targetCluster: "my-target-cluster"
          sourceConnector:
            config:
              replication.factor: 1
              offset-syncs.topic.replication.factor: 1
              sync.topic.acls.enabled: "false"
          heartbeatConnector:
            config:
              heartbeats.topic.replication.factor: 1
          checkpointConnector:
            config:
              checkpoints.topic.replication.factor: 1
              sync.group.offsets.enabled: "true"
          topicsPattern: "topic1|topic2|topic3"
          groupsPattern: "group1|group2|group3"

    1
    源 Kafka 集群的 TLS 证书。如果它们位于单独的命名空间中,请从 Kafka 集群的命名空间复制集群 secret。
    2
    使用 TLS 机制 访问源 Kafka 集群的用户身份验证。
    3
    目标 Kafka 集群的 TLS 证书。
    4
    访问目标 Kafka 集群的用户身份验证。
  6. 在与目标 Kafka 集群相同的命名空间中创建或更新 KafkaMirrorMaker2 资源。

    oc apply -f <mirrormaker2_configuration_file> -n <namespace_of_target_cluster>

2.5.9. 执行 Kafka MirrorMaker 2.0 连接器重启

此流程描述了如何使用 OpenShift 注解手动触发 Kafka MirrorMaker 2.0 连接器的重启。

先决条件

  • Cluster Operator 正在运行。

流程

  1. 查找控制要重启的 Kafka MirrorMaker 2.0 连接器的 KafkaMirrorMaker2 自定义资源的名称:

    oc get KafkaMirrorMaker2
  2. 查找 Kafka MirrorMaker 2.0 连接器的名称,以便从 KafkaMirrorMaker2 自定义资源重启。

    oc describe KafkaMirrorMaker2 KAFKAMIRRORMAKER-2-NAME
  3. 要重启连接器,请在 OpenShift 中注解 KafkaMirrorMaker2 资源。在本例中,oc annotate 重启名为 my-source->my-target.MirrorSourceConnector 的连接器

    oc annotate KafkaMirrorMaker2 KAFKAMIRRORMAKER-2-NAME "strimzi.io/restart-connector=my-source->my-target.MirrorSourceConnector"
  4. 等待下一次协调发生(默认为两分钟)。

    Kafka MirrorMaker 2.0 连接器将重启,只要该注解由协调过程检测到。当接受重启请求时,注解会从 KafkaMirrorMaker2 自定义资源中删除。

2.5.10. 执行 Kafka MirrorMaker 2.0 连接器任务重启

此流程描述了如何使用 OpenShift 注解手动触发 Kafka MirrorMaker 2.0 连接器任务的重启。

先决条件

  • Cluster Operator 正在运行。

流程

  1. 查找控制要重启的 Kafka MirrorMaker 2.0 连接器的 KafkaMirrorMaker2 自定义资源的名称:

    oc get KafkaMirrorMaker2
  2. 查找 Kafka MirrorMaker 2.0 连接器的名称以及要从 KafkaMirrorMaker2 自定义资源重启的任务 ID。任务 ID 是非负的整数,从 0 开始。

    oc describe KafkaMirrorMaker2 KAFKAMIRRORMAKER-2-NAME
  3. 要重启连接器任务,请在 OpenShift 中注解 KafkaMirrorMaker2 资源。在本例中,oc annotate 重启名为 my-source->my-target.MirrorSourceConnector 的连接器的任务 0

    oc annotate KafkaMirrorMaker2 KAFKAMIRRORMAKER-2-NAME "strimzi.io/restart-connector-task=my-source->my-target.MirrorSourceConnector:0"
  4. 等待下一次协调发生(默认为两分钟)。

    Kafka MirrorMaker 2.0 连接器任务会重启,只要该注解由协调过程检测到。当重启任务请求被接受时,注解会从 KafkaMirrorMaker2 自定义资源中删除。

2.6. Kafka Bridge 集群配置

这部分论述了如何在 AMQ Streams 集群中配置 Kafka Bridge 部署。

Kafka Bridge 提供了一个 API,用于将基于 HTTP 的客户端与 Kafka 集群集成。

如果使用 Kafka Bridge,请配置 KafkaBridge 资源。

KafkaBridge 资源的完整 schema 包括在 第 12.2.112 节 “KafkaBridge 模式参考” 中。

2.6.1. 配置 Kafka Bridge

使用 Kafka Bridge 向 Kafka 集群发出基于 HTTP 的请求。

使用 KafkaBridge 资源的属性来配置 Kafka Bridge 部署。

为了防止,当客户端消费者请求由不同的 Kafka Bridge 实例处理时,必须使用基于地址的路由来确保请求路由到正确的 Kafka Bridge 实例。另外,每个独立的 Kafka Bridge 实例都必须有副本。Kafka Bridge 实例具有自己的状态,它不与其他实例共享。

先决条件

  • OpenShift 集群
  • 正在运行的 Cluster Operator

有关运行的信息 ,请参阅 OpenShift 中的部署和升级 AMQ Streams 指南:

流程

  1. 编辑 KafkaBridge 资源的 spec 属性。

    您可以在以下示例配置中显示您可以配置的属性:

    apiVersion: kafka.strimzi.io/v1beta2
    kind: KafkaBridge
    metadata:
      name: my-bridge
    spec:
      replicas: 3 1
      bootstrapServers: <cluster_name>-cluster-kafka-bootstrap:9092 2
      tls: 3
        trustedCertificates:
          - secretName: my-cluster-cluster-cert
            certificate: ca.crt
          - secretName: my-cluster-cluster-cert
            certificate: ca2.crt
      authentication: 4
        type: tls
        certificateAndKey:
          secretName: my-secret
          certificate: public.crt
          key: private.key
      http: 5
        port: 8080
        cors: 6
          allowedOrigins: "https://strimzi.io"
          allowedMethods: "GET,POST,PUT,DELETE,OPTIONS,PATCH"
      consumer: 7
        config:
          auto.offset.reset: earliest
      producer: 8
        config:
          delivery.timeout.ms: 300000
      resources: 9
        requests:
          cpu: "1"
          memory: 2Gi
        limits:
          cpu: "2"
          memory: 2Gi
      logging: 10
        type: inline
        loggers:
          logger.bridge.level: "INFO"
          # enabling DEBUG just for send operation
          logger.send.name: "http.openapi.operation.send"
          logger.send.level: "DEBUG"
      jvmOptions: 11
        "-Xmx": "1g"
        "-Xms": "1g"
      readinessProbe: 12
        initialDelaySeconds: 15
        timeoutSeconds: 5
      livenessProbe:
        initialDelaySeconds: 15
        timeoutSeconds: 5
      image: my-org/my-image:latest 13
      template: 14
        pod:
          affinity:
            podAntiAffinity:
              requiredDuringSchedulingIgnoredDuringExecution:
                - labelSelector:
                    matchExpressions:
                      - key: application
                        operator: In
                        values:
                          - postgresql
                          - mongodb
                  topologyKey: "kubernetes.io/hostname"
        bridgeContainer: 15
          env:
            - name: JAEGER_SERVICE_NAME
              value: my-jaeger-service
            - name: JAEGER_AGENT_HOST
              value: jaeger-agent-name
            - name: JAEGER_AGENT_PORT
              value: "6831"
    1
    2
    用于连接目标 Kafka 集群的 bootstrap 服务器。使用 Kafka 集群的名称作为 < cluster_name>
    3
    TLS 加密,使用密钥名称,其中 TLS 证书存储为源 Kafka 集群的 X.509 格式。如果证书存储在同一 secret 中,可以多次列出它。
    4
    Kafka Bridge 集群的身份验证,使用 TLS 机制,如此处所示,使用 OAuth bearer 令牌 或基于 SASL 的 SCRAM-SHA-256/SCRAM-SHA-512PLAIN 机制。默认情况下,Kafka Bridge 会在没有身份验证的情况下连接到 Kafka 代理。
    5
    对 Kafka 代理的 HTTP 访问
    6
    CORS 访问 指定所选资源和访问方法。请求中的其他 HTTP 标头描述了允许访问 Kafka 集群的来源。
    7
    8
    9
    用于保留 支持的资源、当前 cpu 和内存 的请求,以及指定可消耗的最大资源数量。
    10
    指定 Kafka Bridge 日志记录器和日志级别 直接(内联)或通过 ConfigMap 间接添加(外部)。自定义 ConfigMap 必须放在 log4j.propertieslog4j2.properties 键下。对于 Kafka Bridge 日志记录器,您可以将日志级别设置为 INFO、ERROR、WARN、TRACE、DEBUG、FATAL 或 OFF。
    11
    JVM 配置选项,用于优化运行 Kafka Bridge 的虚拟机(VM)的性能。
    12
    状况检查,了解何时重启容器(持续)以及容器是否可以接受流量(就绪状态)。
    13
    可选: 容器镜像配置,这只在特殊情况下建议。
    14
    模板自定义。这里调度了带有反关联性的 pod,因此不会将 pod 调度到具有相同主机名的节点。
    15
    还使用 Jaeger 为分布式追踪 设置环境变量。
  2. 创建或更新资源:

    oc apply -f KAFKA-BRIDGE-CONFIG-FILE

2.6.2. Kafka Bridge 集群资源列表

以下资源由 OpenShift 集群中的 Cluster Operator 创建:

bridge-cluster-name-bridge
用于创建 Kafka Bridge worker 节点 pod 的部署。
bridge-cluster-name-bridge-service
此服务公开 Kafka Bridge 集群的 REST 接口。
bridge-cluster-name-bridge-config
包含 Kafka Bridge 辅助配置的 ConfigMap,并由 Kafka 代理 pod 挂载为卷。
bridge-cluster-name-bridge
为 Kafka Bridge worker 节点配置的 Pod Disruption Budget。

2.7. 处理大量消息

如果您的 AMQ Streams 部署需要处理大量信息,您可以使用配置选项来优化吞吐量和延迟。

Kafka producer 和使用者配置可帮助控制对 Kafka 代理的请求的大小和频率。有关配置选项的详情请参考以下内容:

您还可以将相同的配置选项与 Kafka Connect 运行时源连接器(包括 MirrorMaker 2.0)和接收器连接器使用的生产者和消费者使用相同的配置选项。

源连接器
  • Kafka Connect 运行时中的制作者将信息发送到 Kafka 集群。
  • 对于 MirrorMaker 2.0,由于源系统是 Kafka,消费者从源 Kafka 集群检索信息。
sink 连接器
  • Kafka Connect 运行时的使用者从 Kafka 集群检索信息。

对于消费者,您可以增加在单个提取请求中获取的数据量,以减少延迟。您可以使用 fetch.max.bytesmax.partition.fetch.bytes 属性来增加 fetch 请求大小。您还可以使用 max.poll.records 属性针对使用者缓冲区返回的消息数量设置最大限制。

对于 MirrorMaker 2.0,配置 fetch.max.bytesmax.partition.fetch.bytesmax.poll.records 值的来源连接器级别(consumer.*),因为它们与从来源获取消息的特定使用者相关。

对于制作者而言,您可以增加一个生成请求中发送的消息批处理的大小。您可以使用 batch.size 属性来增加批处理大小。较大的批处理大小可减少已发送的未处理消息的数量,以及消息队列中 backlog 的大小。发送到同一分区的消息一起批处理。当达到批处理大小时,生成的请求将发送到目标集群。通过增加批处理大小,生成请求会延迟,更多的消息会添加到批处理中,并同时发送到代理。当您只拥有处理大量消息的几个主题分区时,这可以提高吞吐量。

考虑制作者为适合生产批处理大小处理的记录数和大小。

使用 linger.ms 添加等待时间(以毫秒为单位),以在生产负载减少时延迟生成请求。延迟意味着,如果这些记录在最大批处理大小下,可以向批处理添加更多记录。

在源连接器级别上配置 batch.sizelinger.ms 值(producer.override.*),因为它们与将消息发送到目标 Kafka 集群的特定制作者相关。

对于 Kafka Connect 源连接器,到目标 Kafka 集群的数据流管道如下:

Kafka Connect 源连接器的数据流管道

外部数据源 →(Kafka Connect 任务)源消息队列 → producer buffer → target Kafka topic

对于 Kafka Connect sink 连接器,到目标外部数据源的数据流管道如下:

Kafka Connect sink 连接器的数据流管道

Source Kafka topic →(Kafka Connect tasks) sink 消息队列 → consumer buffer → external 数据源

对于 MirrorMaker 2.0,数据镜像管道到目标 Kafka 集群如下:

MirrorMaker 2.0 的数据镜像管道

Source Kafka topic →(Kafka Connect tasks)源消息队列 → producer buffer → target Kafka topic

制作者在其缓冲中发送消息发送到目标 Kafka 集群中的主题。发生这种情况时,Kafka Connect 任务将继续轮询数据源,以将消息添加到源消息队列中。

源连接器的制作者缓冲区的大小使用 producer.override.buffer.memory 属性来设置。任务等待指定的超时时间(offset.flush.timeout.ms)等待缓冲区被清除。这应该有足够的时间,用于发送的消息被代理和提交偏移数据确认。源任务不会等待制作者在提交偏移之前清空消息队列,但关机期间除外。

如果制作者无法在源消息队列中保留消息吞吐量,则缓冲会被阻断,直到缓冲区内有限制的 max.block.ms 的时间里是否存在空间。在此期间,缓冲区中仍然发送任何未确认的信息。在这些消息被确认并清空前,不会向缓冲区添加新消息。

您可以尝试以下配置更改,将原始消息的基本源消息队列保持在可管理的大小:

  • offset.flush.timeout.ms的毫秒为单位增加默认值
  • 确保有足够的 CPU 和内存资源
  • 通过执行以下操作来增加并行运行的任务数量:

    • 使用 tasksMax 属性增加并行运行的任务数量
    • 使用 replicas 属性增加运行任务的 worker 节点数量

根据可用 CPU 和内存资源和 worker 节点数量,考虑可以并行运行的任务数量。您可能需要调整配置值,直到它们具有所需的效果。

2.7.1. 为高卷信息配置 Kafka 连接

Kafka Connect 从源外部数据系统获取数据,并将其传递给 Kafka Connect 运行时制作者,以便它复制到目标集群。

以下示例显示了使用 KafkaConnect 自定义资源的 Kafka Connect 配置。

处理大量消息的 Kafka 连接配置示例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnect
metadata:
  name: my-connect-cluster
  annotations:
    strimzi.io/use-connector-resources: "true"
spec:
  replicas: 3
  config:
    offset.flush.timeout.ms: 10000
    # ...
  resources:
    requests:
      cpu: "1"
      memory: 2Gi
    limits:
      cpu: "2"
      memory: 2Gi
  # ...

为源连接器添加制作者配置,该连接器通过 KafkaConnector 自定义资源进行管理。

处理大量消息的源连接器配置示例

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:
    producer.override.batch.size: 327680
    producer.override.linger.ms: 100
    # ...

注意

FileStreamSourceConnectorFileStreamSinkConnector 作为示例连接器提供。有关将其部署为 KafkaConnector 资源的信息,请参阅 部署 KafkaConnector 资源

为 sink 连接器添加了消费者配置。

处理大量消息的接收器连接器配置示例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnector
metadata:
  name: my-sink-connector
  labels:
    strimzi.io/cluster: my-connect-cluster
spec:
  class: org.apache.kafka.connect.file.FileStreamSinkConnector
  tasksMax: 2
  config:
    consumer.fetch.max.bytes: 52428800
    consumer.max.partition.fetch.bytes: 1048576
    consumer.max.poll.records: 500
    # ...

如果您使用 Kafka Connect API 而不是 KafkaConnector 自定义资源来管理您的连接器,您可以把连接器配置添加为 JSON 对象。

为处理大量消息的 curl 请求添加源连接器配置示例

curl -X POST \
  http://my-connect-cluster-connect-api:8083/connectors \
  -H 'Content-Type: application/json' \
  -d '{ "name": "my-source-connector",
    "config":
    {
      "connector.class":"org.apache.kafka.connect.file.FileStreamSourceConnector",
      "file": "/opt/kafka/LICENSE",
      "topic":"my-topic",
      "tasksMax": "4",
      "type": "source"
      "producer.override.batch.size": 327680
      "producer.override.linger.ms": 100
    }
}'

2.7.2. 为高卷信息配置 MirrorMaker 2.0

MirrorMaker 2.0 从源集群获取数据并将其写入 Kafka Connect 运行时制作者,以便它复制到目标集群。

以下示例显示了使用 KafkaMirrorMaker2 自定义资源的 MirrorMaker 2.0 的配置。

用于处理大量消息卷的 MirrorMaker 2.0 配置示例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaMirrorMaker2
metadata:
  name: my-mirror-maker2
spec:
  version: 3.2.3
  replicas: 1
  connectCluster: "my-cluster-target"
  clusters:
  - alias: "my-cluster-source"
    bootstrapServers: my-cluster-source-kafka-bootstrap:9092
  - alias: "my-cluster-target"
    config:
      offset.flush.timeout.ms: 10000
    bootstrapServers: my-cluster-target-kafka-bootstrap:9092
  mirrors:
  - sourceCluster: "my-cluster-source"
    targetCluster: "my-cluster-target"
    sourceConnector:
      tasksMax: 2
      config:
        producer.override.batch.size: 327680
        producer.override.linger.ms: 100
        consumer.fetch.max.bytes: 52428800
        consumer.max.partition.fetch.bytes: 1048576
        consumer.max.poll.records: 500
    # ...
  resources:
    requests:
      cpu: "1"
      memory: Gi
    limits:
      cpu: "2"
      memory: 4Gi

2.7.3. 检查 MirrorMaker 2.0 消息流

如果使用 Prometheus 和 Grafana 监控部署,您可以检查 MirrorMaker 2.0 消息流。

AMQ Streams 提供的 MirrorMaker 2.0 Grafana 仪表板示例显示了与 flush 管道相关的以下指标。

  • Kafka Connect 的未处理消息队列中的信息数
  • producer 缓冲的可用字节
  • 偏移提交超时(以毫秒为单位)

您可以使用这些指标来衡量是否需要根据消息卷来调整配置。

2.8. 自定义 OpenShift 资源

AMQ Streams 部署创建 OpenShift 资源,如 DeploymentStatefulSetsPodServices。这些资源由 AMQ Streams operator 管理。只有负责管理特定 OpenShift 资源的 Operator 才能更改该资源。如果您尝试手动更改操作器管理的 OpenShift 资源,Operator 将还原您的更改。

如果要执行某些任务,则更改操作器管理的 OpenShift 资源非常有用,例如:

  • 添加控制 Istio 或其他服务如何处理 Pod 的自定义标签或注解
  • 管理集群如何创建 Loadbalancer-type Services

您可以使用 AMQ Streams 自定义资源中的 template 属性进行更改。以下资源支持 template 属性。API 引用提供有关可自定义字段的更多详情。

在以下示例中,template 属性用于修改 Kafka 代理 pod 中的标签。

模板自定义示例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
  labels:
    app: my-cluster
spec:
  kafka:
    # ...
    template:
      pod:
        metadata:
          labels:
            mylabel: myvalue
    # ...

2.8.1. 自定义镜像拉取策略

AMQ Streams 允许您为 Cluster Operator 部署的所有 pod 中容器自定义镜像拉取策略。镜像拉取策略使用 Cluster Operator 部署中的环境变量 STRIMZI_IMAGE_PULL_POLICY 配置。STRIMZI_IMAGE_PULL_POLICY 环境变量可以设置为三个不同的值:

Always
每次 pod 启动或重启时都会从 registry 中拉取容器镜像。
IfNotPresent
仅当容器镜像没有拉取时,才会从 registry 中拉取容器镜像。
Never
容器镜像从 registry 中拉取。

镜像拉取(pull)策略目前只能自定义所有 Kafka、Kafka Connect 和 Kafka MirrorMaker 集群。更改策略将导致所有 Kafka、Kafka Connect 和 Kafka MirrorMaker 集群滚动更新。

其他资源

2.8.2. 应用终止宽限期

应用终止宽限期,让 Kafka 集群有足够的时间来完全关闭。

使用 terminationGracePeriodSeconds 属性指定时间。将 属性添加到 Kafka 自定义资源的 template.pod 配置中。

您添加的时间将取决于 Kafka 集群的大小。终止宽限期的 OpenShift 默认为 30 秒。如果您发现集群没有完全关闭,您可以提高终止宽限期。

每次 pod 重启时会应用终止宽限期。在 OpenShift 向容器集中运行的进程发送 术语 (终止)信号时,该周期开始。周期应反映将终止 pod 的进程传输到另一个 pod 所需的时间,然后再停止它们。在周期结束后,kill 信号将停止 pod 中仍在运行的任何进程。

以下示例在 Kafka 自定义资源中添加终止宽限期( 120 秒)。您还可以在其他 Kafka 组件的自定义资源中指定配置。

终止宽限期配置示例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    template:
      pod:
        terminationGracePeriodSeconds: 120
        # ...
    # ...

2.9. 配置 pod 调度

当两个应用调度到同一 OpenShift 节点时,两个应用都可能使用相同的资源,如磁盘 I/O 和影响性能。这可能导致性能下降。以避免与其他关键工作负载共享节点的方式调度 Kafka pod,使用正确的节点或只为 Kafka 专用节点集合才是避免此类问题的最佳方法。

2.9.1. 指定关联性、容限和拓扑分布限制

使用关联性、容限和拓扑分布约束,将 kafka 资源的 pod 调度到节点上。关联性、容限和拓扑分布约束通过以下资源中的 关联性容限topologySpreadConstraint 属性进行配置:

  • Kafka.spec.kafka.template.pod
  • Kafka.spec.zookeeper.template.pod
  • Kafka.spec.entityOperator.template.pod
  • KafkaConnect.spec.template.pod
  • KafkaBridge.spec.template.pod
  • KafkaMirrorMaker.spec.template.pod
  • KafkaMirrorMaker2.spec.template.pod

关联性容限topologySpreadConstraint 属性的格式遵循 OpenShift 规格。关联性配置可以包括不同类型的关联性:

  • Pod 关联性和反关联性
  • 节点关联性
注意

在 OpenShift 1.16 和 1.17 上,默认禁用 topologySpreadConstraint 的支持。要使用 topologySpreadConstraint,您必须在 Kubernetes API 服务器和调度程序中启用 EvenPodsSpread 功能门。

2.9.1.1. 使用 pod 反关联性来避免关键应用程序共享节点

使用 pod 反关联性来确保关键应用程序不会调度到同一磁盘上。在运行 Kafka 集群时,建议您使用 pod 反关联性来确保 Kafka 代理不与其他工作负载(如数据库)共享节点。

2.9.1.2. 使用节点关联性将工作负载调度到特定的节点上

OpenShift 集群通常包含许多不同的 worker 节点。有些是针对 CPU 重量工作负载(一些内存)进行了优化,另一些则针对存储(快速本地 SSD)或网络进行优化。使用其他节点有助于优化成本和性能。要实现最佳的性能,务必要调度 AMQ Streams 组件以使用正确的节点。

OpenShift 使用节点关联性将工作负载调度到特定的节点上。节点关联性允许您为要在其上调度 pod 的节点创建调度约束。约束被指定为标签选择器。您可以使用内置的节点标签(如 beta.kubernetes.io/instance-type 或自定义标签)来指定标签,以选择正确的节点。

2.9.1.3. 对专用节点使用节点关联性和容限

使用污点来创建专用节点,然后通过配置节点关联性和容限,在专用节点上调度 Kafka pod。

集群管理员可以将所选 OpenShift 节点标记为污点。污点的节点会排除在常规调度中,普通 pod 不会调度到它们上运行。只有可容许节点上设定的服务才可以调度到节点上。此类节点上运行的唯一其他服务将是日志收集器或定义的网络等系统服务。

在专用节点上运行 Kafka 及其组件会有很多优点。不会在同一节点上运行其他应用程序,这可能会导致距离或消耗 Kafka 所需的资源。这样就可以提高性能和稳定性。

2.9.2. 配置 pod 反关联性以在不同的 worker 节点上调度每个 Kafka 代理

许多 Kafka 代理或 ZooKeeper 节点可以在同一 OpenShift worker 节点上运行。如果 worker 节点失败,它们将同时不可用。要提高可靠性,您可以使用 podAntiAffinity 配置来在不同的 OpenShift worker 节点上调度每个 Kafka 代理或 ZooKeeper 节点。

先决条件

  • OpenShift 集群
  • 正在运行的 Cluster Operator

流程

  1. 编辑指定集群部署的资源中的 affinity 属性。要确定 Kafka 代理或 ZooKeeper 节点没有共享任何 worker 节点,请使用 strimzi.io/name 标签。将 topologyKey 设置为 kubernetes.io/hostname,以指定所选 pod 没有调度到具有相同主机名的节点。这仍然允许同一 worker 节点由单个 Kafka 代理和单个 ZooKeeper 节点共享。例如:

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    spec:
      kafka:
        # ...
        template:
          pod:
            affinity:
              podAntiAffinity:
                requiredDuringSchedulingIgnoredDuringExecution:
                  - labelSelector:
                      matchExpressions:
                        - key: strimzi.io/name
                          operator: In
                          values:
                            - CLUSTER-NAME-kafka
                    topologyKey: "kubernetes.io/hostname"
        # ...
      zookeeper:
        # ...
        template:
          pod:
            affinity:
              podAntiAffinity:
                requiredDuringSchedulingIgnoredDuringExecution:
                  - labelSelector:
                      matchExpressions:
                        - key: strimzi.io/name
                          operator: In
                          values:
                            - CLUSTER-NAME-zookeeper
                    topologyKey: "kubernetes.io/hostname"
        # ...

    其中 CLUSTER-NAME 是 Kafka 自定义资源的名称。

  2. 如果您甚至想确保 Kafka 代理和 ZooKeeper 节点没有共享相同的 worker 节点,请使用 strimzi.io/cluster 标签。例如:

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    spec:
      kafka:
        # ...
        template:
          pod:
            affinity:
              podAntiAffinity:
                requiredDuringSchedulingIgnoredDuringExecution:
                  - labelSelector:
                      matchExpressions:
                        - key: strimzi.io/cluster
                          operator: In
                          values:
                            - CLUSTER-NAME
                    topologyKey: "kubernetes.io/hostname"
        # ...
      zookeeper:
        # ...
        template:
          pod:
            affinity:
              podAntiAffinity:
                requiredDuringSchedulingIgnoredDuringExecution:
                  - labelSelector:
                      matchExpressions:
                        - key: strimzi.io/cluster
                          operator: In
                          values:
                            - CLUSTER-NAME
                    topologyKey: "kubernetes.io/hostname"
        # ...

    其中 CLUSTER-NAME 是 Kafka 自定义资源的名称。

  3. 创建或更新资源。

    oc apply -f <kafka_configuration_file>

2.9.3. 在 Kafka 组件中配置 pod 反关联性

Pod 反关联性配置有助于获取 Kafka 代理的稳定性和性能。通过使用 podAntiAffinity,OpenShift 不会将 Kafka 代理调度到与其他工作负载相同的节点上。通常,您需要避免 Kafka 与其他网络或存储密集型应用程序(如数据库、存储或其他消息传递平台)在同一 worker 节点上运行。

先决条件

  • OpenShift 集群
  • 正在运行的 Cluster Operator

流程

  1. 编辑指定集群部署的资源中的 affinity 属性。使用标签指定不应调度到同一节点上的 pod。topologyKey 应设置为 kubernetes.io/hostname,以指定所选 pod 不应该调度到具有相同主机名的节点。例如:

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    spec:
      kafka:
        # ...
        template:
          pod:
            affinity:
              podAntiAffinity:
                requiredDuringSchedulingIgnoredDuringExecution:
                  - labelSelector:
                      matchExpressions:
                        - key: application
                          operator: In
                          values:
                            - postgresql
                            - mongodb
                    topologyKey: "kubernetes.io/hostname"
        # ...
      zookeeper:
        # ...
  2. 创建或更新资源。

    这可以通过 oc apply 完成:

    oc apply -f <kafka_configuration_file>

2.9.4. 在 Kafka 组件中配置节点关联性

先决条件

  • OpenShift 集群
  • 正在运行的 Cluster Operator

流程

  1. 标记 AMQ Streams 组件应该调度的节点。

    这可以通过 oc label 完成:

    oc label node NAME-OF-NODE node-type=fast-network

    或者,一些现有的标签可能会被重复使用。

  2. 编辑指定集群部署的资源中的 affinity 属性。例如:

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    spec:
      kafka:
        # ...
        template:
          pod:
            affinity:
              nodeAffinity:
                requiredDuringSchedulingIgnoredDuringExecution:
                  nodeSelectorTerms:
                    - matchExpressions:
                      - key: node-type
                        operator: In
                        values:
                        - fast-network
        # ...
      zookeeper:
        # ...
  3. 创建或更新资源。

    这可以通过 oc apply 完成:

    oc apply -f <kafka_configuration_file>

2.9.5. 设置专用节点并在其上调度 pod

先决条件

  • OpenShift 集群
  • 正在运行的 Cluster Operator

流程

  1. 选择应用作专用节点。
  2. 确保这些节点上没有调度任何工作负载。
  3. 在所选节点上设置污点:

    这可以通过 oc adm taint 完成:

    oc adm taint node NAME-OF-NODE dedicated=Kafka:NoSchedule
  4. 另外,还要为所选节点添加标签。

    这可以通过 oc label 完成:

    oc label node NAME-OF-NODE dedicated=Kafka
  5. 编辑指定集群部署的资源中的 关联性容限 属性。

    例如:

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    spec:
      kafka:
        # ...
        template:
          pod:
            tolerations:
              - key: "dedicated"
                operator: "Equal"
                value: "Kafka"
                effect: "NoSchedule"
            affinity:
              nodeAffinity:
                requiredDuringSchedulingIgnoredDuringExecution:
                  nodeSelectorTerms:
                  - matchExpressions:
                    - key: dedicated
                      operator: In
                      values:
                      - Kafka
        # ...
      zookeeper:
        # ...
  6. 创建或更新资源。

    这可以通过 oc apply 完成:

    oc apply -f <kafka_configuration_file>

2.10. 日志记录配置

在 Kafka 组件和 AMQ Streams Operator 的自定义资源中配置日志记录级别。您可以在自定义资源的 spec.logging 属性中指定日志记录级别。或者,您可以使用 configMapKeyRef 属性在自定义资源中引用的 ConfigMap 中定义日志记录属性。

使用 ConfigMap 的优点是,日志记录属性在一个位置进行维护,并可以被多个资源访问。您还可以为多个资源重复使用 ConfigMap。如果使用 ConfigMap 为 AMQ Streams Operator 指定日志记录器,您也可以附加日志记录规格来添加过滤器。

您可以在日志 规格中指定日志记录类型

  • 直接指定日志记录级别时 内联
  • 引用 ConfigMap 时 的外部

内联 日志配置示例

spec:
  # ...
  logging:
    type: inline
    loggers:
      kafka.root.logger.level: "INFO"

外部日志记录 配置示例

spec:
  # ...
  logging:
    type: external
    valueFrom:
      configMapKeyRef:
        name: my-config-map
        key: my-config-map-key

ConfigMap 的 namekey 的值是必需的。如果没有设置 namekey,则会使用默认日志记录。

2.10.1. Kafka 组件和 Operator 的日志记录选项

有关为特定 Kafka 组件或操作员配置日志记录的更多信息,请参见以下部分。

2.10.2. 创建用于日志记录的 ConfigMap

要使用 ConfigMap 定义日志记录属性,您可以创建 ConfigMap,然后将其引用为资源 spec 中的日志记录定义的一部分。

ConfigMap 必须包含适当的日志记录配置。

  • Kafka 组件的 log4j.properties、ZooKeeper 和 Kafka Bridge
  • Topic Operator 和用户 Operator 的 log4j2.properties

配置必须放在这些属性下。

此流程中 ConfigMap 为 Kafka 资源定义根日志记录器。

流程

  1. 创建 ConfigMap。

    您可以将 ConfigMap 创建为 YAML 文件或从属性文件创建。

    带有 Kafka 根日志记录器定义的 ConfigMap 示例:

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: logging-configmap
    data:
      log4j.properties:
        kafka.root.logger.level="INFO"

    如果使用属性文件,请在命令行中指定该文件:

    oc create configmap logging-configmap --from-file=log4j.properties

    属性文件定义日志配置:

    # Define the logger
    kafka.root.logger.level="INFO"
    # ...
  2. 在资源的 spec 中定义 外部日志记录,将 logging.valueFrom.configMapKeyRef.name 设置为 ConfigMap 的名称,并将 logging.valueFrom.configMapKeyRef.key 设置为此 ConfigMap 中的键。

    spec:
      # ...
      logging:
        type: external
        valueFrom:
          configMapKeyRef:
            name: logging-configmap
            key: log4j.properties
  3. 创建或更新资源。

    oc apply -f <kafka_configuration_file>

2.10.3. 在 Operator 中添加日志记录过滤器

如果使用 ConfigMap 为 AMQ Streams Operator 配置(log4j2)日志记录级别,您也可以定义日志记录过滤器来限制日志中返回的内容。

当您有大量日志消息时,日志记录过滤器很有用。假设您将日志记录器的日志级别设置为 DEBUG (rootLogger.level="DEBUG")。日志记录过滤器减少了该级别上为日志记录器返回的日志数量,因此您可以专注于特定的资源。当设置过滤器时,仅记录与过滤器匹配的日志消息。

过滤器使用 标记来指定 在日志中包含的内容。您可以为标记指定 kind、namespace 和 name。例如,如果 Kafka 集群失败,您可以通过将 kind 指定为 Kafka 来隔离日志,并使用失败集群的命名空间和名称。

本例显示了名为 my-kafka-cluster 的 Kafka 集群的标记过滤器。

基本日志记录过滤器配置

rootLogger.level="INFO"
appender.console.filter.filter1.type=MarkerFilter 1
appender.console.filter.filter1.onMatch=ACCEPT 2
appender.console.filter.filter1.onMismatch=DENY 3
appender.console.filter.filter1.marker=Kafka(my-namespace/my-kafka-cluster) 4

1
MarkerFilter 类型比较了指定标记进行过滤。
2
onMatch 属性接受标记匹配的日志。
3
如果标记不匹配,则 onMismatch 属性会拒绝日志。
4
用于过滤的标记格式为 KIND (NAMESPACE/NAME-OF-RESOURCE)

您可以创建一个或多个过滤器。在这里,会针对两个 Kafka 集群过滤日志。

多个日志记录过滤器配置

appender.console.filter.filter1.type=MarkerFilter
appender.console.filter.filter1.onMatch=ACCEPT
appender.console.filter.filter1.onMismatch=DENY
appender.console.filter.filter1.marker=Kafka(my-namespace/my-kafka-cluster-1)
appender.console.filter.filter2.type=MarkerFilter
appender.console.filter.filter2.onMatch=ACCEPT
appender.console.filter.filter2.onMismatch=DENY
appender.console.filter.filter2.marker=Kafka(my-namespace/my-kafka-cluster-2)

在 Cluster Operator 中添加过滤器

要在 Cluster Operator 中添加过滤器,请更新其日志记录 ConfigMap YAML 文件(install/cluster-operator/050-ConfigMap-strimzi-cluster-operator.yaml)。

流程

  1. 更新 050-ConfigMap-strimzi-cluster-operator.yaml 文件,将过滤器属性添加到 ConfigMap 中。

    在本例中,过滤器属性只返回 my-kafka-cluster Kafka 集群的日志:

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: strimzi-cluster-operator
    data:
      log4j2.properties:
        #...
        appender.console.filter.filter1.type=MarkerFilter
        appender.console.filter.filter1.onMatch=ACCEPT
        appender.console.filter.filter1.onMismatch=DENY
        appender.console.filter.filter1.marker=Kafka(my-namespace/my-kafka-cluster)

    或者,直接编辑 ConfigMap

    oc edit configmap strimzi-cluster-operator
  2. 如果您更新了 YAML 文件而不是直接编辑 ConfigMap,通过部署 ConfigMap 来应用更改:

    oc create -f install/cluster-operator/050-ConfigMap-strimzi-cluster-operator.yaml

在 Topic Operator 或 User Operator 中添加过滤器

要在 Topic Operator 或 User Operator 中添加过滤器,请创建或编辑日志记录 ConfigMap。

此流程使用 Topic Operator 的过滤器创建日志记录 ConfigMap。对于 User Operator,使用相同的方法。

流程

  1. 创建 ConfigMap。

    您可以将 ConfigMap 创建为 YAML 文件或从属性文件创建。

    在本例中,过滤器属性只返回 my-topic 主题的日志:

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: logging-configmap
    data:
      log4j2.properties:
        rootLogger.level="INFO"
        appender.console.filter.filter1.type=MarkerFilter
        appender.console.filter.filter1.onMatch=ACCEPT
        appender.console.filter.filter1.onMismatch=DENY
        appender.console.filter.filter1.marker=KafkaTopic(my-namespace/my-topic)

    如果使用属性文件,请在命令行中指定该文件:

    oc create configmap logging-configmap --from-file=log4j2.properties

    属性文件定义日志配置:

    # Define the logger
    rootLogger.level="INFO"
    # Set the filters
    appender.console.filter.filter1.type=MarkerFilter
    appender.console.filter.filter1.onMatch=ACCEPT
    appender.console.filter.filter1.onMismatch=DENY
    appender.console.filter.filter1.marker=KafkaTopic(my-namespace/my-topic)
    # ...
  2. 在资源的 spec 中定义 外部日志记录,将 logging.valueFrom.configMapKeyRef.name 设置为 ConfigMap 的名称,并将 logging.valueFrom.configMapKeyRef.key 设置为此 ConfigMap 中的键。

    对于主题 Operator,日志记录在 Kafka 资源的 topicOperator 配置中指定。

    spec:
      # ...
      entityOperator:
        topicOperator:
          logging:
            type: external
            valueFrom:
              configMapKeyRef:
                name: logging-configmap
                key: log4j2.properties
  3. 通过部署 Cluster Operator 来应用更改:
create -f install/cluster-operator -n my-cluster-operator-namespace

第 3 章 从外部来源加载配置值

使用配置供应商插件从外部来源加载配置数据。供应商独立于 AMQ Streams 运行。您可以使用它们为所有 Kafka 组件(包括生产者和消费者)加载配置数据。例如,使用它们为 Kafka Connect 连接器配置提供凭证。

OpenShift 配置提供程序

OpenShift Configuration Provider 插件从 OpenShift secret 或配置映射加载配置数据。

假设您有一个在 Kafka 命名空间或 Kafka 集群外管理的 Secret 对象。OpenShift Configuration Provider 允许您在不提取文件的情况下引用配置中的机密值。您只需告知供应商使用哪些 secret 并提供访问权限。供应商加载数据而无需重启 Kafka 组件,即使使用新的 SecretConfigMap 对象。此功能可避免在 Kafka Connect 实例托管多个连接器时中断。

环境变量配置提供程序

Environment Variables Configuration Provider 插件从环境变量加载配置数据。

环境变量的值可以从 secret 或配置映射映射。您可以使用 Environment Variables Configuration Provider (如,从 OpenShift secret 映射的环境变量)加载证书或 JAAS 配置。

注意

OpenShift 配置提供程序无法使用已挂载的文件。例如,它无法加载需要信任存储或密钥存储的位置的值。反之,您可以将配置映射或 secret 挂载到 Kafka Connect pod 中,作为环境变量或卷。您可以使用 Environment Variables Configuration Provider 来加载环境变量的值。您可以使用 KafkaConnect.spec 中的 externalConfiguration 属性 添加配置。您不需要通过这种方法设置访问权限。但是,当将新的 SecretConfigMap 用于连接器时,Kafka Connect 将需要重启。这会导致中断所有 Kafka Connect 实例连接器。

3.1. 从配置映射载入配置值

此流程演示了如何使用 OpenShift Configuration Provider 插件。

在此过程中,外部 ConfigMap 对象为连接器提供配置属性。

先决条件

  • OpenShift 集群可用。
  • Kafka 集群正在运行。
  • Cluster Operator 正在运行。

流程

  1. 创建包含配置属性的 ConfigMapSecret

    在本例中,名为 my-connector-configurationConfigMap 对象包含 connector 属性:

    使用连接器属性的 ConfigMap 示例

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: my-connector-configuration
    data:
      option1: value1
      option2: value2

  2. 在 Kafka Connect 配置中指定 OpenShift Configuration Provider。

    此处所示的规格支持从 secret 和配置映射加载值。

    启用 OpenShift Configuration Provider 的 Kafka Connect 配置示例

    apiVersion: kafka.strimzi.io/v1beta2
    kind: KafkaConnect
    metadata:
      name: my-connect
      annotations:
        strimzi.io/use-connector-resources: "true"
    spec:
      # ...
      config:
        # ...
        config.providers: secrets,configmaps 1
        config.providers.secrets.class: io.strimzi.kafka.KubernetesSecretConfigProvider 2
        config.providers.configmaps.class: io.strimzi.kafka.KubernetesConfigMapConfigProvider 3
      # ...

    1
    配置提供程序的别名用于定义其他配置参数。provider 参数使用 config.providers 中的别名,格式为 config.providers.${alias}.class
    2
    KubernetesSecretConfigProvider 提供来自 secret 的值。
    3
    KubernetesConfigMapConfigProvider 提供配置映射的值。
  3. 创建或更新资源以启用该提供程序。

    oc apply -f <kafka_connect_configuration_file>
  4. 创建允许访问外部配置映射中的值的角色。

    从配置映射访问值的角色示例

    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      name: connector-configuration-role
    rules:
    - apiGroups: [""]
      resources: ["configmaps"]
      resourceNames: ["my-connector-configuration"]
      verbs: ["get"]
    # ...

    该规则授予访问 my-connector-configuration 配置映射的角色权限。

  5. 创建一个角色绑定,以允许访问包含配置映射的命名空间。

    访问包含配置映射的命名空间的角色绑定示例

    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      name: connector-configuration-role-binding
    subjects:
    - kind: ServiceAccount
      name: my-connect-connect
      namespace: my-project
    roleRef:
      kind: Role
      name: connector-configuration-role
      apiGroup: rbac.authorization.k8s.io
    # ...

    角色绑定授予访问 my-project 命名空间的角色权限。

    服务帐户必须是 Kafka Connect 部署使用的相同。服务帐户名称格式为 < cluster_name>-connect,其中 <cluster_name > 是 KafkaConnect 自定义资源的名称。

  6. 在连接器配置中引用配置映射。

    引用配置映射的连接器配置示例

    apiVersion: kafka.strimzi.io/v1beta2
    kind: KafkaConnector
    metadata:
      name: my-connector
      labels:
        strimzi.io/cluster: my-connect
    spec:
      # ...
      config:
        option: ${configmaps:my-project/my-connector-configuration:option1}
        # ...
    # ...

    配置映射中属性值的占位符在连接器配置中引用。占位符结构是 configmaps: <path_and_file_name> : & lt;property>KubernetesConfigMapConfigProvider 从外部配置映射读取并提取 option1 属性值。

3.2. 从环境变量载入配置值

此流程演示了如何使用 Environment Variables Configuration Provider 插件。

在此过程中,环境变量为连接器提供配置属性。数据库密码以环境变量的形式指定。

先决条件

  • OpenShift 集群可用。
  • Kafka 集群正在运行。
  • Cluster Operator 正在运行。

流程

  1. 在 Kafka Connect 配置中指定 Environment Variables Configuration Provider。

    使用 externalConfiguration 属性定义 环境变量。

    用于启用 Environment Variables 配置提供程序的 Kafka 连接配置示例

    apiVersion: kafka.strimzi.io/v1beta2
    kind: KafkaConnect
    metadata:
      name: my-connect
      annotations:
        strimzi.io/use-connector-resources: "true"
    spec:
      # ...
      config:
        # ...
        config.providers: env 1
        config.providers.env.class: io.strimzi.kafka.EnvVarConfigProvider 2
      # ...
      externalConfiguration:
        env:
          - name: DB_PASSWORD 3
            valueFrom:
              secretKeyRef:
                name: db-creds 4
                key: dbPassword 5
      # ...

    1
    配置提供程序的别名用于定义其他配置参数。provider 参数使用 config.providers 中的别名,格式为 config.providers.${alias}.class
    2
    EnvVarConfigProvider 提供的环境变量中的值。
    3
    DB_PASSWORD 环境变量取 secret 中的密码值。
    4
    包含预定义密码的 secret 名称。
    5
    存储在机密中的密码的密钥。
  2. 创建或更新资源以启用该提供程序。

    oc apply -f <kafka_connect_configuration_file>
  3. 在连接器配置中引用环境变量。

    引用环境变量的连接器配置示例

    apiVersion: kafka.strimzi.io/v1beta2
    kind: KafkaConnector
    metadata:
      name: my-connector
      labels:
        strimzi.io/cluster: my-connect
    spec:
      # ...
      config:
        option: ${env:DB_PASSWORD}
        # ...
    # ...

第 4 章 访问 OpenShift 集群外的 Kafka

使用外部监听程序将 AMQ Streams Kafka 集群公开给 OpenShift 环境之外的客户端。

指定在外部监听器配置中公开 Kafka 的连接类型

  • nodeport 使用 NodePort 类型 Services
  • LoadBalancer 使用 Loadbalancer 类型 服务
  • Ingress 使用 Kubernetes IngressNGINX Ingress Controller 用于 Kubernetes
  • 路由 使用 OpenShift 路由和 HAProxy 路由器

有关监听器配置的更多信息,请参阅 通用KafkaListener 模式参考

如果要了解有关每种连接类型的代理和配件的更多信息,请参阅 Strimzi 中的访问 Apache Kafka

注意

只有在 OpenShift 中才支持 路由

4.1. 使用节点端口访问 Kafka

此流程描述了如何使用节点端口从外部客户端访问 AMQ Streams Kafka 集群。

要连接到代理,您需要 Kafka bootstrap 地址 的主机名和端口号,以及用于身份验证的证书。

先决条件

  • OpenShift 集群
  • 正在运行的 Cluster Operator

流程

  1. 配置一个 Kafka 资源,并将外部监听程序设置为 nodeport 类型。

    例如:

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    spec:
      kafka:
        # ...
        listeners:
          - name: external
            port: 9094
            type: nodeport
            tls: true
            authentication:
              type: tls
            # ...
        # ...
      zookeeper:
        # ...
  2. 创建或更新资源。

    oc apply -f <kafka_configuration_file>

    为每个 Kafka 代理创建 NodePort 类型服务,以及外部的 bootstrap service。bootstrap 服务将外部流量路由到 Kafka 代理。用于连接的节点地址会被传播到 Kafka 自定义资源 的状态

    在 secret <cluster _name> -cluster-ca-cert 中也创建了用于验证 kafka 代理身份的集群 CA 证书。

  3. 检索您用来从 Kafka 资源状态访问 Kafka 集群的 bootstrap 地址。

    oc get kafka <kafka_cluster_name> -o=jsonpath='{.status.listeners[?(@.name=="<listener_name>")].bootstrapServers}{"\n"}'

    例如:

    oc get kafka my-cluster -o=jsonpath='{.status.listeners[?(@.name=="external")].bootstrapServers}{"\n"}'
  4. 如果启用了 TLS 加密,提取代理证书颁发机构的公共证书。

    oc get secret KAFKA-CLUSTER-NAME-cluster-ca-cert -o jsonpath='{.data.ca\.crt}' | base64 -d > ca.crt

    使用 Kafka 客户端中提取的证书配置 TLS 连接。如果您启用了任何身份验证,您也需要配置 SASL 或 TLS 身份验证。

4.2. 使用负载均衡器访问 Kafka

这个步骤描述了如何使用负载均衡器从外部客户端访问 AMQ Streams Kafka 集群。

要连接到代理,您需要 bootstrap 负载均衡器的地址以及用于 TLS 加密的证书。

先决条件

  • OpenShift 集群
  • 正在运行的 Cluster Operator

流程

  1. 配置一个 Kafka 资源,并将外部监听程序设置为 loadbalancer 类型。

    例如:

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    spec:
      kafka:
        # ...
        listeners:
          - name: external
            port: 9094
            type: loadbalancer
            tls: true
            # ...
        # ...
      zookeeper:
        # ...
  2. 创建或更新资源。

    oc apply -f <kafka_configuration_file>

    为每个 Kafka 代理创建 loadbalancer 类型服务和负载均衡器,以及外部 bootstrap 服务。bootstrap 服务将外部流量路由到所有 Kafka 代理。用于连接的 DNS 名称和 IP 地址会传播到每个 服务的状态

    在 secret <cluster _name> -cluster-ca-cert 中也创建了用于验证 kafka 代理身份的集群 CA 证书。

  3. 检索可用于从 Kafka 资源状态访问 Kafka 集群的 bootstrap 服务地址。

    oc get kafka <kafka_cluster_name> -o=jsonpath='{.status.listeners[?(@.name=="<listener_name>")].bootstrapServers}{"\n"}'

    例如:

    oc get kafka my-cluster -o=jsonpath='{.status.listeners[?(@.name=="external")].bootstrapServers}{"\n"}'
  4. 如果启用了 TLS 加密,提取代理证书颁发机构的公共证书。

    oc get secret KAFKA-CLUSTER-NAME-cluster-ca-cert -o jsonpath='{.data.ca\.crt}' | base64 -d > ca.crt

    使用 Kafka 客户端中提取的证书配置 TLS 连接。如果您启用了任何身份验证,您也需要配置 SASL 或 TLS 身份验证。

4.3. 使用 ingress 访问 Kafka

此流程演示了如何使用 Nginx Ingress 从 OpenShift 外部的外部客户端访问 AMQ Streams Kafka 集群。

要连接到代理,您需要一个主机名(验证地址)用于 Ingress bootstrap 地址,以及用于身份验证的证书。

对于使用 Ingress 的访问,端口始终为 443。

TLS 透传

Kafka 通过 TCP 使用二进制协议,但 Kubernetes 的 NGINX Ingress Controller 设计为用于 HTTP 协议。要通过 Ingress 传递 Kafka 连接,AMQ Streams 使用 NGINX Ingress Controller 的 TLS 透传功能。确保在 NGINX Ingress Controller for Kubernetes 部署中启用了 TLS 透传。

由于它使用 TLS 透传功能,在使用 Ingress 公开 Kafka 时无法禁用 TLS 加密。

有关启用 TLS 透传的更多信息,请参阅 TLS 透传文档

先决条件

流程

  1. 配置 Kafka 资源,并将外部监听程序设置为 入口 类型。

    为 bootstrap 服务和 Kafka 代理指定 Ingress 主机。

    例如:

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    spec:
      kafka:
        # ...
        listeners:
          - name: external
            port: 9094
            type: ingress
            tls: true
            authentication:
              type: tls
            configuration: 1
              bootstrap:
                host: bootstrap.myingress.com
              brokers:
              - broker: 0
                host: broker-0.myingress.com
              - broker: 1
                host: broker-1.myingress.com
              - broker: 2
                host: broker-2.myingress.com
        # ...
      zookeeper:
        # ...
    1
    bootstrap 服务和 Kafka 代理的 Ingress 主机。
  2. 创建或更新资源。

    oc apply -f <kafka_configuration_file>

    为每个 Kafka 代理创建 ClusterIP 类型服务,以及额外的 bootstrap 服务。Ingress 控制器使用这些服务将流量路由到 Kafka 代理。还为每个服务创建一个 Ingress 资源,以使用 Ingress 控制器公开它们。Ingress 主机被传播到每个 服务的状态

    在 secret <cluster _name> -cluster-ca-cert 中也创建了用于验证 kafka 代理身份的集群 CA 证书。

    将您在 Kafka 客户端中的 配置和 端口 443 (BOOTSTRAP-HOST:443)中指定的 bootstrap 主机的地址作为 bootstrap 地址连接到 Kafka 集群。

  3. 提取代理证书颁发机构的公共证书。

    oc get secret KAFKA-CLUSTER-NAME-cluster-ca-cert -o jsonpath='{.data.ca\.crt}' | base64 -d > ca.crt

    使用 Kafka 客户端中提取的证书配置 TLS 连接。如果您启用了任何身份验证,您也需要配置 SASL 或 TLS 身份验证。

4.4. 使用 OpenShift 路由访问 Kafka

此流程描述了如何使用路由从 OpenShift 外部的外部客户端访问 AMQ Streams Kafka 集群。

要连接到代理,您需要一个路由 bootstrap 地址 的主机名,以及用于 TLS 加密的证书。

对于使用路由访问,端口始终为 443。

先决条件

  • OpenShift 集群
  • 正在运行的 Cluster Operator

流程

  1. 配置 Kafka 资源,将外部监听程序设置为 route 类型。

    例如:

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    metadata:
      labels:
        app: my-cluster
      name: my-cluster
      namespace: myproject
    spec:
      kafka:
        # ...
        listeners:
          - name: listener1
            port: 9094
            type: route
            tls: true
            # ...
        # ...
      zookeeper:
        # ...
    警告

    OpenShift Route 地址由 Kafka 集群的名称、侦听器的名称以及在其中创建的命名空间的名称组成。例如,my-cluster-kafka-listener1-bootstrap-myproject (CLUSTER-NAME-kafka-LISTENER-NAME-bootstrap-NAMESPACE)。请注意,地址的整个长度不超过 63 个字符的最大值。

  2. 创建或更新资源。

    oc apply -f <kafka_configuration_file>

    ClusterIP 类型服务为每个 Kafka 代理和外部 bootstrap 服务创建。服务将 OpenShift 路由的流量路由到 Kafka 代理。还为每个服务创建一个 OpenShift Route 资源,以使用 HAProxy 负载均衡器来公开它们。用于连接的 DNS 地址会传播到每个 服务的状态

    在 secret <cluster _name> -cluster-ca-cert 中也创建了用于验证 kafka 代理身份的集群 CA 证书。

  3. 检索可用于从 Kafka 资源状态访问 Kafka 集群的 bootstrap 服务地址。

    oc get kafka <kafka_cluster_name> -o=jsonpath='{.status.listeners[?(@.name=="<listener_name>")].bootstrapServers}{"\n"}'

    例如:

    oc get kafka my-cluster -o=jsonpath='{.status.listeners[?(@.name=="listener1")].bootstrapServers}{"\n"}'
  4. 提取代理证书颁发机构的公共证书。

    oc get secret KAFKA-CLUSTER-NAME-cluster-ca-cert -o jsonpath='{.data.ca\.crt}' | base64 -d > ca.crt

    使用 Kafka 客户端中提取的证书配置 TLS 连接。如果您启用了任何身份验证,您也需要配置 SASL 或 TLS 身份验证。

第 5 章 管理 Kafka 的安全访问

您可以通过管理每个客户端对 Kafka 代理的访问来保护 Kafka 集群。

Kafka 代理和客户端之间的安全连接可以编程:

  • 数据交换加密
  • 证明身份的身份验证
  • 允许或拒绝用户执行操作的授权

本章论述了如何在 Kafka 代理和客户端之间设置安全连接,以及描述:

  • Kafka 集群和客户端的安全选项
  • 如何保护 Kafka 代理
  • 如何将授权服务器用于基于 OAuth 2.0 令牌的身份验证和授权

5.1. Kafka 的安全性选项

使用 Kafka 资源来配置用于 Kafka 身份验证和授权的机制。

5.1.1. 侦听器身份验证

对于 OpenShift 集群中的客户端,您可以创建 普通 (不加密)或 tls 内部 监听程序。对于 OpenShift 集群外的客户端,您可以创建外部监听程序并指定连接机制,可以是 nodeport, loadbalancer, ingress or route(在 OpenShift 中)。

有关连接外部客户端的配置选项的更多信息,请参阅 在 OpenShift 集群外访问 Kafka

支持的身份验证选项:

  1. 双向 TLS 身份验证(仅在启用 TLS 的监听程序中)
  2. SCRAM-SHA-512 身份验证
  3. 基于 OAuth 2.0 令牌的身份验证
  4. 自定义身份验证

您选择的身份验证选项取决于您要如何验证对 Kafka 代理的访问。

注意

在使用自定义身份验证之前,尝试探索标准身份验证选项。自定义身份验证允许任何类型的 kafka 支持的验证。它可以提供更大的灵活性,但也增加了复杂性。

图 5.1. Kafka 侦听器身份验证选项

侦听器身份验证配置的选项

侦听器 身份验证 属性用于指定特定于该侦听器的身份验证机制。

如果没有指定 身份验证 属性,则监听器不会验证通过该侦听器连接的客户端。侦听器将接受所有无身份验证的连接。

在使用 User Operator 管理 KafkaUsers 时,必须配置身份验证。

以下示例显示了:

  • 为 SCRAM-SHA-512 身份验证配置了 普通 侦听器
  • 带有 mutual TLS 身份验证的 tls 侦听器
  • 具有 mutual TLS 身份验证 的外部 监听程序

每个监听程序都配置了 Kafka 集群内的唯一名称和端口。

注意

侦听器无法配置为使用保留代理通信的端口(9091 或 9090)和指标(9404)。

显示监听程序验证配置示例

# ...
listeners:
  - name: plain
    port: 9092
    type: internal
    tls: true
    authentication:
      type: scram-sha-512
  - name: tls
    port: 9093
    type: internal
    tls: true
    authentication:
      type: tls
  - name: external
    port: 9094
    type: loadbalancer
    tls: true
    authentication:
      type: tls
# ...

5.1.1.1. 双向 TLS 身份验证

双向 TLS 身份验证总是用于 Kafka 代理和 ZooKeeper pod 之间的通信。

AMQ Streams 可将 Kafka 配置为使用 TLS (Transport Layer Security)来提供 Kafka 代理和客户端之间的加密通信,或者没有相互身份验证。对于双向身份验证,无论是服务器和客户端均提供证书。当您配置 mutual 身份验证时,代理会验证客户端(客户端身份验证)和客户端验证代理(服务器身份验证)。

注意

TLS 身份验证更为单向,一个方对另一身份进行身份验证。例如,在 Web 浏览器和 Web 服务器之间使用 HTTPS 时,浏览器获取 Web 服务器的身份证明。

5.1.1.2. SCRAM-SHA-512 身份验证

SCRAM (Salted Challenge Response Authentication Mechanism)是一个身份验证协议,可以使用密码建立相互验证。AMQ Streams 可将 Kafka 配置为使用 SASL (Simple Authentication and Security Layer) SCRAM-SHA-512,以在未加密的和加密客户端连接中提供身份验证。

当将 SCRAM-SHA-512 身份验证与 TLS 客户端连接一起使用时,TLS 协议会提供加密,但不用于身份验证。

SCRAM 的以下属性可以安全使用 SCRAM-SHA-512,即使在未加密的连接中:

  • 通过通信频道不会以明文形式发送密码。相反,客户端和服务器都会相互挑战,以便证明他们知道验证用户的密码。
  • 服务器和客户端为每个身份验证交换造成新挑战。这意味着该交换可以应对重播攻击。

KafkaUser.spec.authentication.type 配置有 scram-sha-512 时,用户 Operator 将生成一个由大写和小写 ASCII 字母和数字组成的 12 个字符的随机密码。

5.1.1.3. 网络策略

默认情况下,AMQ Streams 会自动为每个在 Kafka 代理上启用的监听程序创建一个 NetworkPolicy 资源。这个 NetworkPolicy 允许应用程序连接到所有命名空间中的监听程序。使用网络策略作为监听程序配置的一部分。

如果要将网络级别的监听程序的访问权限限制为特定的应用程序或命名空间,请使用 networkPolicyPeers 属性。每个监听程序都有不同的 networkPolicyPeers 配置。有关网络策略对等方法的更多信息,请参阅 NetworkPolicyPeer API 参考

如果要使用自定义网络策略,您可以在 Cluster Operator 配置中将 STRIMZI_NETWORK_POLICY_GENERATION 环境变量设置为 false。如需更多信息,请参阅 Cluster Operator 配置

注意

您的 OpenShift 配置必须支持 ingress NetworkPolicies,以便在 AMQ Streams 中使用网络策略。

5.1.1.4. 其他监听程序配置选项

您可以使用 GenericKafkaListenerConfiguration 模式 的属性,将进一步配置添加到监听程序。

5.1.2. Kafka 授权

您可以使用 Kafka.spec.kafka 资源中的 authorization 属性配置 Kafka 代理的授权。如果缺少 授权 属性,则不会启用授权,并且客户端没有限制。启用后,授权将应用到所有启用的监听程序。授权方法在 type 字段中定义。

支持的授权选项:

图 5.2. Kafka 集群授权选项

kafks 授权配置的选项
5.1.2.1. 超级用户

超级用户可以访问 Kafka 集群中的所有资源,无论访问限制如何,并且受所有授权机制的支持。

要为 Kafka 集群指定超级用户,请在 superUsers 属性中添加一个用户主体列表。如果用户使用 TLS 客户端身份验证,则用户名是其证书主题中以 CN= 前缀的通用名称。

使用超级用户配置示例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
  namespace: myproject
spec:
  kafka:
    # ...
    authorization:
      type: simple
      superUsers:
        - CN=client_1
        - user_2
        - CN=client_3
    # ...

5.2. Kafka 客户端的安全选项

使用 KafkaUser 资源为 Kafka 客户端配置身份验证机制、授权机制和访问权限。在配置安全性方面,客户端以用户表示。

您可以验证并授权用户对 Kafka 代理的访问。身份验证允许访问权限,授权限制对所禁止的操作的访问权限。

您还可以创建对 Kafka 代理没有约束访问的 超级用户

身份验证和授权机制必须与 用于访问 Kafka 代理的监听程序的规格 匹配。

配置用户以保证对 Kafka 代理的访问

有关配置 KafkaUser 资源以安全访问 Kafka 代理的更多信息,请查看以下部分:

5.2.1. 为用户处理识别 Kafka 集群

KafkaUser 资源包含一个标签,它定义了其所属的 Kafka 集群(来自 Kafka 资源名称)的适当名称。

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaUser
metadata:
  name: my-user
  labels:
    strimzi.io/cluster: my-cluster

User Operator 用来识别 KafkaUser 资源并创建新用户,以及后续用户处理过程中使用该标签。

如果标签与 Kafka 集群不匹配,则 User Operator 无法识别 KafkaUser,用户不会被创建。

如果 KafkaUser 资源的状态为空,请检查您的标签。

5.2.2. 用户身份验证

使用 KafkaUser.spec 中的 身份验证 属性配置用户身份验证。使用 type 字段指定用户的验证机制。

支持的验证类型:

  • TLS 用于 TLS 客户端身份验证
  • 使用外部证书进行 TLS 客户端身份验证的 TLS- external
  • SCRAM-sha-512 用于 SCRAM-SHA-512 身份验证

如果指定了 tlsscram-sha-512,则用户 Operator 会在创建用户时创建身份验证凭据。如果指定了 tls-external,用户仍然使用 TLS 客户端身份验证,但没有创建身份验证凭据。当您提供自己的证书时,使用这个选项。如果没有指定验证类型,用户 Operator 不会创建用户或其凭证。

您可以使用 tls-external 使用 User Operator 外部发布的证书进行 TLS 客户端身份验证。User Operator 不会生成 TLS 证书或 secret。您仍然可以通过 User Operator 管理 ACL 规则和配额,其方式与使用 tls 机制相同。这意味着,在指定 ACL 规则和配额时使用 CN=USER-NAME 格式。USER-NAME 是 TLS 证书中提供的常用名称。

5.2.2.1. TLS 客户端身份验证

要使用 TLS 客户端身份验证,请将 KafkaUser 资源中的 type 字段设置为 tls

启用 TLS 客户端身份验证的用户示例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaUser
metadata:
  name: my-user
  labels:
    strimzi.io/cluster: my-cluster
spec:
  authentication:
    type: tls
  # ...

用户由 User Operator 创建时,它会创建一个名为 KafkaUser 资源的名称的新 secret。secret 包含用于 TLS 客户端身份验证的私钥和公钥。公钥包含在用户证书中,由客户端证书颁发机构(CA)签名。

所有密钥都是 X.509 格式。

secret 以 PEM 和 PKCS #12 格式提供私钥和证书。

有关保护 Kafka 与 secret 的通信的更多信息,请参阅 第 10 章 管理 TLS 证书

使用用户凭证的 secret 示例

apiVersion: v1
kind: Secret
metadata:
  name: my-user
  labels:
    strimzi.io/kind: KafkaUser
    strimzi.io/cluster: my-cluster
type: Opaque
data:
  ca.crt: # Public key of the client CA
  user.crt: # User certificate that contains the public key of the user
  user.key: # Private key of the user
  user.p12: # PKCS #12 archive file for storing certificates and keys
  user.password: # Password for protecting the PKCS #12 archive file

5.2.2.2. 使用 User Operator 之外发布的证书进行 TLS 客户端身份验证

要使用 User Operator 之外发布的证书的 TLS 客户端身份验证,请将 KafkaUser 资源中的 type 字段设置为 tls-external。不会为用户创建 secret 和凭证。

带有 TLS 客户端身份验证的用户示例,它使用 User Operator 之外发布的证书

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaUser
metadata:
  name: my-user
  labels:
    strimzi.io/cluster: my-cluster
spec:
  authentication:
    type: tls-external
  # ...

5.2.2.3. SCRAM-SHA-512 身份验证

要使用 SCRAM-SHA-512 身份验证机制,请将 KafkaUser 资源中的 type 字段设置为 scram-sha-512

启用 SCRAM-SHA-512 验证的用户示例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaUser
metadata:
  name: my-user
  labels:
    strimzi.io/cluster: my-cluster
spec:
  authentication:
    type: scram-sha-512
  # ...

用户由 User Operator 创建时,它会创建一个名为 KafkaUser 资源的名称的新 secret。secret 包含在 password 键中生成的密码,该密钥使用 base64 编码。要使用密码,必须解码它。

使用用户凭证的 secret 示例

apiVersion: v1
kind: Secret
metadata:
  name: my-user
  labels:
    strimzi.io/kind: KafkaUser
    strimzi.io/cluster: my-cluster
type: Opaque
data:
  password: Z2VuZXJhdGVkcGFzc3dvcmQ= 1
  sasl.jaas.config: b3JnLmFwYWNoZS5rYWZrYS5jb21tb24uc2VjdXJpdHkuc2NyYW0uU2NyYW1Mb2dpbk1vZHVsZSByZXF1aXJlZCB1c2VybmFtZT0ibXktdXNlciIgcGFzc3dvcmQ9ImdlbmVyYXRlZHBhc3N3b3JkIjsK 2

1
生成的密码 base64 编码。
2
SASL SCRAM-SHA-512 身份验证的 JAAS 配置字符串为 base64 编码。

解码生成的密码:

echo "Z2VuZXJhdGVkcGFzc3dvcmQ=" | base64 --decode
5.2.2.3.1. 自定义密码配置

创建用户时,AMQ Streams 会生成随机密码。您可以使用自己的密码而不是 AMQ Streams 生成的密码。要做到这一点,使用密码创建一个 secret,并在 KafkaUser 资源中引用它。

为 SCRAM-SHA-512 身份验证设置密码的用户示例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaUser
metadata:
  name: my-user
  labels:
    strimzi.io/cluster: my-cluster
spec:
  authentication:
    type: scram-sha-512
    password:
      valueFrom:
        secretKeyRef:
          name: my-secret 1
          key: my-password 2
  # ...

1
包含预定义密码的 secret 名称。
2
存储在机密中的密码的密钥。

5.2.3. 用户授权

用户授权使用 KafkaUser.spec 中的 authorization 属性进行配置。使用 type 字段为用户启用的授权类型。

要使用简单的授权,您可以在 KafkaUser.spec.authorization 中将 type 属性设置为 simple。简单的授权将使用 Kafka Admin API 管理 Kafka 集群内的 ACL 规则。是否启用 User Operator 中的 ACL 管理,还是取决于您的 Kafka 集群中的授权配置。

  • 对于简单的授权,始终启用了 ACL 管理。
  • 对于 OPA 授权,始终禁用 ACL 管理。授权规则在 OPA 服务器中配置。
  • 对于 Red Hat Single Sign-On 授权,您可以直接管理 Red Hat Single Sign-On 中的 ACL 规则。您还可以将授权委派给简单授权器,作为配置中回退选项。当启用对简单授权器委派时,User Operator 也将启用 ACL 规则的管理。
  • 要使用自定义授权插件进行自定义授权,请使用 Kafka 自定义资源的 .spec.kafka.authorization 配置中的 supportsAdminApi 属性来启用或禁用支持。

如果没有启用 ACL managment,AMQ Streams 会在包含任何 ACL 规则时拒绝资源。

如果您使用 User Operator 的独立部署,则默认启用 ACL 管理。您可以使用 STRIMZI_ACLS_ADMIN_API_SUPPORTED 环境变量来禁用它。

如果没有指定授权,则 User Operator 不会为用户置备任何访问权限。这类 KafkaUser 仍然可以访问资源取决于所使用的授权器。例如,对于 AclAuthorizer,这由其 allow.everyone.if.no.acl.found 配置决定。

5.2.3.1. ACL 规则

AclAuthorizer 使用 ACL 规则来管理对 Kafka 代理的访问。

ACL 规则授予您在 acls 属性中指定的用户访问权限。

如需有关 AclRule 对象的更多信息,请参阅 AclRule 模式参考

5.2.3.2. 超级用户访问 Kafka 代理

如果用户添加到 Kafka 代理配置的超级用户列表中,无论 KafkaUser 中的 ACL 中定义的授权限制,用户将允许无限地访问集群。

有关配置超级用户访问代理的更多信息,请参阅 Kafka 授权

5.2.3.3. 用户配额

您可以为 KafkaUser 资源配置 spec 以强制配额,以便用户不超过配置对 Kafka 代理的访问级别。您可以设置基于大小的网络使用量和基于时间的 CPU 利用率阈值。您还可以添加分区变异配额来控制为用户请求接受更改分区的请求的速度。

带有用户配额的 KafkaUser 示例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaUser
metadata:
  name: my-user
  labels:
    strimzi.io/cluster: my-cluster
spec:
  # ...
  quotas:
    producerByteRate: 1048576 1
    consumerByteRate: 2097152 2
    requestPercentage: 55 3
    controllerMutationRate: 10 4

1
用户可以推送到 Kafka 代理的数据量上的字节/秒配额
2
用户可从 Kafka 代理获取的数据量的字节/秒配额
3
CPU 使用率限制为客户端组的时间百分比
4
每秒允许的并发分区创建和删除操作数(mutations)数

有关这些属性的更多信息,请参阅 KafkaUserQuotas 架构参考

5.3. 保护对 Kafka 代理的访问

要建立对 Kafka 代理的安全访问,请配置并应用:

  • Kafka 资源以:

    • 使用指定验证类型创建监听程序
    • 为整个 Kafka 集群配置授权
  • KafkaUser 资源,用于通过监听程序安全地访问 Kafka 代理

配置 Kafka 资源以设置:

  • 侦听器身份验证
  • 限制访问 Kafka 监听器的网络策略
  • Kafka 授权
  • 超级用户禁止对代理的访问

身份验证独立配置每个监听程序。始终为整个 Kafka 集群配置授权。

Cluster Operator 创建监听程序并设置集群和客户端证书颁发机构(CA)证书,以便在 Kafka 集群中启用身份验证。

您可以通过安装 自己的证书 来替换 Cluster Operator 生成的证书。您还可以将 监听程序配置为使用由外部证书颁发机构管理的 Kafka 侦听器证书。证书以 PKCS #12 格式(.p12)和 PEM (.crt)格式提供。

使用 KafkaUser 启用特定客户端用来访问 Kafka 的身份验证和授权机制。

配置 KafkaUser 资源以设置:

  • 与启用的监听程序身份验证匹配的身份验证
  • 与启用的 Kafka 授权匹配的授权
  • 用于控制客户端资源使用的配额

User Operator 根据所选的身份验证类型创建代表客户端和用于客户端身份验证的安全凭证的用户。

有关访问配置属性的更多信息,请参阅架构参考:

5.3.1. 保护 Kafka 代理

此流程显示在运行 AMQ Streams 时保护 Kafka 代理的步骤。

为 Kafka 代理实施的安全必须与需要访问的客户端实施的安全兼容。

  • kafka .spec.kafka.listeners[*].authentication 匹配 KafkaUser.spec.authentication
  • kafka.spec.authorizationKafkaUser.spec.authorization匹配

这些步骤显示,使用 TLS 身份验证进行简单授权和侦听器的配置。有关监听器配置的更多信息,请参阅 通用KafkaListener 模式参考

另外,您可以使用 SCRAM-SHA 或 OAuth 2.0 进行 监听程序身份验证,以及 OAuth 2.0 或 OPA 用于 Kafka 授权

流程

  1. 配置 Kafka 资源。

    1. 配置 授权 属性以进行授权。
    2. 配置 监听程序 属性,以创建具有身份验证的监听程序。

      例如:

      apiVersion: kafka.strimzi.io/v1beta2
      kind: Kafka
      spec:
        kafka:
          # ...
          authorization: 1
            type: simple
            superUsers: 2
              - CN=client_1
              - user_2
              - CN=client_3
          listeners:
            - name: tls
              port: 9093
              type: internal
              tls: true
              authentication:
                type: tls 3
          # ...
        zookeeper:
          # ...
      1
      2
      对 Kafka 有无限访问权限的用户主体列表。在使用 TLS 验证时,CN 是客户端证书的通用名称。
      3
      可以为每个监听器配置监听器验证机制,并将 指定为 mutual TLS、SCRAM-SHA-512 或基于令牌的 OAuth 2.0

      如果您要配置外部监听程序,配置取决于所选的连接机制。

  2. 创建或更新 Kafka 资源。

    oc apply -f <kafka_configuration_file>

    Kafka 集群使用 TLS 身份验证配置 Kafka 代理监听程序。

    为每个 Kafka 代理 pod 创建服务。

    创建服务作为连接到 Kafka 集群的 bootstrap 地址

    在 secret <cluster _name> -cluster-ca-cert 中也创建了用于验证 kafka 代理身份的集群 CA 证书。

5.3.2. 保护用户对 Kafka 的访问

创建或修改 KafkaUser 来代表需要保护 Kafka 集群访问的客户端。

当您配置 KafkaUser 身份验证和授权机制时,请确保它们与对等的 Kafka 配置匹配:

  • KafkaUser.spec.authentication 匹配 Kafka.spec.kafka.listeners[*].authentication
  • KafkaUser.spec.authorization 匹配 Kafka.spec.kafka.authorization

此流程演示了如何使用 TLS 身份验证创建用户。您还可以创建带有 SCRAM-SHA 身份验证的用户。

所需的身份验证取决于 为 Kafka 代理侦听程序配置的 身份验证类型。

注意

Kafka 用户和 Kafka 代理之间的身份验证取决于每个验证设置。例如,如果 Kafka 配置中还没有启用,则无法使用 TLS 验证用户。

先决条件

KafkaUser 中的身份验证类型应与 Kafka 代理中配置的身份验证匹配。

流程

  1. 配置 KafkaUser 资源。

    例如:

    apiVersion: kafka.strimzi.io/v1beta2
    kind: KafkaUser
    metadata:
      name: my-user
      labels:
        strimzi.io/cluster: my-cluster
    spec:
      authentication: 1
        type: tls
      authorization:
        type: simple 2
        acls:
          - resource:
              type: topic
              name: my-topic
              patternType: literal
            operation: Read
          - resource:
              type: topic
              name: my-topic
              patternType: literal
            operation: Describe
          - resource:
              type: group
              name: my-group
              patternType: literal
            operation: Read
    1
    用户身份验证机制,定义为 mutual tlsscram-sha-512
    2
    简单授权,这需要附带 ACL 规则列表。
  2. 创建或更新 KafkaUser 资源。

    oc apply -f <user_config_file>

    创建用户,以及与 KafkaUser 资源名称相同的 Secret。Secret 包含 TLS 客户端身份验证的私钥和公钥。

有关使用属性配置 Kafka 客户端以连接到 Kafka 代理的详情,请参考为 OpenShift 外部的客户端设置访问

5.3.3. 使用网络策略限制 Kafka 侦听程序的访问

您可以使用 networkPolicyPeers 属性将对监听程序的访问限制为特定的应用程序。

先决条件

  • 一个 OpenShift 集群,它支持 Ingress NetworkPolicies。
  • Cluster Operator 正在运行。

流程

  1. 打开 Kafka 资源。
  2. networkPolicyPeers 属性中,定义允许访问 Kafka 集群的应用程序 pod 或命名空间。

    例如,要配置 tls 侦听器,仅允许从带有标签 app 设置为 kafka-client 的应用程序 pod 的连接:

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    spec:
      kafka:
        # ...
        listeners:
          - name: tls
            port: 9093
            type: internal
            tls: true
            authentication:
              type: tls
            networkPolicyPeers:
              - podSelector:
                  matchLabels:
                    app: kafka-client
        # ...
      zookeeper:
        # ...
  3. 创建或更新资源。

    使用 oc apply:

    oc apply -f your-file

5.4. 使用基于 OAuth 2.0 令牌的身份验证

AMQ Streams 支持使用 OAUTHBEARERPLAIN 机制使用 OAuth 2.0 身份验证

OAuth 2.0 支持在应用程序之间标准化基于令牌的身份验证和授权,使用中央授权服务器来发布令牌,以授予对资源的有限访问权限。

您可以配置 OAuth 2.0 身份验证,然后配置 OAuth 2.0 授权

Kafka 代理和客户端都需要配置为使用 OAuth 2.0。OAuth 2.0 身份验证也可以与 简单 或 OPA 的 Kafka 授权 结合使用。

使用基于 OAuth 2.0 令牌的身份验证时,应用程序客户端可以在不公开帐户凭据的情况下访问应用服务器上的资源(称为 资源服务器)。

应用程序客户端以身份验证的方式传递访问令牌,应用程序服务器也可以用于确定要授予的访问权限级别。授权服务器处理访问权限的授予和询问有关访问权限的查询。

在 AMQ Streams 上下文中:

  • Kafka 代理充当 OAuth 2.0 资源服务器
  • Kafka 客户端充当 OAuth 2.0 应用程序客户端

Kafka 客户端对 Kafka 代理进行身份验证。代理和客户端根据需要与 OAuth 2.0 授权服务器通信,以获取或验证访问令牌。

对于 AMQ Streams 的部署,OAuth 2.0 集成提供:

  • 服务器端 OAuth 2.0 支持 Kafka 代理
  • 客户端 OAuth 2.0 支持 Kafka MirrorMaker、Kafka Connect 和 Kafka Bridge

5.4.1. OAuth 2.0 验证机制

AMQ Streams 支持 OAUTHBEARER 和 PLAIN 机制进行 OAuth 2.0 身份验证。这两种机制都允许 Kafka 客户端使用 Kafka 代理建立经过身份验证的会话。客户端、授权服务器和 Kafka 代理之间的身份验证流因每种机制而异。

我们建议您将客户端配置为尽可能使用 OAUTHBEARER。OAUTHBEARER 提供比 PLAIN 更高的安全性,因为客户端凭证 永远不会 与 Kafka 代理共享。考虑仅在不支持 OAUTHBEARER 的 Kafka 客户端中使用 PLAIN。

您可以将 Kafka 代理监听程序配置为使用 OAuth 2.0 身份验证来连接客户端。如果需要,您可以使用同一 oauth 侦听器上的 OAUTHBEARER 和 PLAIN 机制。在 oauth 侦听器配置中明确指定用于支持每种机制的属性。

OAUTHBEARER 概述

OAUTHBEARER 在 oauth 侦听器配置中自动启用用于 Kafka 代理。您可以将 enableOauthBearer 属性设置为 true,尽管不需要这样做。

  # ...
  authentication:
    type: oauth
    # ...
    enableOauthBearer: true

许多 Kafka 客户端工具都使用在协议级别为 OAUTHBEARER 提供基本支持的库。为支持应用程序开发,AMQ Streams 为上游 Kafka 客户端 Java 库提供一个 OAuth 回调处理器 (但不适用于其他库)。因此,您不需要编写自己的回调处理程序。应用客户端可以使用回调处理程序来提供访问令牌。使用 Go 等其他语言编写的客户端必须使用自定义代码连接到授权服务器并获取访问令牌。

使用 OAUTHBEARER 时,客户端发起与 Kafka 代理用于凭证交换的会话,其中凭证采用由回调处理程序提供的 bearer 令牌的形式。使用回调时,您可以使用以下三种方法之一配置令牌置备:

  • 客户端 ID 和 Secret (通过使用 OAuth 2.0 客户端证书 机制)
  • 在配置时手动获取的长期访问令牌
  • 长期刷新令牌,在配置时手动获取
注意

OAUTHBEARER 身份验证只能由 Kafka 客户端用来支持协议级别的 OAUTHBEARER 机制。

PLAIN 概述

要使用 PLAIN,您必须在 Kafka 代理的 oauth 侦听器配置中启用它。

在以下示例中,除了 OAUTHBEARER 外,还启用了 PLAIN (默认启用)。如果您只想使用 PLAIN,您可以通过将 enableOauthBearer 设置为 false 来禁用 OAUTHBEARER。

  # ...
  authentication:
    type: oauth
    # ...
    enablePlain: true
    tokenEndpointUri: https://OAUTH-SERVER-ADDRESS/auth/realms/external/protocol/openid-connect/token

PLAIN 是所有 Kafka 客户端工具使用的简单身份验证机制。要启用 PLAIN 与 OAuth 2.0 身份验证一起使用,AMQ Streams 通过 PLAIN 服务器端回调提供 OAuth 2.0

通过 PLAIN 的 AMQ Streams 实现,客户端凭证不会存储在 ZooKeeper 中。相反,客户端凭证会在兼容的授权服务器集中处理,与使用 OAUTHBEARER 身份验证时类似。

当通过 PLAIN 回调与 OAuth 2.0 一起使用时,Kafka 客户端使用以下任一方法与 Kafka 代理进行身份验证:

  • 客户端 ID 和 secret (使用 OAuth 2.0 客户端证书机制)
  • 在配置时手动获取的长期访问令牌

对于这两种方法,客户端必须提供 PLAIN usernamepassword 属性,以便将凭证传递给 Kafka 代理。客户端使用这些属性来传递客户端 ID 和 secret 或用户名和访问令牌。

客户端 ID 和 secret 用于获取访问令牌。

访问令牌作为 密码 属性值传递。您可以使用 或不使用 $accessToken: 前缀传递访问令牌。

  • 如果您在监听程序配置中配置令牌端点(tokenEndpointUri),则需要使用前缀。
  • 如果您没有在监听器配置中配置令牌端点(tokenEndpointUri),则不需要这个前缀。Kafka 代理将密码解析为原始访问令牌。

如果 密码 被设置为访问令牌,则 用户名 必须设置为 Kafka 代理从访问令牌获取的相同主体名称。您可以使用 userNameClaimfallbackUserNameClaim、fallUsernamePrefixuserInfoEndpointUri 属性在监听程序中指定用户名提取选项。用户名提取过程也取决于您的授权服务器,特别是它如何将客户端 ID 映射到帐户名称。

5.4.2. OAuth 2.0 Kafka 代理配置

OAuth 2.0 的 Kafka 代理配置涉及:

  • 在授权服务器中创建 OAuth 2.0 客户端
  • 在 Kafka 自定义资源中配置 OAuth 2.0 身份验证
注意

与授权服务器的关系,Kafka 代理和 Kafka 客户端都被视为 OAuth 2.0 客户端。

5.4.2.1. 授权服务器上的 OAuth 2.0 客户端配置

要配置 Kafka 代理以验证会话启动期间收到的令牌,建议的做法是在授权服务器中创建一个 OAuth 2.0 client 定义(配置为 confidential),并启用了以下客户端凭证:

  • kafka 的客户端 ID (例如)
  • 客户端 ID 和 Secret 作为身份验证机制
注意

只有在使用授权服务器的非公共内省端点时,才需要使用客户端 ID 和 secret。当使用公共授权服务器端点时,通常会要求凭据,因为快速本地 JWT 令牌验证一样。

5.4.2.2. Kafka 集群中的 OAuth 2.0 身份验证配置

要在 Kafka 集群中使用 OAuth 2.0 身份验证,例如,使用验证方法 oauth 的 Kafka 集群自定义资源的 TLS 侦听器配置:

评估 OAuth 2.0 的身份验证方法类型

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
spec:
  kafka:
    # ...
    listeners:
      - name: tls
        port: 9093
        type: internal
        tls: true
        authentication:
          type: oauth
      #...

您可以配置 plain, tlsexternal 监听程序,但不建议使用带有 OAuth 2.0 禁用了 TLS 加密的 plainexternal 监听程序,因为这会产生一个漏洞,通过令牌对网络造成破坏和未经授权的访问。

您可以使用 type: oauth 为安全传输层配置 外部 监听程序,以便与客户端通信。

将 OAuth 2.0 与外部监听程序搭配使用

# ...
listeners:
  - name: external
    port: 9094
    type: loadbalancer
    tls: true
    authentication:
      type: oauth
    #...

tls 属性默认为 false,因此必须启用它。

当您将身份验证类型定义为 OAuth 2.0 时,您可以根据验证类型添加配置,可以是 快速本地 JWT 验证或利用 内省端点验证的令牌验证

有关为监听程序配置 OAuth 2.0 的步骤,其中描述了 为 Kafka 代理配置 OAuth 2.0 支持

5.4.2.3. 快速本地 JWT 令牌验证配置

快速本地 JWT 令牌验证会在本地检查 JWT 令牌签名。

本地检查可确保令牌:

  • 符合 type,具体为访问令牌包含 Bearer 的(typ)声明值
  • 为有效(不是过期)
  • 具有与 有效IssuerURI匹配的签发者

在配置侦听器时,您可以指定 有效的IssuerURI 属性,以便任何未由授权服务器发布的令牌都会被拒绝。

授权服务器不需要在快速本地 JWT 令牌验证过程中联系。您可以通过指定 jwksEndpointUri 属性(由 OAuth 2.0 授权服务器公开的端点)来激活快速本地 JWT 令牌验证。端点包含用于验证签名的 JWT 令牌的公钥,这些令牌作为 Kafka 客户端作为凭证发送。

注意

与授权服务器的所有通信都应使用 TLS 加密来执行。

您可以在 AMQ Streams 项目命名空间中将证书信任存储配置为 OpenShift Secret,并使用 tlsTrustedCertificates 属性指向包含 truststore 文件的 OpenShift Secret。

您可能需要配置 userNameClaim 来从 JWT 令牌正确提取用户名。如果要使用 Kafka ACL 授权,您需要在验证过程中通过其用户名标识该用户。( JWT 令牌中的 声明通常是唯一 ID,而不是用户名。)

快速本地 JWT 令牌验证配置示例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
spec:
  kafka:
    #...
    listeners:
      - name: tls
        port: 9093
        type: internal
        tls: true
        authentication:
          type: oauth
          validIssuerUri: <https://<auth-server-address>/auth/realms/tls>
          jwksEndpointUri: <https://<auth-server-address>/auth/realms/tls/protocol/openid-connect/certs>
          userNameClaim: preferred_username
          maxSecondsWithoutReauthentication: 3600
          tlsTrustedCertificates:
          - secretName: oauth-server-cert
            certificate: ca.crt
    #...

5.4.2.4. OAuth 2.0 内省端点配置

使用 OAuth 2.0 内省端点验证的令牌验证会将收到的访问令牌视为不透明的。Kafka 代理将访问令牌发送到内省端点,该端点使用验证所需的令牌信息进行响应。重要的是,如果特定的访问令牌有效,它会返回最新的信息,以及令牌过期时的相关信息。

要配置基于 OAuth 2.0 内省验证,您可以指定一个 introspectionEndpointUri 属性,而不是为快速本地 JWT 令牌验证指定的 jwksEndpointUri 属性。根据授权服务器,通常必须指定 clientIdclientSecret,因为内省端点通常受到保护。

内省端点配置示例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
spec:
  kafka:
    listeners:
      - name: tls
        port: 9093
        type: internal
        tls: true
        authentication:
          type: oauth
          clientId: kafka-broker
          clientSecret:
            secretName: my-cluster-oauth
            key: clientSecret
          validIssuerUri: <https://<auth-server-address>/auth/realms/tls>
          introspectionEndpointUri: <https://<auth-server-address>/auth/realms/tls/protocol/openid-connect/token/introspect>
          userNameClaim: preferred_username
          maxSecondsWithoutReauthentication: 3600
          tlsTrustedCertificates:
          - secretName: oauth-server-cert
            certificate: ca.crt

5.4.3. Kafka 代理的会话重新验证

您可以将 oauth 监听程序配置为使用 Kafka 客户端和 Kafka 代理之间的 OAuth 2.0 会话的 Kafka 会话重新验证。这个机制在指定的时间后会强制在客户端和代理之间执行经过身份验证的会话。当会话过期时,客户端会立即通过重复使用现有连接来启动一个新会话,而不是将其丢弃。

默认情况下,会话重新身份验证将被禁用。要启用它,您可以在 oauth 监听器配置中为 maxSecondsWithoutReauthentication 设置一个时间值。同一属性可用于为 OAUTHBEARER 和 PLAIN 身份验证配置会话重新身份验证。如需配置示例,请参阅 第 5.4.6.2 节 “为 Kafka 代理配置 OAuth 2.0 支持”

会话重新身份验证必须由客户端使用的 Kafka 客户端库支持。

会话重新身份验证可用于快速 本地 JWT内省端点 令牌验证。

客户端重新验证

当代理通过身份验证的会话过期时,客户端必须通过向代理发送一个新的有效访问令牌来重新验证到现有会话,而不丢弃连接。

如果令牌验证成功,则使用现有连接启动新的客户端会话。如果客户端无法重新验证,代理会在进一步尝试发送或接收消息时关闭连接。如果使用 Kafka 客户端库 2.2 或更高版本的 Java 客户端,如果代理上启用了 re-authentication 机制,则会自动重新验证。

如果使用,会话重新身份验证也适用于刷新令牌。会话过期时,客户端使用其刷新令牌来刷新访问令牌。然后,客户端使用新的访问令牌来重新验证到现有会话。

有关 OAUTHBEARER 和 PLAIN 的会话过期时间

配置会话重新身份验证后,会话到期工作与 OAUTHBEARER 和 PLAIN 身份验证不同。

对于 OAUTHBEARER 和 PLAIN,请使用客户端 ID 和 secret 方法:

  • 代理的经过身份验证的用户会话将在配置的 maxSeconds withoutReauthentication 下过期。
  • 如果访问令牌在配置的时间前过期,则会话将过期。

对于 PLAIN 使用长期访问令牌方法:

  • 代理的经过身份验证的用户会话将在配置的 maxSeconds withoutReauthentication 下过期。
  • 如果访问令牌在配置的时间之前过期,则重新身份验证将失败。虽然尝试了会话重新身份验证,但 PLAIN 没有刷新令牌的机制。

如果没有配置 maxSecondsWithoutReauthentication,OAUTHBEARER 和 PLAIN 客户端可以无限期地连接到代理,而无需重新验证。经过身份验证的会话不以访问令牌到期。但是,在配置授权时这可被视为被视为使用 keycloak 授权或安装自定义授权器。

5.4.4. OAuth 2.0 Kafka 客户端配置

Kafka 客户端配置有:

  • 从授权服务器获取有效的访问令牌(客户端 ID 和 Secret)所需的凭证
  • 使用授权服务器提供的工具获取有效的长期访问令牌或刷新令牌

发送给 Kafka 代理的唯一信息是访问令牌。用于通过授权服务器进行身份验证的凭据不会发送到代理。

当客户端获取访问令牌时,不需要进一步与授权服务器通信。

最简单的机制是使用客户端 ID 和 Secret 进行身份验证。使用长期的访问令牌或长期刷新令牌会增加复杂性,因为对授权服务器工具有额外的依赖。

注意

如果使用长期的访问令牌,可能需要在授权服务器中配置客户端,以增加令牌的最长生命周期。

如果 Kafka 客户端没有直接配置访问令牌,客户端会在 Kafka 会话通过联系授权服务器发起时交换访问令牌的凭证。Kafka 客户端交换:

  • 客户端 ID 和机密
  • 客户端 ID、刷新令牌和(可选)Secret

5.4.5. OAuth 2.0 客户端验证流程

OAuth 2.0 身份验证流取决于底层 Kafka 客户端和 Kafka 代理配置。该流必须由使用的授权服务器支持。

Kafka 代理监听程序配置决定客户端如何使用访问令牌进行身份验证。客户端可以传递客户端 ID 和机密,以请求访问令牌。

如果侦听器配置为使用 PLAIN 身份验证,客户端可以通过客户端 ID 和 secret 或用户名和访问令牌进行身份验证。这些值作为 PLAIN 机制 usernamepassword 属性传递。

侦听器配置支持以下令牌验证选项:

  • 您可以基于 JWT 签名检查和本地令牌内省使用快速本地令牌验证,而无需联系授权服务器。授权服务器提供了一个 JWKS 端点,其公共证书用于验证令牌上的签名。
  • 您可以使用授权服务器提供的令牌内省端点调用。每次建立新的 Kafka 代理连接时,代理都会将从客户端接收的访问令牌传递给授权服务器。Kafka 代理检查响应,以确认令牌是否有效。
注意

授权服务器可能只允许使用不透明的访问令牌,这意味着无法进行本地令牌验证。

还可以为以下类型的身份验证配置 Kafka 客户端凭证:

  • 使用之前生成的长期访问令牌直接进行本地访问
  • 与授权服务器联系,以获取要发出的新访问令牌(使用客户端 ID 和 secret 或刷新令牌)
5.4.5.1. 使用 SASL OAUTHBEARER 机制的客户端验证流示例

您可以使用 SASL OAUTHBEARER 机制对 Kafka 身份验证使用以下通信流。

使用客户端 ID 和 secret 的客户端,并将验证委派到授权服务器

Client using client ID and secret with broker delegating validation to authorization server

  1. Kafka 客户端使用客户端 ID 和 secret 从授权服务器请求访问令牌,以及可选的刷新令牌。
  2. 授权服务器生成新的访问令牌。
  3. Kafka 客户端使用 SASL OAUTHBEARER 机制通过 Kafka 代理进行身份验证,以传递访问令牌。
  4. Kafka 代理使用自己的客户端 ID 和 secret 调用授权服务器上的令牌内省端点来验证访问令牌。
  5. 如果令牌有效,则建立 Kafka 客户端会话。

使用客户端 ID 和 secret 的客户端,以及执行快速本地令牌验证的代理

Client using client ID and secret with broker performing fast local token validation

  1. Kafka 客户端使用令牌端点的授权服务器验证,使用客户端 ID 和 secret,以及可选的刷新令牌。
  2. 授权服务器生成新的访问令牌。
  3. Kafka 客户端使用 SASL OAUTHBEARER 机制通过 Kafka 代理进行身份验证,以传递访问令牌。
  4. Kafka 代理使用 JWT 令牌签名检查和本地令牌内省在本地验证访问令牌。

使用长期访问令牌的客户端,并将验证委派到授权服务器

Client using long-lived access token with broker delegating validation to authorization server

  1. Kafka 客户端使用 SASL OAUTHBEARER 机制通过 Kafka 代理进行身份验证,以传递长期的访问令牌。
  2. Kafka 代理使用自己的客户端 ID 和 secret 调用授权服务器上的令牌内省端点来验证访问令牌。
  3. 如果令牌有效,则建立 Kafka 客户端会话。

使用长期访问令牌的客户端,以及执行快速本地验证的代理

Client using long-lived access token with broker performing fast local validation

  1. Kafka 客户端使用 SASL OAUTHBEARER 机制通过 Kafka 代理进行身份验证,以传递长期的访问令牌。
  2. Kafka 代理使用 JWT 令牌签名检查和本地令牌内省在本地验证访问令牌。
警告

快速本地 JWT 令牌签名验证仅适用于短传输的令牌,因为如果撤销令牌,则不会检查授权服务器。令牌到期时间写入到令牌中,但可以随时进行撤销,因此无需联系授权服务器即可考虑。任何发出的令牌都将被视为有效,直到它到期为止。

5.4.5.2. 使用 SASL PLAIN 机制的客户端验证流示例

您可以使用 OAuth PLAIN 机制对 Kafka 身份验证使用以下通信流。

使用客户端 ID 和 secret 的客户端,代理获取客户端的访问令牌

Client using a client ID and secret with the broker obtaining the access token for the client

  1. Kafka 客户端以用户名和 secret 作为密码通过 clientId
  2. Kafka 代理使用令牌端点将 clientIdsecret 传递给授权服务器。
  3. 如果客户端凭据无效,授权服务器会返回一个全新的访问令牌或错误。
  4. Kafka 代理使用以下方法之一验证令牌:

    1. 如果指定了令牌内省端点,则 Kafka 代理通过调用授权服务器上的端点来验证访问令牌。如果令牌验证成功,则会建立一个会话。
    2. 如果使用本地令牌内省,则不会向授权服务器发出请求。Kafka 代理使用 JWT 令牌签名检查在本地验证访问令牌。

使用没有客户端 ID 和 secret 的长期访问令牌的客户端

Client using a long-lived access token without a client ID and secret

  1. Kafka 客户端通过用户名和密码。密码提供在运行客户端之前手动和配置的访问令牌的值。
  2. 密码通过 或不使用 $accessToken: 字符串前缀传递,具体取决于 Kafka 代理监听程序配置了用于身份验证的令牌端点。

    1. 如果配置了令牌端点,密码应以 $accessToken: 前缀,以便代理知道 password 参数包含访问令牌而不是客户端 secret。Kafka 代理将用户名解释为帐户用户名。
    2. 如果没有在 Kafka 代理监听器上配置令牌端点(强制使用 no-client-credentials 模式),密码应该提供没有前缀的访问令牌。Kafka 代理将用户名解释为帐户用户名。在这个模式中,客户端不使用客户端 ID 和 secret,密码 参数始终被解释为原始访问令牌。
  3. Kafka 代理使用以下方法之一验证令牌:

    1. 如果指定了令牌内省端点,则 Kafka 代理通过调用授权服务器上的端点来验证访问令牌。如果令牌验证成功,则会建立一个会话。
    2. 如果使用了本地令牌内省,则不会向授权服务器发出请求。Kafka 代理使用 JWT 令牌签名检查在本地验证访问令牌。

5.4.6. 配置 OAuth 2.0 身份验证

OAuth 2.0 用于在 Kafka 客户端和 AMQ Streams 组件间交互。

要将 OAuth 2.0 用于 AMQ Streams,您必须:

5.4.6.1. 配置 OAuth 2.0 授权服务器

这个步骤描述了配置与 AMQ Streams 集成所需的授权服务器的一般信息。

这些说明并非特定于产品。

这些步骤取决于所选授权服务器。有关如何设置 OAuth 2.0 访问的信息,请参阅授权服务器的产品文档。

注意

如果您已经部署了授权服务器,您可以跳过部署步骤并使用当前的部署。

流程

  1. 将授权服务器部署到集群中。
  2. 访问授权服务器的 CLI 或管理控制台,以便为 AMQ Streams 配置 OAuth 2.0。

    现在,准备授权服务器以用于 AMQ Streams。

  3. 配置 kafka-broker 客户端。
  4. 为应用程序的每个 Kafka 客户端组件配置客户端。

接下来要执行的操作

在部署和配置授权服务器后,将 Kafka 代理配置为使用 OAuth 2.0

5.4.6.2. 为 Kafka 代理配置 OAuth 2.0 支持

此流程描述了如何配置 Kafka 代理,以便代理监听程序可以使用授权服务器使用 OAuth 2.0 身份验证。

我们建议通过配置 TLS 监听器在加密接口中使用 OAuth 2.0。不建议使用普通的监听程序。

如果授权服务器使用由可信 CA 签名的证书并匹配 OAuth 2.0 服务器主机名,则 TLS 连接使用默认设置正常工作。否则,您可能需要使用探测器证书或禁用证书主机名验证配置信任存储。

在配置 Kafka 代理时,有两个选项可用于在新连接 Kafka 客户端的 OAuth 2.0 身份验证期间验证访问令牌:

开始前

有关为 Kafka 代理监听程序配置 OAuth 2.0 身份验证的更多信息,请参阅:

先决条件

  • AMQ Streams 和 Kafka 正在运行
  • 已部署了 OAuth 2.0 授权服务器

流程

  1. 在编辑器中更新 Kafka 资源的 Kafka 代理配置(Kafka.spec.kafka)。

    oc edit kafka my-cluster
  2. 配置 Kafka 代理 监听程序 配置。

    每种侦听器的配置不一定是相同的,因为它们是独立的。

    此处的示例显示了为外部监听器配置的配置选项。

    示例 1:配置快速本地 JWT 令牌验证

    #...
    - name: external
      port: 9094
      type: loadbalancer
      tls: true
      authentication:
        type: oauth 1
        validIssuerUri: <https://<auth-server-address>/auth/realms/external> 2
        jwksEndpointUri: <https://<auth-server-address>/auth/realms/external/protocol/openid-connect/certs> 3
        userNameClaim: preferred_username 4
        maxSecondsWithoutReauthentication: 3600 5
        tlsTrustedCertificates: 6
        - secretName: oauth-server-cert
          certificate: ca.crt
        disableTlsHostnameVerification: true 7
        jwksExpirySeconds: 360 8
        jwksRefreshSeconds: 300 9
        jwksMinRefreshPauseSeconds: 1 10

    1
    侦听器类型设置为 oauth
    2
    用于身份验证的令牌签发者的 URI。
    3
    用于本地 JWT 验证的 JWKS 证书端点的 URI。
    4
    在令牌中包含实际用户名的令牌声明(或密钥)。用户名是用于标识用户的 主体userNameClaim 值将取决于身份验证流和使用的授权服务器。
    5
    (可选)激活 Kafka 重新身份验证机制,以强制实施与访问令牌相同的长度。如果指定值小于访问令牌过期的时间,那么客户端必须在实际令牌到期前重新进行身份验证。默认情况下,当访问令牌过期时,会话不会过期,客户端也不会尝试重新身份验证。
    6
    (可选)用于 TLS 连接授权服务器的可信证书。
    7
    (可选)禁用 TLS 主机名验证。默认为 false
    8
    JWKS 证书在过期前被视为有效的持续时间。默认为 360 秒。如果您指定较长的时间,请考虑允许访问撤销证书的风险。
    9
    JWKS 证书刷新之间的周期。间隔必须至少的 60 秒少于到期间隔。默认值为 300 秒。
    10
    连续尝试刷新 JWKS 公钥之间的最短暂停时间(以秒为单位)。当遇到未知签名密钥时,JWKS 键刷新会在常规常规调度外调度,且至少在上次刷新后至少指定暂停。刷新键遵循 exponential backoff 规则,重试失败刷新,并增加暂停,直到它达到 jwksRefreshSeconds。默认值为 1。

    示例 2:使用内省端点配置令牌验证

    - 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> 1
        clientId: kafka-broker 2
        clientSecret: 3
          secretName: my-cluster-oauth
          key: clientSecret
        userNameClaim: preferred_username 4
        maxSecondsWithoutReauthentication: 3600 5

    1
    令牌内省端点的 URI。
    2
    用于标识客户端的客户端 ID。
    3
    客户端 Secret 和客户端 ID 用于身份验证。
    4
    在令牌中包含实际用户名的令牌声明(或密钥)。用户名是用于标识用户的 主体userNameClaim 值将取决于所使用的授权服务器。
    5
    (可选)激活 Kafka 重新身份验证机制,以强制实施与访问令牌相同的长度。如果指定值小于访问令牌过期的时间,那么客户端必须在实际令牌到期前重新进行身份验证。默认情况下,当访问令牌过期时,会话不会过期,客户端也不会尝试重新身份验证。

    根据您应用 OAuth 2.0 身份验证以及授权服务器的类型,您可以使用额外的(可选)配置设置:

      # ...
      authentication:
        type: oauth
        # ...
        checkIssuer: false 1
        checkAudience: true 2
        fallbackUserNameClaim: client_id 3
        fallbackUserNamePrefix: client-account- 4
        validTokenType: bearer 5
        userInfoEndpointUri: https://OAUTH-SERVER-ADDRESS/auth/realms/external/protocol/openid-connect/userinfo 6
        enableOauthBearer: false 7
        enablePlain: true 8
        tokenEndpointUri: https://OAUTH-SERVER-ADDRESS/auth/realms/external/protocol/openid-connect/token 9
        customClaimCheck: "@.custom == 'custom-value'" 10
        clientAudience: AUDIENCE 11
        clientScope: SCOPE 12
        connectTimeoutSeconds: 60 13
        readTimeoutSeconds: 60 14
        groupsClaim: "$.groups" 15
        groupsClaimDelimiter: "," 16
    1
    如果您的授权服务器不提供 声明,则无法执行签发者检查。在这种情况下,将 checkIssuer 设为 false,且不 指定有效的IssuerUri。默认为 true
    2
    如果您的授权服务器 提供了一个ud (udience)申索,并且希望强制执行听众检查,则将 checkAudience 设置为 true。受众检查确定令牌的预期接收者。因此,Kafka 代理将拒绝在其 aud 声明中没有 clientId 的令牌。默认为 false
    3
    授权服务器可能无法提供单一属性来识别常规用户和客户端。当客户端在其自己的名称中进行身份验证时,该服务器可能会提供 客户端 ID。当用户使用用户名和密码进行身份验证时,若要获取刷新令牌或访问令牌,服务器在客户端 ID 之外可能会提供 用户名 属性。如果主用户 ID 属性不可用,则使用此回退选项指定要使用的用户名声明(attribute)。
    4
    在适用 fallbackUserNameClaim 时,可能需要防止用户名声明的值和回退用户名声明之间的名称冲突。例如存在名为 producer 的客户端,但存在一个名为 producer 的普通用户。为了区分这两者,您可以使用此属性为客户端的用户 ID 添加前缀。
    5
    (仅适用于使用 introspectionEndpointUri)取决于您使用的授权服务器,内省端点可能会返回 令牌类型 属性,或者可能包含不同的值。您可以指定来自内省端点要包含的响应的有效令牌类型值。
    6
    (仅适用于使用 introspectionEndpointUri)授权服务器配置或实施,这样在 Introspection Endpoint 响应中不提供任何可识别的信息。要获取用户 ID,您可以将 userinfo 端点的 URI 配置为回退。userNameClaim、freUserNameClaimfallbackUserNamePrefix 设置应用于 userinfo 端点的响应。
    7
    将其设置为 false,以禁用监听器上的 OAUTHBEARER 机制。必须至少启用 PLAIN 或 OAUTHBEARER 之一。默认为 true
    8
    设置为 true,以在监听器上启用 PLAIN 身份验证,在所有平台上的客户端都受支持。
    9
    用于 PLAIN 机制的其他配置。如果指定,客户端可以使用 $accessToken: 前缀将访问令牌作为 密码 传递,通过 PLAIN 进行身份验证。对于生产环境,始终使用 https:// urls。
    10
    可以在验证过程中对 JWT 访问令牌实施额外的自定义规则,方法是将其设置为 JsonPath 过滤器查询。如果访问令牌不包含必要的数据,则会被拒绝。在使用 introspectionEndpointUri 时,自定义检查将应用到内省端点响应 JSON。
    11
    一个 audience 参数传递给令牌端点。在获取用于代理身份验证的访问令牌时,需要使用 使用者。它还使用在 PLAIN 客户端身份验证中使用 clientIdsecret 的 OAuth 2.0 客户端名称。这只会影响获取令牌的能力,以及令牌的内容,具体取决于授权服务器。它不会受到监听程序影响令牌验证规则。
    12
    传递给令牌端点的 scope 参数。获取访问令牌进行代理身份验证时使用的 范围。它还使用在 PLAIN 客户端身份验证中使用 clientIdsecret 的 OAuth 2.0 客户端名称。这只会影响获取令牌的能力,以及令牌的内容,具体取决于授权服务器。它不会受到监听程序影响令牌验证规则。
    13
    连接授权服务器时出现连接超时(以秒为单位)。默认值为 60。
    14
    连接到授权服务器时读取超时(以秒为单位)。默认值为 60。
    15
    JsonPath 查询,用于从 JWT 令牌或内省端点响应中提取组信息。默认情况下不设置。这可以由自定义授权者用来根据用户组做出授权决策。
    16
    以单个分隔字符串返回时用于解析组信息的分隔符。默认值为 ','(comma)。
  3. 保存并退出编辑器,然后等待滚动更新完成。
  4. 检查日志中的更新,或者查看 pod 状态转换:

    oc logs -f ${POD_NAME} -c ${CONTAINER_NAME}
    oc get pod -w

    滚动更新将代理配置为使用 OAuth 2.0 身份验证。

5.4.6.3. 将 Kafka Java 客户端配置为使用 OAuth 2.0

此流程描述了如何配置 Kafka producer 和使用者 API,以使用 OAuth 2.0 与 Kafka 代理交互。

将客户端回调插件添加到您的 pom.xml 文件中,并配置系统属性。

先决条件

  • AMQ Streams 和 Kafka 正在运行
  • OAuth 2.0 授权服务器被部署并为 OAuth 访问 Kafka 代理配置
  • 为 OAuth 2.0 配置 Kafka 代理

流程

  1. 将支持 OAuth 2.0 的客户端程序库添加到 Kafka 客户端的 pom.xml 文件中:

    <dependency>
     <groupId>io.strimzi</groupId>
     <artifactId>kafka-oauth-client</artifactId>
     <version>0.10.0.redhat-00014</version>
    </dependency>
  2. 为回调配置系统属性:

    例如:

    System.setProperty(ClientConfig.OAUTH_TOKEN_ENDPOINT_URI, “https://<auth-server-address>/auth/realms/master/protocol/openid-connect/token”); 1
    System.setProperty(ClientConfig.OAUTH_CLIENT_ID, "<client_name>"); 2
    System.setProperty(ClientConfig.OAUTH_CLIENT_SECRET, "<client_secret>"); 3
    System.setProperty(ClientConfig.OAUTH_SCOPE, "<scope_value>") 4
    System.setProperty(ClientConfig.OAUTH_AUDIENCE, "<audience_value") 5
    1
    授权服务器令牌端点的 URI。
    2
    客户端 ID,这是在授权服务器中创建 客户端 时使用的名称。
    3
    在授权服务器中创建 客户端 secret。
    4
    (可选)从令牌端点请求令牌 的范围。授权服务器可能需要客户端指定范围。
    5
    (可选 用于从令牌端点请求令牌的使用者。授权服务器可能需要客户端指定受众。
  3. 在 Kafka 客户端配置中,在 TLS 加密连接中启用 OAUTHBEARERPLAIN 机制。

    例如:

    为 Kafka 客户端启用 OAUTHBEARER

    props.put("sasl.jaas.config", "org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required;");
    props.put("security.protocol", "SASL_SSL");
    props.put("sasl.mechanism", "OAUTHBEARER");
    props.put("sasl.login.callback.handler.class", "io.strimzi.kafka.oauth.client.JaasClientOauthLoginCallbackHandler");

    为 Kafka 客户端启用 PLAIN

    props.put("sasl.jaas.config", "org.apache.kafka.common.security.plain.PlainLoginModule required username=\"$CLIENT_ID_OR_ACCOUNT_NAME\" password=\"$SECRET_OR_ACCESS_TOKEN\" ;");
    props.put("security.protocol", "SASL_SSL"); 1
    props.put("sasl.mechanism", "PLAIN");

    1
    此处我们使用 SASL_SSL 接管 TLS 连接。仅限本地开发使用 SASL_PLAINTEXT 而不是未加密的连接。
  4. 验证 Kafka 客户端是否可以访问 Kafka 代理。
5.4.6.4. 为 Kafka 组件配置 OAuth 2.0

这个步骤描述了如何使用授权服务器将 Kafka 组件配置为使用 OAuth 2.0 身份验证。

您可以为以下配置身份验证:

  • Kafka Connect
  • Kafka MirrorMaker
  • Kafka Bridge

在这种情况下,Kafka 组件和授权服务器在同一集群中运行。

开始前

如需有关为 Kafka 组件配置 OAuth 2.0 身份验证的更多信息,请参阅:

先决条件

  • AMQ Streams 和 Kafka 正在运行
  • OAuth 2.0 授权服务器被部署并为 OAuth 访问 Kafka 代理配置
  • 为 OAuth 2.0 配置 Kafka 代理

流程

  1. 创建客户端 secret,并将其作为环境变量挂载到组件中。

    例如,我们为 Kafka Bridge 创建客户端 Secret

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Secret
    metadata:
     name: my-bridge-oauth
    type: Opaque
    data:
     clientSecret: MGQ1OTRmMzYtZTllZS00MDY2LWI5OGEtMTM5MzM2NjdlZjQw 1
    1
    clientSecret 键必须采用 base64 格式。
  2. 创建或编辑 Kafka 组件的资源,以便为身份验证属性配置 OAuth 2.0 身份验证。

    对于 OAuth 2.0 身份验证,您可以使用:

    • 客户端 ID 和 secret
    • 客户端 ID 和刷新令牌
    • 访问令牌
    • TLS

    KafkaClientAuthenticationOAuth 模式参考提供了每个 的示例

    例如,这里的 OAuth 2.0 使用客户端 ID 和 secret 分配给 Kafka Bridge 客户端:

    apiVersion: kafka.strimzi.io/v1beta2
    kind: KafkaBridge
    metadata:
      name: my-bridge
    spec:
      # ...
      authentication:
        type: oauth 1
        tokenEndpointUri: https://<auth-server-address>/auth/realms/master/protocol/openid-connect/token 2
        clientId: kafka-bridge
        clientSecret:
          secretName: my-bridge-oauth
          key: clientSecret
        tlsTrustedCertificates: 3
        - secretName: oauth-server-cert
          certificate: tls.crt
    1
    身份验证类型设置为 oauth
    2
    用于身份验证的令牌端点的 URI。
    3
    TLS 连接到授权服务器的可信证书。

    根据您应用 OAuth 2.0 身份验证以及授权服务器的类型,您可以使用其他配置选项:

    # ...
    spec:
      # ...
      authentication:
        # ...
        disableTlsHostnameVerification: true 1
        checkAccessTokenType: false 2
        accessTokenIsJwt: false 3
        scope: any 4
        audience: kafka 5
        connectTimeoutSeconds: 60 6
        readTimeoutSeconds: 60 7
    1
    (可选)禁用 TLS 主机名验证。默认为 false
    2
    如果授权服务器没有在 JWT 令牌中返回 typ (类型)声明,您可以应用 checkAccessTokenType: false 来跳过令牌类型检查。默认为 true
    3
    如果使用不透明令牌,您可以应用 accessTokenIsJwt: false,以便访问令牌不会被视为 JWT 令牌。
    4
    (可选)从令牌端点请求令牌 的范围。授权服务器可能需要客户端指定范围。在这种情况下,它都是 any
    5
    (可选 用于从令牌端点请求令牌的使用者。授权服务器可能需要客户端指定受众。在本例中,是 kafka
    6
    (可选)连接到授权服务器时连接超时(以秒为单位)。默认值为 60。
    7
    (可选)连接到授权服务器时读取超时(以秒为单位)。默认值为 60。
  3. 将更改应用到 Kafka 资源的部署。

    oc apply -f your-file
  4. 检查日志中的更新,或者查看 pod 状态转换:

    oc logs -f ${POD_NAME} -c ${CONTAINER_NAME}
    oc get pod -w

    滚动更新配置组件,以使用 OAuth 2.0 身份验证与 Kafka 代理交互。

5.5. 使用基于 OAuth 2.0 令牌的授权

如果您将 OAuth 2.0 与 Red Hat Single Sign-On 用于基于令牌的身份验证搭配使用,您还可以使用 Red Hat Single Sign-On 配置授权规则来限制客户端对 Kafka 代理的访问。身份验证建立了用户的身份。授权决定该用户的访问权限级别。

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

Red Hat Single Sign-On 中定义的安全策略和权限用于授予对 Kafka 代理上资源的访问权限。用户和客户端与允许对 Kafka 代理执行特定操作的策略进行匹配。

Kafka 默认允许所有用户完全访问代理,并提供 AclAuthorizer 插件来根据访问控制列表(ACL)配置授权。

zookeeper 存储了基于 用户名 授予或拒绝对资源的访问的 ACL 规则。但是,带有 Red Hat Single Sign-On 的 OAuth 2.0 令牌的授权提供了更大的灵活性,有关如何实现对 Kafka 代理的访问控制。另外,您可以将 Kafka 代理配置为使用 OAuth 2.0 授权和 ACL。

5.5.1. OAuth 2.0 授权机制

AMQ Streams 中的 OAuth 2.0 授权使用 Red Hat Single Sign-On 服务器授权服务 REST 端点,通过对特定用户应用定义的安全策略来扩展基于令牌的身份验证,并为该用户提供在不同资源上授予的权限列表。策略使用角色和组将权限与用户匹配。OAuth 2.0 授权根据从 Red Hat Single Sign-On 授权服务的用户列表,在本地强制实施权限。

5.5.1.1. Kafka 代理自定义授权器

Red Hat Single Sign-On authorizer (KeycloakRBACAuthorizer)由 AMQ Streams 提供。要使用由 Red Hat Single Sign-On 提供的授权服务的 Red Hat Single Sign-On REST 端点,您可以在 Kafka 代理上配置自定义授权器。

授权程序根据需要从授权服务器获取授予权限列表,并在 Kafka Broker 本地实施授权,为每个客户端请求做出快速授权决策。

5.5.2. 配置 OAuth 2.0 授权支持

此流程描述了如何使用 Red Hat Single Sign-On Authorization 服务将 Kafka 代理配置为使用 OAuth 2.0 授权。

开始前

考虑某些用户所需的访问权限或希望限制某些用户。您可以结合使用 Red Hat Single Sign-On 角色客户端 和用户,在 Red Hat Single Sign-On 中配置访问权限。

通常,组用于根据机构部门或地理位置匹配用户。和角色用于根据用户的功能匹配。

使用红帽单点登录,您可以将用户和组存储在 LDAP 中,而客户端和服务器不能以这种方式存储。存储和访问用户数据可能是您选择配置授权策略的原因。

注意

无论 Kafka 代理上实施的授权是什么,超级用户 始终对 Kafka 代理没有限制的访问。

先决条件

  • AMQ Streams 必须将 OAuth 2.0 与 Red Hat Single Sign-On 用于 基于令牌的身份验证。设置授权时,您使用相同的红帽单点登录服务器端点。
  • OAuth 2.0 身份验证必须配置有 maxSecondsWithoutReauthentication 选项才能启用 re-authentication。

流程

  1. 访问 Red Hat Single Sign-On Admin Console,或使用 Red Hat Single Sign-On Admin CLI 为设置 OAuth 2.0 身份验证时创建的 Kafka 代理客户端启用授权服务。
  2. 使用授权服务定义客户端的资源、授权范围、策略和权限。
  3. 通过分配角色和组,将权限绑定到用户和客户端。
  4. 通过在编辑器中更新 Kafka 代理配置Kafka.spec.kafka,将 Kafka 代理配置为使用 Red Hat Single Sign-On 授权。

    oc edit kafka my-cluster
  5. 将 Kafka 代理 kafka 配置配置为使用 keycloak 授权,并可以访问授权服务器和授权服务。

    例如:

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    metadata:
      name: my-cluster
    spec:
      kafka:
        # ...
        authorization:
          type: keycloak 1
          tokenEndpointUri: <https://<auth-server-address>/auth/realms/external/protocol/openid-connect/token> 2
          clientId: kafka 3
          delegateToKafkaAcls: false 4
          disableTlsHostnameVerification: false 5
          superUsers: 6
          - CN=fred
          - sam
          - CN=edward
          tlsTrustedCertificates: 7
          - secretName: oauth-server-cert
            certificate: ca.crt
          grantsRefreshPeriodSeconds: 60 8
          grantsRefreshPoolSize: 5 9
          connectTimeoutSeconds: 60 10
          readTimeoutSeconds: 60 11
        #...
    1
    类型 keycloak 启用 Red Hat Single Sign-On 授权。
    2
    Red Hat Single Sign-On 令牌端点的 URI。对于生产环境,始终使用 https:// urls。当您配置基于令牌的 oauth 身份验证时,您可以将 jwksEndpointUri 指定为本地 JWT 验证的 URI。tokenEndpointUri URI 的主机名必须相同。
    3
    在启用了授权服务的 Red Hat Single Sign-On 中的 OAuth 2.0 客户端定义的客户端 ID。通常,kafka 用作 ID。
    4
    (可选)如果 Red Hat Single Sign-On Authorization Services 策略拒绝了访问,则对 Kafka AclAuthorizer 进行策展授权。默认为 false
    5
    (可选)禁用 TLS 主机名验证。默认为 false
    6
    (可选)指定 超级用户
    7
    (可选)用于 TLS 连接授权服务器的可信证书。
    8
    (可选)两个连续授予刷新运行的时间间隔。这是有效会话的最长时间,用于检测 Red Hat Single Sign-On 上用户的任何权限更改。默认值为 60。
    9
    (可选)用于刷新的线程数量(并行)为活跃会话授予。默认值为 5。
    10
    (可选)连接到 Red Hat Single Sign-On 令牌端点时连接超时(以秒为单位)。默认值为 60。
    11
    (可选)连接到 Red Hat Single Sign-On 令牌端点时读取超时(以秒为单位)。默认值为 60。
  6. 保存并退出编辑器,然后等待滚动更新完成。
  7. 检查日志中的更新,或者查看 pod 状态转换:

    oc logs -f ${POD_NAME} -c kafka
    oc get pod -w

    滚动更新将代理配置为使用 OAuth 2.0 授权。

  8. 通过将 Kafka 代理作为特定角色的客户端或用户访问来验证配置的权限,确保它们具有必要的访问权限,或者没有应该具有的访问权限。

5.5.3. 在 Red Hat Single Sign-On Authorization Services 中管理策略和权限

这部分论述了 Red Hat Single Sign-On Authorization Services 和 Kafka 使用的授权模型,并为每个模型定义重要的概念。

要授予访问 Kafka 的权限,您可以通过在 Red Hat Single Sign-Ons 中创建 OAuth 客户端规格,将 Red Hat Single Sign-On 授权服务对象映射到 Kafka 资源。使用 Red Hat Single Sign-On Authorization Services 规则为用户帐户或服务帐户授予 Kafka 权限。

显示常见 Kafka 操作所需的不同用户权限 示例,如创建和列出主题。

5.5.3.1. Kafka 和 Red Hat Single Sign-On 授权模型概述

Kafka 和 Red Hat Single Sign-On 授权服务使用不同的授权模型。

Kafka 授权模型

Kafka 的授权模型使用 资源类型。当 Kafka 客户端对代理执行操作时,代理使用配置的 KeycloakRBACAuthorizer 检查客户端的权限,具体取决于操作和资源类型。

Kafka 使用五个资源类型来控制访问: 主题ClusterTransactionalIdDelegationToken。每个资源类型都有一组可用权限。

Topic

  • 创建
  • 删除
  • describe
  • DescribeConfigs
  • 改变
  • AlterConfigs

  • describe
  • 删除

集群

  • 创建
  • describe
  • 改变
  • DescribeConfigs
  • AlterConfigs
  • IdempotentWrite
  • ClusterAction

TransactionalId

  • describe

DelegationToken

  • describe
Red Hat Single Sign-On 授权服务模型

红帽单点登录授权服务模型有四个定义和授予权限的概念: 资源授权范围策略权限

Resources
资源是一组资源定义,用于匹配允许的操作的资源。资源可能是单独的主题,例如,或者名称以同一前缀开头的所有主题。资源定义与一组可用的授权范围关联,后者代表资源上所有可用操作的集合。通常,实际上只允许这些操作的子集。
授权范围
授权范围是关于特定资源定义的一组所有可用操作。当您定义新资源时,会添加来自所有范围的范围。
策略(policy)

策略是一个授权规则,它使用条件与帐户列表匹配。策略可以匹配:

  • 基于客户端 ID 或角色 的服务帐户
  • 基于用户名、组或角色的 用户帐户
权限
权限向一组用户授予对特定资源定义的授权范围子集。

其他资源

5.5.3.2. 将 Red Hat Single Sign-On 授权服务映射到 Kafka 授权模型

Kafka 授权模型用作定义控制对 Kafka 访问权限的 Red Hat Single Sign-On 角色和资源的基础。

要为用户帐户或服务帐户授予 Kafka 权限,您必须首先在用于 Kafka 代理的 Red Hat Single Sign-On 中创建 OAuth 客户端规格。然后,在客户端上指定 Red Hat Single Sign-On Authorization Services 规则。通常,代表代理的 OAuth 客户端的客户端 ID 是 kafka。带有 AMQ Streams 提供 的示例配置文件 使用 kafka 作为 OAuth 客户端 ID。

注意

如果有多个 Kafka 集群,您可以将单个 OAuth 客户端(kafka)用于所有这些 Kafka 集群。这为您提供了一个可定义和管理授权规则的统一空间。但是,您还可以使用不同的 OAuth 客户端 ID (如 my-cluster-kafkacluster-dev-kafka),并为每个客户端配置中为每个集群定义授权规则。

kafka 客户端定义必须在 Red Hat Single Sign-On Admin 控制台中启用 Authorization Enabled 选项。

所有权限都存在于 kafka 客户端范围内。如果您使用不同的 OAuth 客户端 ID 配置不同的 Kafka 集群,它们各自需要单独的权限集合,即使它们属于同一个 Red Hat Single Sign-On 域。

当 Kafka 客户端使用 OAUTHBEARER 身份验证时,Red Hat Single Sign-On 授权器(KeycloakRBACAuthorizer)使用当前会话的访问令牌来检索从红帽单点登录服务器授予的列表。为检索授权,授权器会评估红帽单点登录授权服务和权限。

Kafka 权限的授权范围

初始的 Red Hat Single Sign-On 配置通常涉及上传授权范围,以创建可在每个 Kafka 资源类型上执行的所有可能操作的列表。只有在定义任何权限前,才会执行此步骤。您可以手动添加授权范围,而不是上传它们。

无论资源类型是什么,授权范围必须包含所有可能的 Kafka 权限:

  • 创建
  • 删除
  • describe
  • 改变
  • DescribeConfig
  • AlterConfig
  • ClusterAction
  • IdempotentWrite
注意

如果您确信不需要权限(例如,IdempotentWrite),您可以从授权范围列表中省略它。但是,该权限不适用于 Kafka 资源的目标。

权限检查的资源模式

在执行权限检查时,资源模式用于与目标资源模式匹配。通用模式格式为 RESOURCE-TYPE:PATTERN-NAME

资源类型镜像 Kafka 授权模型。该模式允许两个匹配选项:

  • 完全匹配(当模式不以 *结尾)
  • 前缀匹配(当模式以 *结尾)

资源模式示例

Topic:my-topic
Topic:orders-*
Group:orders-*
Cluster:*

另外,常规模式格式可以通过 kafka-cluster:CLUSTER-NAME 前缀,后跟一个逗号,其中 CLUSTER-NAME 代表 Kafka 自定义资源中的 metadata.name

带有集群前缀的资源的模式示例

kafka-cluster:my-cluster,Topic:*
kafka-cluster:*,Group:b_*

当缺少 kafka-cluster 前缀时,它会假定为 kafka-cluster:*

在定义资源时,您可以将其与与该资源相关的授权范围列表关联。设置针对目标资源类型采取的任何操作。

虽然您可以将任何授权范围添加到任何资源,但只有资源类型支持的范围才会考虑访问控制。

应用访问权限的策略

策略用于针对一个或多个用户帐户或服务帐户的目标权限。目标可指代:

  • 特定用户或服务帐户
  • realm 角色或客户端角色
  • 用户组
  • 与客户端 IP 地址匹配的 JavaScript 规则

策略被授予唯一名称,可重新利用目标多个资源的权限。

授予访问权限的权限

使用精细权限,将策略、资源和授权范围拉取到一起,并授予用户访问权限。

每个权限的名称应该明确定义它为哪个用户授予哪些权限。例如,开发团队 B 可从以 x 开始的主题读取

其他资源

5.5.3.3. Kafka 操作所需的权限示例

以下示例演示了在 Kafka 上执行常见操作所需的用户权限。

创建主题

要创建主题,特定主题或 Cluster:kafka-cluster 需要 Create 权限。

bin/kafka-topics.sh --create --topic my-topic \
  --bootstrap-server my-cluster-kafka-bootstrap:9092 --command-config=/tmp/config.properties

列出主题

如果用户具有指定主题 的描述 权限,则会列出该主题。

bin/kafka-topics.sh --list \
  --bootstrap-server my-cluster-kafka-bootstrap:9092 --command-config=/tmp/config.properties

显示主题详情

要显示主题详情,在主题上需要 DescribeDescribeConfigs 权限。

bin/kafka-topics.sh --describe --topic my-topic \
  --bootstrap-server my-cluster-kafka-bootstrap:9092 --command-config=/tmp/config.properties

将消息生成到主题

要将消息生成到主题,主题上需要 DescribeWrite 权限。

如果主题尚未创建,并且启用了主题自动创建,则需要创建主题的权限。

bin/kafka-console-producer.sh  --topic my-topic \
  --bootstrap-server my-cluster-kafka-bootstrap:9092 --producer.config=/tmp/config.properties

使用来自主题的消息

为了使用主题中的消息 需要描述和 Read 权限。在主题中使用通常依赖于将消费者偏移存储在消费者组中,这需要对消费者组需要额外的 DescribeRead 权限。

匹配需要两个 资源。例如:

Topic:my-topic
Group:my-group-*
bin/kafka-console-consumer.sh --topic my-topic --group my-group-1 --from-beginning \
  --bootstrap-server my-cluster-kafka-bootstrap:9092 --consumer.config /tmp/config.properties

使用幂等制作者将消息生成到主题

除了生成主题的权限外,集群资源还需要额外的 IdempotentWrite 权限。

匹配需要两个 资源。例如:

Topic:my-topic
Cluster:kafka-cluster
bin/kafka-console-producer.sh  --topic my-topic \
  --bootstrap-server my-cluster-kafka-bootstrap:9092 --producer.config=/tmp/config.properties --producer-property enable.idempotence=true --request-required-acks -1

列出消费者组

在列出消费者组时,只有返回用户具有 描述 权限的组。另外,如果用户对 Cluster:kafka-cluster 具有 Describe 权限,则返回所有消费者组。

bin/kafka-consumer-groups.sh --list \
  --bootstrap-server my-cluster-kafka-bootstrap:9092 --command-config=/tmp/config.properties

显示消费者组详情

要显示消费者组的详情,组必须具有 描述 权限以及与组关联的主题。

bin/kafka-consumer-groups.sh --describe --group my-group-1 \
  --bootstrap-server my-cluster-kafka-bootstrap:9092 --command-config=/tmp/config.properties

更改主题配置

要更改主题的配置,在主题上需要 DescribeAlter 权限。

bin/kafka-topics.sh --alter --topic my-topic --partitions 2 \
  --bootstrap-server my-cluster-kafka-bootstrap:9092 --command-config=/tmp/config.properties

显示 Kafka 代理配置

要使用 kafka-configs.sh 获取代理配置,Cluster:kafka-cluster 上需要 DescribeConfigs 权限。

bin/kafka-configs.sh --entity-type brokers --entity-name 0 --describe --all \
  --bootstrap-server my-cluster-kafka-bootstrap:9092 --command-config=/tmp/config.properties

更改 Kafka 代理配置

要更改 Kafka 代理的配置,Cluster:kafka-cluster 上需要 DescribeConfigsAlterConfigs 权限。

bin/kafka-configs --entity-type brokers --entity-name 0 --alter --add-config log.cleaner.threads=2 \
  --bootstrap-server my-cluster-kafka-bootstrap:9092 --command-config=/tmp/config.properties

删除主题

要删除主题,在主题上需要 DescribeDelete 权限。

bin/kafka-topics.sh --delete --topic my-topic \
  --bootstrap-server my-cluster-kafka-bootstrap:9092 --command-config=/tmp/config.properties

选择潜在客户分区

要运行主题分区的领导选择,Cluster:kafka-cluster 上需要使用 Alter 权限。

bin/kafka-leader-election.sh --topic my-topic --partition 0 --election-type PREFERRED  /
  --bootstrap-server my-cluster-kafka-bootstrap:9092 --admin.config /tmp/config.properties

重新分配分区

要生成分区重新分配文件,相关主题需要 描述 权限。

bin/kafka-reassign-partitions.sh --topics-to-move-json-file /tmp/topics-to-move.json --broker-list "0,1" --generate \
  --bootstrap-server my-cluster-kafka-bootstrap:9092 --command-config /tmp/config.properties > /tmp/partition-reassignment.json

要执行分区重新分配,Cluster:kafka-cluster 上需要 DescribeAlter 权限。另外,有关涉及的主题还需要 描述 权限。

bin/kafka-reassign-partitions.sh --reassignment-json-file /tmp/partition-reassignment.json --execute \
  --bootstrap-server my-cluster-kafka-bootstrap:9092 --command-config /tmp/config.properties

要验证分区重新分配、描述AlterConfigs 权限是 Cluster:kafka-cluster,以及涉及的每个主题所需的权限。

bin/kafka-reassign-partitions.sh --reassignment-json-file /tmp/partition-reassignment.json --verify \
  --bootstrap-server my-cluster-kafka-bootstrap:9092 --command-config /tmp/config.properties

5.5.4. 试用红帽单点登录授权服务

本例解释了如何使用带有 keycloak 授权的红帽单点登录授权服务。使用 Red Hat Single Sign-On Authorization Services 对 Kafka 客户端实施访问限制。红帽单点登录授权服务使用授权范围、策略和权限来定义和应用对资源的访问控制。

Red Hat Single Sign-On Authorization Services REST 端点提供经过身份验证的用户授予资源的权限列表。权限列表从 Red Hat Single Sign-On 服务器获取,作为 Kafka 客户端建立经过身份验证的会话后的第一个操作。该列表在后台刷新,以便检测到对授权的更改。授予在 Kafka 代理上本地缓存并强制每个用户会话提供快速授权决策。

AMQ Streams 提供 示例配置文件。这包括以下用于设置 Red Hat Single Sign-On 的示例文件:

kafka-ephemeral-oauth-single-keycloak-authz.yaml
使用 Red Hat Single Sign-On 为基于 OAuth 2.0 令牌授权配置的 Kafka 自定义资源示例。您可以使用自定义资源部署使用 keycloak 授权和基于令牌的 oauth 身份验证的 Kafka 集群。
kafka-authz-realm.json
红帽单点登录域示例配置了示例组、用户、角色和客户端。您可以将域导入到 Red Hat Single Sign-On 实例,以设置访问 Kafka 的精细权限。

如果要尝试使用 Red Hat Single Sign-On 的示例,请使用这些文件执行本节中所述的任务。

身份验证

当您配置基于令牌的 oauth 身份验证时,您可以将 jwksEndpointUri 指定为本地 JWT 验证的 URI。当您配置 keycloak 授权时,您可以将 tokenEndpointUri 指定为 Red Hat Single Sign-On 令牌端点的 URI。两个 URI 的主机名必须相同。

具有组或角色策略的目标权限

在 Red Hat Single Sign-On 中,启用服务帐户的保密客户端可以使用客户端 ID 和 secret 在其自己的名称中对服务器进行身份验证。对于通常以自己的名称而不是作为特定用户的代理(如网站)的微服务来说,这很方便。服务帐户可以像普通用户一样分配角色。但是,他们不能分配有组。因此,如果要使用服务帐户将权限目标到微服务,则无法使用组策略,而是应使用角色策略。相反,如果您只想将某些权限限制到需要用户名和密码的常规用户帐户,则可利用组策略而不是角色策略作为副作用。这个示例中使用了从 ClusterManager 开始的权限。执行集群管理通常使用 CLI 工具进行。在使用生成的访问令牌向 Kafka 代理进行身份验证前,需要用户登录才需要用户登录。在这种情况下,访问令牌代表特定用户,而不是客户端应用程序。

5.5.4.1. 访问 Red Hat Single Sign-On Admin Console

设置 Red Hat Single Sign-On,然后连接到其管理控制台并添加预配置的域。使用示例 kafka-authz-realm.json 文件导入域。您可以在 Admin 控制台中检查为 realm 定义的授权规则。这些规则授予对 Kafka 集群上的资源的访问权限,以使用 Red Hat Single Sign-On 域示例。

先决条件

  • 一个正常运行的 OpenShift 集群。
  • AMQ Streams 示例/security/keycloak-authorization/kafka-authz-realm.json 文件,该文件包含预先配置的域。

流程

  1. 使用 Red Hat Single Sign-On Operator 安装 Red Hat Single Sign-On 服务器,如 Red Hat Single Sign-On 文档中的服务器安装和配置 中所述。
  2. 等待 Red Hat Single Sign-On 实例处于运行状态。
  3. 获取外部主机名,以访问管理控制台。

    NS=sso
    oc get ingress keycloak -n $NS

    在本例中,我们假定 Red Hat Single Sign-On 服务器正在 sso 命名空间中运行。

  4. 获取 admin 用户的密码。

    oc get -n $NS pod keycloak-0 -o yaml | less

    密码存储为 secret,因此要获取 Red Hat Single Sign-On 实例的配置 YAML 文件,以标识 secret 的名称(secretKeyRef.name)。

  5. 使用 secret 的名称获取明文密码。

    SECRET_NAME=credential-keycloak
    oc get -n $NS secret $SECRET_NAME -o yaml | grep PASSWORD | awk '{print $2}' | base64 -D

    在本例中,我们假定 secret 的名称为 credential-keycloak

  6. 使用您获取的用户名 admin 和密码登录 Admin 控制台。

    使用 https://HOSTNAME 来访问 OpenShift 入口。

    现在,您可以使用 Admin 控制台将示例域上传到 Red Hat Single Sign-On。

  7. 单击 Add Realm 以导入示例域。
  8. 添加 example /security/keycloak-authorization/kafka-authz-realm.json 文件,然后点 Create

    现在,在 Admin 控制台中将 kafka-authz 作为当前域。

    默认视图显示 Master 域。

  9. 在 Red Hat Single Sign-On Admin Console 中,进入 Clients > kafka > Authorization > Settings,并检查是否将 Decision Strategy 设置为 Affirmative

    Affirmative 策略意味着必须满足至少一个策略来访问 Kafka 集群。

  10. 在 Red Hat Single Sign-On Admin Console 中,进入 Groups, Users, RolesClients 来查看 realm 配置。

    用于创建用户组并设置用户权限。组是一组分配了名称的用户。它们用于将用户整理到地理、组织或部门单位。组可以链接到 LDAP 身份提供程序。您可以通过自定义 LDAP 服务器 admin 用户界面使用户成为一个组的成员,例如,授予 Kafka 资源的权限。
    用户
    用户 用于创建用户。在本例中,定义了 alicebobaliceClusterManager 组的成员,bobClusterManager-my-cluster 组的成员。用户可以存储在 LDAP 身份提供程序中。
    角色
    角色 将用户或客户端标记为具有特定权限。角色是与组类似的概念。它们通常用于 为用户授予 组织角色的用户,并具有必要权限。角色不能存储在 LDAP 身份提供程序中。如果需要 LDAP,您可以使用组,并将 Red Hat Single Sign-On 角色添加到组中,以便当用户分配有组时,它们也会获得对应的角色。
    客户端

    客户端 可以有特定的配置。在本例中,配置了 kafka, kafka-cli, team-a-client, 和 team-b-client 客户端。

    • Kafka 代理使用 kafka 客户端来执行访问令牌验证所需的 OAuth 2.0 通信。此客户端还包含用于对 Kafka 代理执行授权的授权服务资源定义、策略和授权范围。授权配置在 Authorization 选项卡的 kafka 客户端中定义,在从 Settings 标签页上切换 Authorization 时,它就会可见。
    • kafka-cli 客户端是在使用用户名和密码进行身份验证时 Kafka 命令行工具使用的公共客户端,以获取访问令牌或刷新令牌。
    • team-a-clientteam-b-client 客户端是负责访问某些 Kafka 主题的部分服务的机密客户端。
  11. 在 Red Hat Single Sign-On Admin Console 中,进入 Authorization > Permissions 以查看使用为域定义的资源和策略授予权限。

    例如,kafka 客户端具有以下权限:

    Dev Team A can write to topics that start with x_ on any cluster
    Dev Team B can read from topics that start with x_ on any cluster
    Dev Team B can update consumer group offsets that start with x_ on any cluster
    ClusterManager of my-cluster Group has full access to cluster config on my-cluster
    ClusterManager of my-cluster Group has full access to consumer groups on my-cluster
    ClusterManager of my-cluster Group has full access to topics on my-cluster
    开发团队 A
    Dev 团队 A realm 角色可以对任何集群上以 x_ 开头的主题进行写入。这将合并了一个名为 Topic:x_*DescribeWrite 范围以及 Dev Team A 策略的资源。Dev 团队 A 策略与具有 realm 角色 Dev Team A 的所有用户匹配。
    Dev Team B
    Dev Team B realm 角色可以从任何集群上的 x_ 开头的主题读取。这结合了 topics:x_*Group:x_* 资源、描述读取 范围以及 Dev Team B 策略。Dev 团队 B 策略与具有名为 Dev Team B 的域角色的所有用户匹配。匹配的用户和客户端能够读取主题,并为以 x_ 开始名称的主题和消费者组更新消耗的偏移量。
5.5.4.2. 使用 Red Hat Single Sign-On 授权部署 Kafka 集群

部署配置为连接到 Red Hat Single Sign-On 服务器的 Kafka 集群。使用示例 kafka-ephemeral-oauth-single-keycloak-authz.yaml 文件将 Kafka 集群部署为 Kafka 自定义资源。这个示例使用 keycloak 授权和 oauth 身份验证部署单节点 Kafka 集群。

先决条件

  • Red Hat Single Sign-On 授权服务器部署到 OpenShift 集群,并使用 example realm 加载。
  • Cluster Operator 已部署到 OpenShift 集群。
  • AMQ Streams example /security/keycloak-authorization/kafka-ephemeral-oauth-single-keycloak-authz.yaml 自定义资源。

流程

  1. 使用您部署的 Red Hat Single Sign-On 实例的主机名,为 Kafka 代理准备信任存储证书,以便与红帽单点登录服务器通信。

    SSO_HOST=SSO-HOSTNAME
    SSO_HOST_PORT=$SSO_HOST:443
    STOREPASS=storepass
    
    echo "Q" | openssl s_client -showcerts -connect $SSO_HOST_PORT 2>/dev/null | awk ' /BEGIN CERTIFICATE/,/END CERTIFICATE/ { print $0 } ' > /tmp/sso.crt

    证书是必需的,因为 OpenShift ingress 用于进行安全(HTTPS)连接。

  2. 将证书作为机密部署到 OpenShift。

    oc create secret generic oauth-server-cert --from-file=/tmp/sso.crt -n $NS
  3. 将主机名设置为环境变量

    SSO_HOST=SSO-HOSTNAME
  4. 创建并部署示例 Kafka 集群。

    cat examples/security/keycloak-authorization/kafka-ephemeral-oauth-single-keycloak-authz.yaml | sed -E 's#\${SSO_HOST}'"#$SSO_HOST#" | oc create -n $NS -f -
5.5.4.3. 为 CLI Kafka 客户端会话准备 TLS 连接

为交互式 CLI 会话创建一个新 pod。使用用于 TLS 连接性的红帽单点登录证书设置信任存储。truststore 连接至 Red Hat Single Sign-On 和 Kafka 代理。

先决条件

  • Red Hat Single Sign-On 授权服务器部署到 OpenShift 集群,并使用 example realm 加载。

    在 Red Hat Single Sign-On Admin Console 中,检查分配给客户端的角色在 Clients > Service Account Roles 中显示。

  • 配置为与 Red Hat Single Sign-On 连接的 Kafka 集群部署到 OpenShift 集群。

流程

  1. 使用 AMQ Streams Kafka 镜像运行一个新的交互式 pod 容器,以连接到正在运行的 Kafka 代理。

    NS=sso
    oc run -ti --restart=Never --image=registry.redhat.io/amq7/amq-streams-kafka-32-rhel8:2.2.2 kafka-cli -n $NS -- /bin/sh
    注意

    如果 oc 超时等待镜像下载,后续尝试可能会导致 AlreadyExists 错误。

  2. 附加到 pod 容器。

    oc attach -ti kafka-cli -n $NS
  3. 使用 Red Hat Single Sign-On 实例的主机名,使用 TLS 为客户端连接准备证书。

    SSO_HOST=SSO-HOSTNAME
    SSO_HOST_PORT=$SSO_HOST:443
    STOREPASS=storepass
    
    echo "Q" | openssl s_client -showcerts -connect $SSO_HOST_PORT 2>/dev/null | awk ' /BEGIN CERTIFICATE/,/END CERTIFICATE/ { print $0 } ' > /tmp/sso.crt
  4. 为与 Kafka 代理的 TLS 连接创建信任存储。

    keytool -keystore /tmp/truststore.p12 -storetype pkcs12 -alias sso -storepass $STOREPASS -import -file /tmp/sso.crt -noprompt
  5. 使用 Kafka bootstrap 地址作为 Kafka 代理的主机名,使用 tls 侦听器端口(9093)为 Kafka 代理准备证书。

    KAFKA_HOST_PORT=my-cluster-kafka-bootstrap:9093
    STOREPASS=storepass
    
    echo "Q" | openssl s_client -showcerts -connect $KAFKA_HOST_PORT 2>/dev/null | awk ' /BEGIN CERTIFICATE/,/END CERTIFICATE/ { print $0 } ' > /tmp/my-cluster-kafka.crt
  6. 将 Kafka 代理的证书添加到 truststore 中。

    keytool -keystore /tmp/truststore.p12 -storetype pkcs12 -alias my-cluster-kafka -storepass $STOREPASS -import -file /tmp/my-cluster-kafka.crt -noprompt

    使会话保持打开以检查授权访问权限。

5.5.4.4. 使用 CLI Kafka 客户端会话检查对 Kafka 的授权访问

通过交互式 CLI 会话检查通过 Red Hat Single Sign-On 域应用的授权规则。使用 Kafka 的示例制作者和使用者客户端应用检查,以创建具有不同访问级别的用户和服务帐户。

使用 team-a-clientteam-b-client 客户端检查授权规则。使用 alice admin 用户在 Kafka 上执行额外的管理任务。

本例中使用的 AMQ Streams Kafka 镜像包含 Kafka producer 和 consumer 二进制文件。

先决条件

设置客户端和 admin 用户配置

  1. 使用 team-a-client 客户端的身份验证属性准备 Kafka 配置文件。

    SSO_HOST=SSO-HOSTNAME
    
    cat > /tmp/team-a-client.properties << EOF
    security.protocol=SASL_SSL
    ssl.truststore.location=/tmp/truststore.p12
    ssl.truststore.password=$STOREPASS
    ssl.truststore.type=PKCS12
    sasl.mechanism=OAUTHBEARER
    sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \
      oauth.client.id="team-a-client" \
      oauth.client.secret="team-a-client-secret" \
      oauth.ssl.truststore.location="/tmp/truststore.p12" \
      oauth.ssl.truststore.password="$STOREPASS" \
      oauth.ssl.truststore.type="PKCS12" \
      oauth.token.endpoint.uri="https://$SSO_HOST/auth/realms/kafka-authz/protocol/openid-connect/token" ;
    sasl.login.callback.handler.class=io.strimzi.kafka.oauth.client.JaasClientOauthLoginCallbackHandler
    EOF

    使用 SASL OAUTHBEARER 机制。这种机制需要客户端 ID 和客户端 secret,这意味着客户端首先连接到 Red Hat Single Sign-On 服务器来获取访问令牌。然后,客户端连接到 Kafka 代理并使用访问令牌进行身份验证。

  2. 准备 Kafka 配置文件,其中包含 team-b-client 客户端的身份验证属性。

    cat > /tmp/team-b-client.properties << EOF
    security.protocol=SASL_SSL
    ssl.truststore.location=/tmp/truststore.p12
    ssl.truststore.password=$STOREPASS
    ssl.truststore.type=PKCS12
    sasl.mechanism=OAUTHBEARER
    sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \
      oauth.client.id="team-b-client" \
      oauth.client.secret="team-b-client-secret" \
      oauth.ssl.truststore.location="/tmp/truststore.p12" \
      oauth.ssl.truststore.password="$STOREPASS" \
      oauth.ssl.truststore.type="PKCS12" \
      oauth.token.endpoint.uri="https://$SSO_HOST/auth/realms/kafka-authz/protocol/openid-connect/token" ;
    sasl.login.callback.handler.class=io.strimzi.kafka.oauth.client.JaasClientOauthLoginCallbackHandler
    EOF
  3. 使用 curl 执行密码授权验证 admin 用户 alice,以获取刷新令牌。

    USERNAME=alice
    PASSWORD=alice-password
    
    GRANT_RESPONSE=$(curl -X POST "https://$SSO_HOST/auth/realms/kafka-authz/protocol/openid-connect/token" -H 'Content-Type: application/x-www-form-urlencoded' -d "grant_type=password&username=$USERNAME&password=$PASSWORD&client_id=kafka-cli&scope=offline_access" -s -k)
    
    REFRESH_TOKEN=$(echo $GRANT_RESPONSE | awk -F "refresh_token\":\"" '{printf $2}' | awk -F "\"" '{printf $1}')

    刷新令牌是一个离线令牌,它是长期的且无法过期。

  4. 使用 admin 用户 alice 的身份验证属性准备 Kafka 配置文件。

    cat > /tmp/alice.properties << EOF
    security.protocol=SASL_SSL
    ssl.truststore.location=/tmp/truststore.p12
    ssl.truststore.password=$STOREPASS
    ssl.truststore.type=PKCS12
    sasl.mechanism=OAUTHBEARER
    sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \
      oauth.refresh.token="$REFRESH_TOKEN" \
      oauth.client.id="kafka-cli" \
      oauth.ssl.truststore.location="/tmp/truststore.p12" \
      oauth.ssl.truststore.password="$STOREPASS" \
      oauth.ssl.truststore.type="PKCS12" \
      oauth.token.endpoint.uri="https://$SSO_HOST/auth/realms/kafka-authz/protocol/openid-connect/token" ;
    sasl.login.callback.handler.class=io.strimzi.kafka.oauth.client.JaasClientOauthLoginCallbackHandler
    EOF

    kafka-cli 公共客户端用于 sasl.jaas.config 中的 oauth.client.id。由于这是不需要机密的公共客户端。客户端使用上一步中通过身份验证的刷新令牌进行身份验证。刷新令牌会在 scenes 后面请求访问令牌,然后将其发送到 Kafka 代理以进行身份验证。

生成具有授权访问权限的消息

使用 team-a-client 配置检查您可以生成消息到以 a_x_ 开头的主题。

  1. 将 写入到主题 my-topic

    bin/kafka-console-producer.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --topic my-topic \
      --producer.config=/tmp/team-a-client.properties
    First message

    此请求返回 Not authorized 以访问主题:[my-topic] 错误。

    team-a-client 具有 Dev Team A 角色,它有权对以 a_ 开头的主题执行任何受支持操作,但只能写入以 x_ 开头的主题。名为 my-topic 的主题都匹配这些规则。

  2. 将 写入到主题 a_messages

    bin/kafka-console-producer.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --topic a_messages \
      --producer.config /tmp/team-a-client.properties
    First message
    Second message

    在 Kafka 中成功生成信息。

  3. 按 CTRL+C 退出 CLI 应用程序。
  4. 检查 Kafka 容器日志,获取请求的 Authorization GRANTED 的 debug 日志。

    oc logs my-cluster-kafka-0 -f -n $NS

使用具有授权访问权限的消息

使用 team-a-client 配置来消耗主题 a_messages 中的消息。

  1. 从主题 a_messages 获取消息。

    bin/kafka-console-consumer.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --topic a_messages \
      --from-beginning --consumer.config /tmp/team-a-client.properties

    该请求会返回一个错误,因为 team-a-clientDev Team A 角色只能访问具有以 _ 开始名称的消费者组。

  2. 更新 team-a-client 属性,以指定允许使用的自定义使用者组。

    bin/kafka-console-consumer.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --topic a_messages \
      --from-beginning --consumer.config /tmp/team-a-client.properties --group a_consumer_group_1

    使用者接收来自 a_messages 主题的所有消息。

使用授权访问权限管理 Kafka

team-a-client 是一个没有集群级别访问权限的帐户,但它可用于一些管理操作。

  1. 列出主题。

    bin/kafka-topics.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --command-config /tmp/team-a-client.properties --list

    返回 a_messages 主题。

  2. 列出使用者组。

    bin/kafka-consumer-groups.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --command-config /tmp/team-a-client.properties --list

    a_consumer_group_1 consumer 组返回。

    获取集群配置的详情。

    bin/kafka-configs.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --command-config /tmp/team-a-client.properties \
      --entity-type brokers --describe --entity-default

    请求返回一个错误,因为操作需要 team-a-client 没有集群级别权限。

使用具有不同权限的客户端

使用 team-b-client 配置向以 b_ 开头的主题生成消息。

  1. 将 写入到主题 a_messages

    bin/kafka-console-producer.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --topic a_messages \
      --producer.config /tmp/team-b-client.properties
    Message 1

    此请求返回 Not authorized 以访问主题:[a_messages] 错误。

  2. 将主题 b_messages 写入主题。

    bin/kafka-console-producer.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --topic b_messages \
      --producer.config /tmp/team-b-client.properties
    Message 1
    Message 2
    Message 3

    在 Kafka 中成功生成信息。

  3. 将 写入到主题 x_messages

    bin/kafka-console-producer.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --topic x_messages \
      --producer.config /tmp/team-b-client.properties
    Message 1

    不授权访问主题:[x_messages] 错误将返回,team-b-client 只能从主题 x_messages 中读取。

  4. 使用 team-a-client 写入主题 x_messages

    bin/kafka-console-producer.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --topic x_messages \
      --producer.config /tmp/team-a-client.properties
    Message 1

    此请求返回 Not authorized 以访问主题:[x_messages] 错误。team-a-client 可以写入 x_messages 主题,但如果不存在,则没有创建主题的权限。在 team-a-client 可以写入 x_messages 主题之前,管理员 高级用户 必须通过正确的配置创建它,如分区和副本的数量。

使用授权 admin 用户管理 Kafka

使用 admin 用户 alice 管理 Kafka。alice 具有管理任何 Kafka 集群上的所有内容的完整访问权限。

  1. alice 身份创建 x_messages 主题。

    bin/kafka-topics.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --command-config /tmp/alice.properties \
      --topic x_messages --create --replication-factor 1 --partitions 1

    主题创建成功。

  2. 列出所有主题为 alice

    bin/kafka-topics.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --command-config /tmp/alice.properties --list
    bin/kafka-topics.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --command-config /tmp/team-a-client.properties --list
    bin/kafka-topics.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --command-config /tmp/team-b-client.properties --list

    admin 用户 alice 可以列出所有主题,而 team-a-clientteam-b-client 只能列出它们可访问的主题。

    Dev 团队 ADev Team B 角色都 描述x_ 开头的主题,但它们无法看到其他组的主题,因为它们没有 描述 权限。

  3. 使用 team-a-clientx_messages 主题生成信息:

    bin/kafka-console-producer.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --topic x_messages \
      --producer.config /tmp/team-a-client.properties
    Message 1
    Message 2
    Message 3

    因为 alice 创建 x_messages 主题,因此成功生成给 Kafka 的信息。

  4. 使用 team-b-clientx_messages 主题生成消息。

    bin/kafka-console-producer.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --topic x_messages \
      --producer.config /tmp/team-b-client.properties
    Message 4
    Message 5

    此请求返回 Not authorized 以访问主题:[x_messages] 错误。

  5. 使用 team-b-client 使用 x_messages 主题的消息:

    bin/kafka-console-consumer.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --topic x_messages \
      --from-beginning --consumer.config /tmp/team-b-client.properties --group x_consumer_group_b

    使用者接收来自 x_messages 主题的所有消息。

  6. 使用 team-a-client 使用 x_messages 主题的消息。

    bin/kafka-console-consumer.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --topic x_messages \
      --from-beginning --consumer.config /tmp/team-a-client.properties --group x_consumer_group_a

    此请求返回 Not authorized 以访问主题:[x_messages] 错误。

  7. 使用 team-a-client 使用以 _ 开头的消费者组的消息。

    bin/kafka-console-consumer.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --topic x_messages \
      --from-beginning --consumer.config /tmp/team-a-client.properties --group a_consumer_group_a

    此请求返回 Not authorized 以访问主题:[x_messages] 错误。

    Dev Team A 没有以 x_ 开始的主题的 Read 访问权限。

  8. 使用 alicex_messages 主题生成消息。

    bin/kafka-console-consumer.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --topic x_messages \
      --from-beginning --consumer.config /tmp/alice.properties

    在 Kafka 中成功生成信息。

    alice 可以从任何主题读取或写入。

  9. 使用 alice 读取集群配置。

    bin/kafka-configs.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --command-config /tmp/alice.properties \
      --entity-type brokers --describe --entity-default

    本例中的集群配置为空。

第 6 章 使用 Strimzi Operator

使用 Strimzi operator 来管理 Kafka 集群,以及 Kafka 主题和用户。

6.1. 使用 AMQ Streams operator 监视命名空间

Operator 会监视和管理命名空间中的 AMQ Streams 资源。Cluster Operator 可以监控 OpenShift 集群中的一个命名空间、多个命名空间或所有命名空间。主题 Operator 和 User Operator 可以监视单个命名空间。

  • Cluster Operator 监视 Kafka 资源
  • Topic Operator 监视 KafkaTopic 资源
  • User Operator 会监视 KafkaUser 资源

主题 Operator 和 User Operator 只能监视命名空间中的单个 Kafka 集群。它们只能连接到单个 Kafka 集群。

如果多个主题 Operator 监视同一命名空间,则可能会发生名称冲突和主题删除。这是因为每个 Kafka 集群都使用同名的 Kafka 主题(如 __consumer_offsets)。请确定只有一个主题 Operator 会监视给定的命名空间。

当将多个用户 Operator 与单个命名空间一起使用时,带有给定用户名的用户可在多个 Kafka 集群中存在。

如果您使用 Cluster Operator 部署 Topic Operator 和 User Operator,它们会监控 Cluster Operator 部署的 Kafka 集群。您还可以使用 operator 配置中的 watchedNamespace 指定一个命名空间。

对于每个 Operator 的独立部署,您可以指定一个命名空间和与 Kafka 集群的连接,以便在配置中监视。

6.2. 使用 Cluster Operator

Cluster Operator 用于部署 Kafka 集群和其他 Kafka 组件。

如需有关部署 Cluster Operator 的信息,请参阅 部署 Cluster Operator

6.2.1. Cluster Operator 配置

您可以使用支持的环境变量以及日志记录配置来配置 Cluster Operator。

环境变量与部署 Cluster Operator 镜像的容器配置相关。有关 镜像 配置的详情请参考 第 12.1.6 节 “image

STRIMZI_NAMESPACE

Operator 应该操作的、以逗号分隔的命名空间列表。如果没有设置,则 Cluster Operator 将在所有命名空间中运行空字符串,或设置为 *。Cluster Operator 部署可能会使用 OpenShift Downward API 自动将其设置为 Cluster Operator 部署的命名空间。

Cluster Operator 命名空间配置示例

env:
  - name: STRIMZI_NAMESPACE
    valueFrom:
      fieldRef:
        fieldPath: metadata.namespace

STRIMZI_FULL_RECONCILIATION_INTERVAL_MS
可选,默认为 120000 ms。定期协调之间的间隔(以毫秒为单位)。
STRIMZI_OPERATION_TIMEOUT_MS
可选,默认为 300000 ms。内部操作的超时时间,以毫秒为单位。使用常规 OpenShift 操作的时间比平等时间使用 AMQ Streams 时,应该增加这个值(例如,下载 Docker 镜像会较慢)。
STRIMZI_ZOOKEEPER_ADMIN_SESSION_TIMEOUT_MS
可选,默认为 10000 ms。

Cluster Operator 的 ZooKeeper 管理客户端的会话超时(以毫秒为单位)。如果来自 Cluster Operator 的 ZooKeeper 请求会因为超时问题而定期失败,则该值应该提高。通过 maxSessionTimeout 配置,ZooKeeper 服务器端设置最大允许的会话时间。默认情况下,此会话最大值是默认 tickTime (默认为 2000)的 20 倍,因此 40000 ms。如果您需要更高的超时,则需要更改 maxSessionTimeout ZooKeeper 服务器配置值。

STRIMZI_OPERATIONS_THREAD_POOL_SIZE
可选,默认 10 个 worker 线程池大小,用于集群操作器运行的各种异步和阻塞操作。
STRIMZI_OPERATOR_NAMESPACE

运行 AMQ Streams Cluster Operator 的命名空间的名称。不要手动配置此变量。使用 OpenShift Downward API。

env:
  - name: STRIMZI_OPERATOR_NAMESPACE
    valueFrom:
      fieldRef:
        fieldPath: metadata.namespace
STRIMZI_OPERATOR_NAMESPACE_LABELS

可选。运行 AMQ Streams Cluster Operator 的命名空间的标签。命名空间标签用于在网络策略中配置命名空间选择器,以允许 AMQ Streams Cluster Operator 只能使用这些标签从命名空间中访问操作对象。如果没有设置,网络策略中的命名空间选择器配置为允许从 OpenShift 集群中的任何命名空间中访问 AMQ Streams Cluster Operator。

env:
  - name: STRIMZI_OPERATOR_NAMESPACE_LABELS
    value: label1=value1,label2=value2
STRIMZI_LABELS_EXCLUSION_PATTERN

可选,默认的 regex 模式是 ^app.kubernetes.io/(?!part-of)*。指定用于过滤主自定义资源的标签的 regex 排除模式到其子资源。labels exclusion 过滤器不适用于 template 部分中的标签,如 spec.kafka.template.pod.metadata.labels

env:
  - name: STRIMZI_LABELS_EXCLUSION_PATTERN
    value: "^key1.*"
STRIMZI_CUSTOM_{COMPONENT_NAME}_LABELS

可选。一个或多个自定义标签应用到由 {COMPONENT_NAME} 自定义资源创建的所有 pod。当创建自定义资源或进行下一个协调时,Cluster Operator 会标记 pod。

以下组件存在环境变量:

  • KAFKA
  • KAFKA_CONNECT
  • KAFKA_CONNECT_BUILD
  • ZOOKEEPER
  • ENTITY_OPERATOR
  • KAFKA_MIRROR_MAKER2
  • KAFKA_MIRROR_MAKER
  • CRUISE_CONTROL
  • KAFKA_BRIDGE
  • KAFKA_EXPORTER
STRIMZI_CUSTOM_RESOURCE_SELECTOR

可选。指定用于过滤 Operator 处理的自定义资源的标签选择器。Operator 只会针对那些设置指定标签的自定义资源进行操作。没有这些标签的资源不会被操作员查看。标签选择器适用于 Kafka, KafkaConnect, KafkaBridge, KafkaMirrorMaker, 和 KafkaMirrorMaker2 资源。仅当对应的 Kafka 和 Kafka Connect 集群有匹配的标签时,才会执行 KafkaRebalanceKafkaConnector 资源。

env:
  - name: STRIMZI_CUSTOM_RESOURCE_SELECTOR
    value: label1=value1,label2=value2
STRIMZI_KAFKA_IMAGES
必需。这可让您从 Kafka 版本映射到包含该版本的 Kafka 代理的对应 Docker 镜像。所需语法是空格或逗号分隔 < version> = &lt;image> 对。例如 3.1.0=registry.redhat.io/amq7/amq-streams-kafka-31-rhel8:2.2.2, 3.2.3=registry.redhat.io/amq7/amq-streams-kafka-32-rhel8:2.2.2。当指定了属性 Kafka.spec.kafka.version 但没有在 Kafka 资源的 Kafka.spec.kafka.image 时使用这个。
STRIMZI_DEFAULT_KAFKA_INIT_IMAGE
可选,默认 registry.redhat.io/amq7/amq-streams-rhel8-operator:2.2.2。在进行初始配置正常工作的代理之前(即机架支持)用作 init 容器的默认镜像名称(如果没有将镜像指定为 Kafka 资源中的 kafka-init-image )。
STRIMZI_KAFKA_CONNECT_IMAGES
必需。这可让您将 Kafka 版本映射到包含该版本的 Kafka 连接对应的 Docker 镜像。所需语法是空格或逗号分隔 < version> = &lt;image> 对。例如 3.1.0=registry.redhat.io/amq7/amq-streams-kafka-31-rhel8:2.2.2, 3.2.3=registry.redhat.io/amq7/amq-streams-kafka-32-rhel8:2.2.2。当指定了 KafkaConnect.spec.version 属性但未指定 KafkaConnect.spec.image 时,会使用此设置。
STRIMZI_KAFKA_MIRROR_MAKER_IMAGES
必需。这可让您将 Kafka 版本映射到包含该版本的 Kafka 镜像制作器的对应 Docker 镜像。所需语法是空格或逗号分隔 < version> = &lt;image> 对。例如 3.1.0=registry.redhat.io/amq7/amq-streams-kafka-31-rhel8:2.2.2, 3.2.3=registry.redhat.io/amq7/amq-streams-kafka-32-rhel8:2.2.2。当指定 KafkaMirrorMaker.spec.version 属性,但没有 KafkaMirrorMaker.spec.image 时会使用这个属性。
STRIMZI_DEFAULT_TOPIC_OPERATOR_IMAGE
可选,默认 registry.redhat.io/amq7/amq-streams-rhel8-operator:2.2.2。如果没有在 Kafka 资源中将 Kafka.spec.entityOperator.topicOperator.image 指定在部署主题 operator 时用作默认 镜像名称
STRIMZI_DEFAULT_USER_OPERATOR_IMAGE
可选,默认 registry.redhat.io/amq7/amq-streams-rhel8-operator:2.2.2。如果没有将镜像指定为 Kafka.spec.entityOperator.userOperator.image,则部署用户 operator 时用作默认 镜像名称
STRIMZI_DEFAULT_TLS_SIDECAR_ENTITY_OPERATOR_IMAGE
可选,默认 registry.redhat.io/amq7/amq-streams-kafka-32-rhel8:2.2.2。如果没有将镜像指定为 Kafka.spec.entityOperator.tlsSidecar.image,在 Kafka 资源中为 Entity Operator 提供 TLS 支持时要使用的 镜像名称
STRIMZI_IMAGE_PULL_POLICY
可选。ImagePullPolicy 将应用到由 AMQ Streams Cluster Operator 管理的所有 pod 中的容器。有效值为 Always,IfNotPresent, Never。如果未指定,则使用 OpenShift 默认值。更改策略将导致所有 Kafka、Kafka Connect 和 Kafka MirrorMaker 集群滚动更新。
STRIMZI_IMAGE_PULL_SECRETS
可选。以逗号分隔的 Secret 名称列表。此处引用的 secret 包含从中拉取容器镜像的容器 registry 的凭证。secret 在 imagePullSecrets 字段中用于 Cluster Operator 创建的所有 Pod。更改此列表会导致所有 Kafka、Kafka Connect 和 Kafka MirrorMaker 集群的滚动更新。
STRIMZI_KUBERNETES_VERSION

可选。覆盖从 API 服务器检测到的 OpenShift 版本信息。

OpenShift 版本覆盖配置示例

env:
  - name: STRIMZI_KUBERNETES_VERSION
    value: |
           major=1
           minor=16
           gitVersion=v1.16.2
           gitCommit=c97fe5036ef3df2967d086711e6c0c405941e14b
           gitTreeState=clean
           buildDate=2019-10-15T19:09:08Z
           goVersion=go1.12.10
           compiler=gc
           platform=linux/amd64

KUBERNETES_SERVICE_DNS_DOMAIN

可选。覆盖默认的 OpenShift DNS 域名后缀。

默认情况下,OpenShift 集群中分配的服务具有使用默认后缀 cluster.local 的 DNS 域名。

例如,对于 broker kafka-0:

<cluster-name>-kafka-0.<cluster-name>-kafka-brokers.<namespace>.svc.cluster.local

DNS 域名添加到用于主机名验证的 Kafka 代理证书中。

如果您在集群中使用不同的 DNS 域名后缀,请将 KUBERNETES_SERVICE_DNS_DOMAIN 环境变量从默认环境变量改为您要用来与 Kafka 代理建立连接。

STRIMZI_CONNECT_BUILD_TIMEOUT_MS
可选,默认为 300000 ms。以毫秒为单位构建新 Kafka Connect 镜像的超时时间。使用 AMQ Streams 构建包含许多连接器或使用较慢的容器 registry 的容器镜像时,应提高这个值。
STRIMZI_NETWORK_POLICY_GENERATION
可选,默认 true。控制 AMQ Streams 是否生成网络策略资源。网络策略允许 Kafka 组件间的连接。

将此环境变量设置为 false 可禁用网络策略生成。例如,您可能想要使用自定义网络策略。自定义网络策略可让更多地控制组件间的连接。

STRIMZI_DNS_CACHE_TTL
可选,默认 30。本地 DNS 解析器中缓存成功名称查找的秒数。任何负值都意味着每次缓存。零表示不要缓存。由于应用了较长的缓存策略,这可用于避免连接错误。
STRIMZI_POD_SET_RECONCILIATION_ONLY
可选,默认 false。当设置为 true 时,Cluster Operator 只协调 StrimziPodSet 资源,以及对其他自定义资源(KafkaKafkaConnect 等等)的任何更改。这个模式有助于确保根据需要重新创建 Pod,但不会对集群进行其他更改。
STRIMZI_FEATURE_GATES
可选。启用或禁用由 功能门 控制的功能和功能。
6.2.1.1. ConfigMap 的日志记录配置

Cluster Operator 的日志记录由 strimzi-cluster-operator ConfigMap 配置。

安装 Cluster Operator 时会创建包含日志记录配置的 ConfigMap。此 ConfigMapinstall/cluster-operator/050-ConfigMap-strimzi-cluster-operator.yaml 文件中描述。您可以通过更改此 ConfigMap 中的数据字段 log4j2.properties 来配置 Cluster Operator 日志记录。

要更新日志记录配置,您可以编辑 050-ConfigMap-strimzi-cluster-operator.yaml 文件,然后运行以下命令:

oc create -f install/cluster-operator/050-ConfigMap-strimzi-cluster-operator.yaml

或者,直接编辑 ConfigMap

oc edit configmap strimzi-cluster-operator

要更改重新加载间隔的频率,请在所创建 ConfigMapmonitorInterval 选项中设置一个时间(以秒为单位)。

如果部署 Cluster Operator 时缺少 ConfigMap,则会使用默认的日志记录值。

如果在部署 Cluster Operator 后意外删除 ConfigMap,则会使用最近加载的日志配置。创建新的 ConfigMap 来加载新的日志记录配置。

注意

不要从 ConfigMap 中删除 monitorInterval 选项。

6.2.1.2. 使用网络策略限制 Cluster Operator 访问

Cluster Operator 可以在与它管理的资源相同的命名空间中运行,或者在单独的命名空间中运行。默认情况下,STRIMZI_OPERATOR_NAMESPACE 环境变量被配置为使用 OpenShift Downward API 来查找 Cluster Operator 在其中运行的命名空间。如果 Cluster Operator 与资源在同一命名空间中运行,则只需要本地访问,并且AMQ Streams 允许。

如果 Cluster Operator 在单独的命名空间中运行到其管理的资源,则 OpenShift 集群中的任何命名空间都可以访问 Cluster Operator,除非配置了网络策略。使用可选的 STRIMZI_OPERATOR_NAMESPACE_LABELS 环境变量使用命名空间标签为 Cluster Operator 建立网络策略。通过添加命名空间标签,对 Cluster Operator 的访问仅限于指定的命名空间。

为 Cluster Operator 部署配置的网络策略

#...
env:
  # ...
  - name: STRIMZI_OPERATOR_NAMESPACE_LABELS
    value: label1=value1,label2=value2
  #...

6.2.1.3. 定期协调

虽然 Cluster Operator 会响应有关从 OpenShift 集群接收的所需集群资源的所有通知,但如果操作器没有运行,或者因为任何原因未收到通知,则所需的资源将不与正在运行的 OpenShift 集群的状态同步。

为了正确处理故障转移,Cluster Operator 会执行定期协调过程,以便它可以将所需资源的状态与当前集群部署进行比较,以便在所有节点上具有一致状态。您可以使用 [STRIMZI_FULL_RECONCILIATION_INTERVAL_MS] 变量为定期协调设置时间间隔。

6.2.1.4. 基于角色的访问控制(RBAC)

要使 Cluster Operator 正常工作,需要 OpenShift 集群中的权限,以便与 KafkaKafkaConnect 等资源交互,以及受管资源,如 ConfigMapPodDeploymentStatefulSet 和服务。这些权限包括在 OpenShift 基于角色的访问控制(RBAC)资源中:

  • ServiceAccount
  • 角色和 ClusterRole
  • RolebindingClusterRoleBinding

除了在带有 ClusterRoleBindingServiceAccount 下运行,Cluster Operator 还为需要访问 OpenShift 资源的组件管理一些 RBAC 资源。

OpenShift 还包括特权升级保护,防止一个 ServiceAccount 下运行的组件授予授予 ServiceAccount 不具有的其他 ServiceAccount 权限。因为 Cluster Operator 必须能够创建 ClusterRoleBindings 和它管理的资源所需的 RoleBindings,所以 Cluster Operator 还必须具有同样的权限。

6.2.1.5. 委派的权限

当 Cluster Operator 为所需的 Kafka 资源部署资源时,它还会创建 ServiceAccountsRoleBindingsClusterRoleBindings,如下所示:

  • Kafka 代理 pod 使用一个名为 cluster-name-kafkaServiceAccount

    • 当使用 rack 功能时,会使用 strimzi-cluster-name-kafka-init ClusterRoleBinding 通过名为 strimzi-kafka-brokerClusterRole 授予这个 ServiceAccount 访问权限
    • 如果不使用机架功能,且集群不会通过 nodeport 公开,则不会创建绑定
  • ZooKeeper pod 使用一个名为 cluster-name-zookeeperServiceAccount
  • Entity Operator pod 使用一个名为 cluster-name-entity-operatorServiceAccount

    • Topic Operator 生成带有状态信息的 OpenShift 事件,因此 ServiceAccount 绑定到一个名为 strimzi-entity-operatorClusterRole,它通过 strimzi-entity-operator RoleBinding授予此访问权限
  • KafkaConnect 资源的 pod 使用一个名为 cluster-name-cluster-connectServiceAccount
  • KafkaMirrorMaker 的 pod 使用一个名为 cluster-name-mirror-makerServiceAccount
  • KafkaMirrorMaker2 的 pod 使用一个名为 cluster-name-mirrormaker2ServiceAccount
  • KafkaBridge 的 pod 使用一个名为 cluster-name-bridgeServiceAccount
6.2.1.6. ServiceAccount

Cluster Operator 最好使用 ServiceAccount 运行:

Cluster Operator 的 ServiceAccount 示例

apiVersion: v1
kind: ServiceAccount
metadata:
  name: strimzi-cluster-operator
  labels:
    app: strimzi

然后,Operator 的 Deployment 需要在其 spec.template.spec.serviceAccountName 中指定:

Cluster Operator 的 Deployment 的部分示例

apiVersion: apps/v1
kind: Deployment
metadata:
  name: strimzi-cluster-operator
  labels:
    app: strimzi
spec:
  replicas: 1
  selector:
    matchLabels:
      name: strimzi-cluster-operator
      strimzi.io/kind: cluster-operator
  template:
      # ...

注意第 12 行,其中 strimzi-cluster-operator ServiceAccount 被指定为 serviceAccountName

6.2.1.7. ClusterRoles

Cluster Operator 需要使用允许访问所需资源的 ClusterRole 来运行。根据 OpenShift 集群设置,集群管理员可能需要创建 ClusterRole

注意

只有创建 ClusterRoles 时需要集群管理员权限。Cluster Operator 不会在集群管理员帐户下运行。

ClusterRole 遵循最小权限 原则,并只包含 Cluster Operator 运行 Kafka、Kafka Connect 和 ZooKeeper 集群所需的权限。分配的第一个权限允许 Cluster Operator 管理 OpenShift 资源,如 StatefulSetsDeploymentPodConfigMap

Cluster Operator 使用 ClusterRole 在命名空间范围的资源级别和集群范围资源级别授予权限:

具有 Cluster Operator 的命名空间资源的 ClusterRole

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: strimzi-cluster-operator-namespaced
  labels:
    app: strimzi
rules:
  - apiGroups:
      - "rbac.authorization.k8s.io"
    resources:
      # The cluster operator needs to access and manage rolebindings to grant Strimzi components cluster permissions
      - rolebindings
    verbs:
      - get
      - list
      - watch
      - create
      - delete
      - patch
      - update
  - apiGroups:
      - "rbac.authorization.k8s.io"
    resources:
      # The cluster operator needs to access and manage roles to grant the entity operator permissions
      - roles
    verbs:
      - get
      - list
      - watch
      - create
      - delete
      - patch
      - update
  - apiGroups:
      - ""
    resources:
      # The cluster operator needs to access and delete pods, this is to allow it to monitor pod health and coordinate rolling updates
      - pods
      # The cluster operator needs to access and manage service accounts to grant Strimzi components cluster permissions
      - serviceaccounts
      # The cluster operator needs to access and manage config maps for Strimzi components configuration
      - configmaps
      # The cluster operator needs to access and manage services and endpoints to expose Strimzi components to network traffic
      - services
      - endpoints
      # The cluster operator needs to access and manage secrets to handle credentials
      - secrets
      # The cluster operator needs to access and manage persistent volume claims to bind them to Strimzi components for persistent data
      - persistentvolumeclaims
    verbs:
      - get
      - list
      - watch
      - create
      - delete
      - patch
      - update
  - apiGroups:
      - "kafka.strimzi.io"
    resources:
      # The cluster operator runs the KafkaAssemblyOperator, which needs to access and manage Kafka resources
      - kafkas
      - kafkas/status
      # The cluster operator runs the KafkaConnectAssemblyOperator, which needs to access and manage KafkaConnect resources
      - kafkaconnects
      - kafkaconnects/status
      # The cluster operator runs the KafkaConnectorAssemblyOperator, which needs to access and manage KafkaConnector resources
      - kafkaconnectors
      - kafkaconnectors/status
      # The cluster operator runs the KafkaMirrorMakerAssemblyOperator, which needs to access and manage KafkaMirrorMaker resources
      - kafkamirrormakers
      - kafkamirrormakers/status
      # The cluster operator runs the KafkaBridgeAssemblyOperator, which needs to access and manage BridgeMaker resources
      - kafkabridges
      - kafkabridges/status
      # The cluster operator runs the KafkaMirrorMaker2AssemblyOperator, which needs to access and manage KafkaMirrorMaker2 resources
      - kafkamirrormaker2s
      - kafkamirrormaker2s/status
      # The cluster operator runs the KafkaRebalanceAssemblyOperator, which needs to access and manage KafkaRebalance resources
      - kafkarebalances
      - kafkarebalances/status
    verbs:
      - get
      - list
      - watch
      - create
      - delete
      - patch
      - update
  - apiGroups:
      - "core.strimzi.io"
    resources:
      # The cluster operator uses StrimziPodSets to manage the Kafka and ZooKeeper pods
      - strimzipodsets
      - strimzipodsets/status
    verbs:
      - get
      - list
      - watch
      - create
      - delete
      - patch
      - update
  - apiGroups:
      # The cluster operator needs the extensions api as the operator supports Kubernetes version 1.11+
      # apps/v1 was introduced in Kubernetes 1.14
      - "extensions"
    resources:
      # The cluster operator needs to access and manage deployments to run deployment based Strimzi components
      - deployments
      - deployments/scale
      # The cluster operator needs to access replica sets to manage Strimzi components and to determine error states
      - replicasets
      # The cluster operator needs to access and manage replication controllers to manage replicasets
      - replicationcontrollers
      # The cluster operator needs to access and manage network policies to lock down communication between Strimzi components
      - networkpolicies
      # The cluster operator needs to access and manage ingresses which allow external access to the services in a cluster
      - ingresses
    verbs:
      - get
      - list
      - watch
      - create
      - delete
      - patch
      - update
  - apiGroups:
      - "apps"
    resources:
      # The cluster operator needs to access and manage deployments to run deployment based Strimzi components
      - deployments
      - deployments/scale
      - deployments/status
      # The cluster operator needs to access and manage stateful sets to run stateful sets based Strimzi components
      - statefulsets
      # The cluster operator needs to access replica-sets to manage Strimzi components and to determine error states
      - replicasets
    verbs:
      - get
      - list
      - watch
      - create
      - delete
      - patch
      - update
  - apiGroups:
      - ""
    resources:
      # The cluster operator needs to be able to create events and delegate permissions to do so
      - events
    verbs:
      - create
  - apiGroups:
      # Kafka Connect Build on OpenShift requirement
      - build.openshift.io
    resources:
      - buildconfigs
      - buildconfigs/instantiate
      - builds
    verbs:
      - get
      - list
      - watch
      - create
      - delete
      - patch
      - update
  - apiGroups:
      - networking.k8s.io
    resources:
      # The cluster operator needs to access and manage network policies to lock down communication between Strimzi components
      - networkpolicies
      # The cluster operator needs to access and manage ingresses which allow external access to the services in a cluster
      - ingresses
    verbs:
      - get
      - list
      - watch
      - create
      - delete
      - patch
      - update
  - apiGroups:
      - route.openshift.io
    resources:
      # The cluster operator needs to access and manage routes to expose Strimzi components for external access
      - routes
      - routes/custom-host
    verbs:
      - get
      - list
      - watch
      - create
      - delete
      - patch
      - update
  - apiGroups:
      - policy
    resources:
      # The cluster operator needs to access and manage pod disruption budgets this limits the number of concurrent disruptions
      # that a Strimzi component experiences, allowing for higher availability
      - poddisruptionbudgets
    verbs:
      - get
      - list
      - watch
      - create
      - delete
      - patch
      - update

第二个包含集群范围的资源所需的权限。

Cluster Operator 的带有集群范围资源的 ClusterRole

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: strimzi-cluster-operator-global
  labels:
    app: strimzi
rules:
  - apiGroups:
      - "rbac.authorization.k8s.io"
    resources:
      # The cluster operator needs to create and manage cluster role bindings in the case of an install where a user
      # has specified they want their cluster role bindings generated
      - clusterrolebindings
    verbs:
      - get
      - list
      - watch
      - create
      - delete
      - patch
      - update
  - apiGroups:
      - storage.k8s.io
    resources:
      # The cluster operator requires "get" permissions to view storage class details
      # This is because only a persistent volume of a supported storage class type can be resized
      - storageclasses
    verbs:
      - get
  - apiGroups:
      - ""
    resources:
      # The cluster operator requires "list" permissions to view all nodes in a cluster
      # The listing is used to determine the node addresses when NodePort access is configured
      # These addresses are then exposed in the custom resource states
      - nodes
    verbs:
      - list

strimzi-kafka-broker ClusterRole 代表 Kafka pod 中 init 容器用于机架功能所需的访问。如 委派的特权 部分中所述,Cluster Operator 还需要此角色,以便能委派此访问权限。

Cluster Operator 的 ClusterRole 允许您将访问权限委派给 Kafka 代理 pod

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: strimzi-kafka-broker
  labels:
    app: strimzi
rules:
  - apiGroups:
      - ""
    resources:
      # The Kafka Brokers require "get" permissions to view the node they are on
      # This information is used to generate a Rack ID that is used for High Availability configurations
      - nodes
    verbs:
      - get

strimzi-topic-operator ClusterRole 代表主题 Operator 所需的访问。如 委派的特权 部分中所述,Cluster Operator 还需要此角色,以便能委派此访问权限。

Cluster Operator 的 ClusterRole,允许它将访问权限委派给主题 Operator

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: strimzi-entity-operator
  labels:
    app: strimzi
rules:
  - apiGroups:
      - "kafka.strimzi.io"
    resources:
      # The entity operator runs the KafkaTopic assembly operator, which needs to access and manage KafkaTopic resources
      - kafkatopics
      - kafkatopics/status
      # The entity operator runs the KafkaUser assembly operator, which needs to access and manage KafkaUser resources
      - kafkausers
      - kafkausers/status
    verbs:
      - get
      - list
      - watch
      - create
      - patch
      - update
      - delete
  - apiGroups:
      - ""
    resources:
      - events
    verbs:
      # The entity operator needs to be able to create events
      - create
  - apiGroups:
      - ""
    resources:
      # The entity operator user-operator needs to access and manage secrets to store generated credentials
      - secrets
    verbs:
      - get
      - list
      - watch
      - create
      - delete
      - patch
      - update

strimzi-kafka-client ClusterRole 代表组件基于使用客户端 rack-awareness 的 Kafka 客户端所需的访问。如 委派的特权 部分中所述,Cluster Operator 还需要此角色,以便能委派此访问权限。

Cluster Operator 的 ClusterRole 允许您将访问权限委派给基于 Kafka 客户端的 pod

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: strimzi-kafka-client
  labels:
    app: strimzi
rules:
  - apiGroups:
      - ""
    resources:
      # The Kafka clients (Connect, Mirror Maker, etc.) require "get" permissions to view the node they are on
      # This information is used to generate a Rack ID (client.rack option) that is used for consuming from the closest
      # replicas when enabled
      - nodes
    verbs:
      - get

6.2.1.8. ClusterRoleBindings

Operator 需要 ClusterRoleBindingsRoleBindings,它将其 ClusterRoleServiceAccount 相关联:包含集群范围资源的 ClusterRole 需要ClusterRoleBinding

Cluster Operator 的 ClusterRoleBinding 示例

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: strimzi-cluster-operator
  labels:
    app: strimzi
subjects:
  - kind: ServiceAccount
    name: strimzi-cluster-operator
    namespace: myproject
roleRef:
  kind: ClusterRole
  name: strimzi-cluster-operator-global
  apiGroup: rbac.authorization.k8s.io

ClusterRoleBindings 也需要,ClusterRoles 需要用于委托。

Kafka 代理机架-awareness Cluster Operator 的 ClusterRoleBinding 示例

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: strimzi-cluster-operator-kafka-broker-delegation
  labels:
    app: strimzi
# The Kafka broker cluster role must be bound to the cluster operator service account so that it can delegate the cluster role to the Kafka brokers.
# This must be done to avoid escalating privileges which would be blocked by Kubernetes.
subjects:
  - kind: ServiceAccount
    name: strimzi-cluster-operator
    namespace: myproject
roleRef:
  kind: ClusterRole
  name: strimzi-kafka-broker
  apiGroup: rbac.authorization.k8s.io

Kafka 客户端的 Cluster Operator 的 ClusterRoleBinding 示例

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: strimzi-cluster-operator-kafka-client-delegation
  labels:
    app: strimzi
# The Kafka clients cluster role must be bound to the cluster operator service account so that it can delegate the
# cluster role to the Kafka clients using it for consuming from closest replica.
# This must be done to avoid escalating privileges which would be blocked by Kubernetes.
subjects:
  - kind: ServiceAccount
    name: strimzi-cluster-operator
    namespace: myproject
roleRef:
  kind: ClusterRole
  name: strimzi-kafka-client
  apiGroup: rbac.authorization.k8s.io

仅包含 命名空间资源的 ClusterRole 仅使用 RoleBindings 进行绑定。

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: strimzi-cluster-operator
  labels:
    app: strimzi
subjects:
  - kind: ServiceAccount
    name: strimzi-cluster-operator
    namespace: myproject
roleRef:
  kind: ClusterRole
  name: strimzi-cluster-operator-namespaced
  apiGroup: rbac.authorization.k8s.io
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: strimzi-cluster-operator-entity-operator-delegation
  labels:
    app: strimzi
# The Entity Operator cluster role must be bound to the cluster operator service account so that it can delegate the cluster role to the Entity Operator.
# This must be done to avoid escalating privileges which would be blocked by Kubernetes.
subjects:
  - kind: ServiceAccount
    name: strimzi-cluster-operator
    namespace: myproject
roleRef:
  kind: ClusterRole
  name: strimzi-entity-operator
  apiGroup: rbac.authorization.k8s.io

6.2.2. 使用默认代理设置配置 Cluster Operator

如果您在 HTTP 代理后运行 Kafka 集群,您仍然可以在集群内和移出数据。例如,您可以使用连接器运行 Kafka Connect,从代理外推送和拉取数据。或者,您可以使用代理与授权服务器连接。

配置 Cluster Operator 部署以指定代理环境变量。Cluster Operator 接受标准代理配置(HTTP_PROXYHTTPS_PROXYNO_PROXY)作为环境变量。代理设置适用于所有 AMQ Streams 容器。

代理地址的格式是 http://IP-ADDRESS:PORT-NUMBER。要使用名称和密码设置代理,格式为 http://USERNAME:PASSWORD@IP-ADDRESS:PORT-NUMBER

先决条件

此流程需要使用 OpenShift 用户帐户来创建 CustomResourceDefinitionsClusterRolesClusterRoleBindings。在 OpenShift 集群中使用 Role Base Access Control (RBAC)通常意味着创建、编辑和删除这些资源的权限仅限于 OpenShift 集群管理员,如 system:admin

流程

  1. 要在 Cluster Operator 中添加代理环境变量,请更新其 Deployment 配置(install/cluster-operator/060-Deployment-strimzi-cluster-operator.yaml)。

    Cluster Operator 的代理配置示例

    apiVersion: apps/v1
    kind: Deployment
    spec:
      # ...
      template:
        spec:
          serviceAccountName: strimzi-cluster-operator
          containers:
            # ...
            env:
            # ...
            - name: "HTTP_PROXY"
              value: "http://proxy.com" 1
            - name: "HTTPS_PROXY"
              value: "https://proxy.com" 2
            - name: "NO_PROXY"
              value: "internal.com, other.domain.com" 3
      # ...

    1
    代理服务器的地址。
    2
    代理服务器的安全地址。
    3
    作为代理服务器例外访问的服务器地址。URL 是用逗号分开的。

    或者,直接编辑 Deployment

    oc edit deployment strimzi-cluster-operator
  2. 如果您更新了 YAML 文件而不是直接编辑 Deployment,请应用更改:

    oc create -f install/cluster-operator/060-Deployment-strimzi-cluster-operator.yaml

6.2.3. 在 Cluster Operator 中配置 FIPS 模式

联邦信息处理标准(FIPS)是计算机安全性和互操作性的标准。当在启用了 FIPS 的 OpenShift 集群上运行 AMQ Streams 时,AMQ Streams 容器镜像中使用的 OpenJDK 会自动切换到 FIPS 模式。这可防止 AMQ Streams 在集群中运行。将 AMQ Streams 部署到集群时,您会看到类似如下的错误:

Exception in thread "main" io.fabric8.kubernetes.client.KubernetesClientException: An error has occurred.
	...
Caused by: java.security.KeyStoreException: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_SESSION_READ_ONLY
	...
Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_SESSION_READ_ONLY
	...

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

流程

  1. 要在 Cluster Operator 中禁用 FIPS 模式,请更新其 Deployment 配置(install/cluster-operator/060-Deployment-strimzi-cluster-operator.yaml)并添加 FIPS_MODE 环境变量。

    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 模式。

    或者,直接编辑 Deployment

    oc edit deployment strimzi-cluster-operator
  2. 如果您更新了 YAML 文件而不是直接编辑 Deployment,请应用更改:

    oc apply -f install/cluster-operator/060-Deployment-strimzi-cluster-operator.yaml

6.3. 使用 Topic Operator

当您使用 KafkaTopic 资源创建、修改或删除主题时,主题 Operator 可确保这些更改反映在 Kafka 集群中。

如需有关 KafkaTopic 资源的更多信息,请参阅 KafkaTopic 模式参考

部署 topics Operator

您可以使用 Cluster Operator 或独立 Operator 部署 Topic Operator。您要将独立 Topic Operator 与不由 Cluster Operator 管理的 Kafka 集群一起使用。

有关部署说明,请查看以下操作:

重要

要部署独立主题 Operator,您需要设置环境变量以连接到 Kafka 集群。如果要使用 Cluster Operator 部署 Topic Operator,则不需要设置这些环境变量,因为 Cluster Operator 将设置它们。

6.3.1. Kafka 主题资源

KafkaTopic 资源用于配置主题,包括分区和副本的数量。

KafkaTopic 的完整模式信息包括在 KafkaTopic schema reference 中。

6.3.1.1. 为主题处理识别 Kafka 集群

KafkaTopic 资源包含一个标签,它指定 Kafka 集群的名称(来自 Kafka 资源的名称)的名称。

例如:

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaTopic
metadata:
  name: topic-name-1
  labels:
    strimzi.io/cluster: my-cluster

Topic Operator 用来识别 KafkaTopic 资源并创建一个新主题,并在后续处理主题时使用该标签。

如果标签与 Kafka 集群不匹配,主题 Operator 无法识别 KafkaTopic,且不创建主题。

6.3.1.2. Kafka 主题使用建议

处理主题时,会一致。始终直接在 OpenShift 中操作 KafkaTopic 资源或主题。避免定期在这两种方法间切换给定主题。

使用反映主题性质的主题名称,并记住以后无法更改名称。

如果在 Kafka 中创建一个主题,请使用有效的 OpenShift 资源名称,否则主题 Operator 需要使用符合 OpenShift 规则的名称来创建对应的 KafkaTopic

注意

如需有关 OpenShift 中标识符和名称的要求的信息,请参阅对象名称 和 ID

6.3.1.3. Kafka 主题命名约定

Kafka 和 OpenShift 会分别在 Kafka 和 KafkaTopic.metadata.name 中对主题进行自己的验证规则。彼此都无效,它们都有有效的名称。

使用 spec.topicName 属性,可以在 Kafka 中创建一个有效的主题,其名称对 OpenShift 中的 Kafka 主题无效。

spec.topicName 属性继承 Kafka 命名验证规则:

  • 名称不得大于 249 个字符。
  • Kafka 主题的有效字符包括 ASCII 字母数字、._-
  • 名称不能是 ..,但 . 可在名称中使用,如 exampleTopic..exampleTopic

不能更改 spec.topicName

例如:

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaTopic
metadata:
  name: topic-name-1
spec:
  topicName: topicName-1 1
  # ...
1
在 OpenShift 中,大写无效。

无法更改为:

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaTopic
metadata:
  name: topic-name-1
spec:
  topicName: name-2
  # ...
注意

有些 Kafka 客户端应用程序(如 Kafka Streams)可以以编程方式在 Kafka 中创建主题。如果这些主题具有无效的 OpenShift 资源名称的名称,主题 Operator 会根据 Kafka 名称赋予它们有效的 metadata.name。无效的字符会被替换,哈希会附加到名称中。例如:

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaTopic
metadata:
  name: mytopic---c55e57fe2546a33f9e603caf57165db4072e827e
spec:
  topicName: myTopic
  # ...

6.3.2. 主题 Operator 主题存储

主题 Operator 使用 Kafka 将主题元数据存储为键值对描述主题配置。主题存储 基于 Kafka Streams 键值机制,使用 Kafka 主题来持久保留状态。

主题元数据缓存在内存中,并在主题 Operator 中本地访问。应用到本地内存缓存的操作更新会被保留到磁盘上的备份主题存储中。主题存储会持续与 Kafka 主题或 OpenShift KafkaTopic 自定义资源的更新同步。操作通过通过这个主题存储设置的快速处理,但应该从持久性存储中自动填充内存缓存崩溃。

6.3.2.1. 内部主题存储主题

内部主题支持处理主题存储中的主题元数据。

__strimzi_store_topic
用于存储主题元数据的输入主题
__strimzi-topic-operator-kstreams-topic-store-changelog
保留紧凑主题存储值的日志
警告

不要删除这些主题,因为它们对于 Topic Operator 的运行至关重要。

6.3.2.2. 从 ZooKeeper 迁移主题元数据

在 AMQ Streams 之前的版本中,主题元数据存储在 ZooKeeper 中。此过程将删除此要求,将元数据引入到 Kafka 集群中,并在主题 Operator 的控制下。

当升级到 AMQ Streams 2.2 时,到主题存储的 Operator 控制是无缝的。从 ZooKeeper 找到并迁移元数据,旧的存储会被删除。

6.3.2.3. 降级到使用 ZooKeeper 存储主题元数据的 AMQ Streams 版本

如果您恢复到 1.7 之前的 AMQ Streams 版本,该版本使用 ZooKeeper 用于主题元数据的存储,您仍然会将 Cluster Operator 降级到以前的版本,然后降级 Kafka 代理和客户端应用程序作为标准。

但是,还必须使用 kafka-admin 命令删除为主题存储创建的主题,并指定 Kafka 集群的 bootstrap 地址。例如:

oc run kafka-admin -ti --image=registry.redhat.io/amq7/amq-streams-kafka-32-rhel8:2.2.2 --rm=true --restart=Never -- ./bin/kafka-topics.sh --bootstrap-server localhost:9092 --topic __strimzi-topic-operator-kstreams-topic-store-changelog --delete && ./bin/kafka-topics.sh --bootstrap-server localhost:9092 --topic __strimzi_store_topic --delete

命令必须与用于访问 Kafka 集群的监听程序和身份验证类型对应。

主题 Operator 将从 Kafka 中主题状态重新创建 ZooKeeper 主题元数据。

6.3.2.4. 主题 Operator 主题复制和扩展

建议由主题 Operator 管理的主题配置是 3 个主题复制因素,至少 2 个同步副本。

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaTopic
metadata:
  name: my-topic
  labels:
    strimzi.io/cluster: my-cluster
spec:
  partitions: 10 1
  replicas: 3 2
  config:
    min.insync.replicas: 2 3
  #...
1
主题的分区数量。
2
副本主题分区的数量。目前,这无法在 KafkaTopic 资源中更改,但可以使用 kafka-reassign-partitions.sh 工具进行修改。
3
必须成功写入消息的最少副本数,或者引发异常。
注意

同步副本与生产者应用的 acks 配置结合使用。acks 配置决定了必须将消息的后续分区数量复制到,然后才能确认成功接收消息。主题 Operator 使用 acks=all 运行,通过所有 in-sync 副本都必须确认信息。

当通过添加或删除代理扩展 Kafka 集群时,复制因素配置不会被更改,且不会自动重新分配副本。但是,您可以使用 kafka-reassign-partitions.sh 工具更改复制因素,并手动将副本重新分配给代理。

另外,虽然集成 AMQ Streams 的 Cruise Control 无法更改主题的复制因素,但它生成的优化建议会包括传输分区副本的命令以及更改分区领导的命令。

6.3.2.5. 处理对主题的更改

主题 Operator 需要解决的一个根本问题是没有单个数据源: KafkaTopic 资源和 Kafka 主题都独立于主题 Operator 修改。对这一点复杂,主题 Operator 可能不会始终能够实时观察变化。例如,当主题 Operator 停机时。

要解决这个问题,主题 Operator 会维护主题存储中每个主题的信息。当 Kafka 集群或 OpenShift 中发生更改时,它会查看其他系统和主题存储的状态,以确定一切保持同步的需求。每当主题 Operator 启动时,并定期发生同样的情况。

例如,假设 Topic Operator 未运行,并且创建了名为 my-topicKafkaTopic。当主题 Operator 启动时,主题存储不包含 my-topic 的信息,因此可在最后运行 KafkaTopic 后创建 KafkaTopic。主题 Operator 创建与 my-topic 对应的主题,并将 my-topic 的元数据存储在主题存储中。

如果您更新 Kafka 主题配置或通过 KafkaTopic 自定义资源应用更改,则在 Kafka 集群协调后会更新主题存储。

主题存储也允许 Topic Operator 来管理在 Kafka 主题中更改主题配置通过 OpenShift KafkaTopic 自定义资源进行更新的情况,只要这些更改没有不兼容。例如,可以更改相同的主题配置键,但可以对不同的值进行更改。对于不兼容的更改,Kafka 配置会考虑优先级,并相应地更新 KafkaTopic

注意

您还可以使用 KafkaTopic 资源,使用 oc delete -f KAFKA-TOPIC-CONFIG-FILE 命令删除主题。要实现此目的,在 Kafka 资源的 spec.kafka.config 中必须将 delete.topic.enable 设置为 true (默认)。

6.3.3. 配置 Kafka 主题

使用 KafkaTopic 资源的属性来配置 Kafka 主题。

您可以使用 oc apply 来创建或修改主题,oc delete 来删除现有的主题。

例如:

  • oc apply -f <topic_config_file>
  • oc delete KafkaTopic <topic_name>

此流程演示了如何创建包含 10 个分区和 2 个副本的主题。

开始前

在进行更改前,您必须考虑以下问题:

  • Kafka 不支持减少分区数量。
  • 通过键为主题增加 spec.partitions 将改变记录分区方式,这在主题使用 语义分区 时会特别问题。
  • AMQ Streams 不支持通过 KafkaTopic 资源进行以下更改:

    • 使用 spec.replicas 更改初始指定副本数
    • 使用 spec.topicName更改主题名称

先决条件

流程

  1. 配置 KafkaTopic 资源。

    Kafka 主题配置示例

    apiVersion: kafka.strimzi.io/v1beta2
    kind: KafkaTopic
    metadata:
      name: orders
      labels:
        strimzi.io/cluster: my-cluster
    spec:
      partitions: 10
      replicas: 2

    提示

    在修改主题时,您可以使用 oc get kafkatopic orders -o yaml 来获取资源的当前版本。

  2. 在 OpenShift 中创建 KafkaTopic 资源。

    oc apply -f <topic_config_file>
  3. 等待主题的就绪状态更改为 True

    oc get kafkatopics -o wide -w -n <namespace>

    Kafka 主题状态

    NAME         CLUSTER     PARTITIONS  REPLICATION FACTOR READY
    my-topic-1   my-cluster  10          3                  True
    my-topic-2   my-cluster  10          3
    my-topic-3   my-cluster  10          3                  True

    READY 输出显示为 True 时,主题创建成功。

  4. 如果 READY 列留空,请从资源 YAML 或 Topic Operator 日志中获取有关状态的更多详细信息。

    消息提供有关当前状态的原因的详细信息。

    oc get kafkatopics my-topic-2 -o yaml

    有关 NotReady 状态主题的详情

    # ...
    status:
      conditions:
      - lastTransitionTime: "2022-06-13T10:14:43.351550Z"
        message: Number of partitions cannot be decreased
        reason: PartitionDecreaseException
        status: "True"
        type: NotReady

    在本例中,主题未就绪的原因是在 KafkaTopic 配置中减少原始分区数量。Kafka 不支持此功能。

    重置主题配置后,状态将显示主题为 ready。

    oc get kafkatopics my-topic-2 -o wide -w -n <namespace>

    主题的状态更新

    NAME         CLUSTER     PARTITIONS  REPLICATION FACTOR READY
    my-topic-2   my-cluster  10          3                  True

    获取详情不会显示任何信息

    oc get kafkatopics my-topic-2 -o yaml

    有关具有 READY 状态的主题的详情

    # ...
    status:
      conditions:
      - lastTransitionTime: '2022-06-13T10:15:03.761084Z'
        status: 'True'
        type: Ready

6.3.4. 使用资源请求和限值配置 Topic Operator

您可以将资源(如 CPU 和内存)分配给主题 Operator,并为其消耗的资源数量设置限制。

先决条件

  • Cluster Operator 正在运行。

流程

  1. 根据需要,在编辑器中更新 Kafka 集群配置:

    oc edit kafka MY-CLUSTER
  2. Kafka 资源的 spec.entityOperator.topicOperator.resources 属性中,为 Topic Operator 设置资源请求和限值。

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    spec:
      # Kafka and ZooKeeper sections...
      entityOperator:
        topicOperator:
          resources:
            requests:
              cpu: "1"
              memory: 500Mi
            limits:
              cpu: "1"
              memory: 500Mi
  3. 应用新配置来创建或更新资源。

    oc apply -f <kafka_configuration_file>

6.4. 使用 User Operator

当您使用 KafkaUser 资源创建、修改或删除用户时,用户 Operator 可确保这些更改在 Kafka 集群中反映出来。

有关 KafkaUser 资源的更多信息,请参阅 KafkaUser 模式参考

部署 User Operator

您可以使用 Cluster Operator 或独立 Operator 部署 User Operator。您可以在不由 Cluster Operator 管理的 Kafka 集群中使用独立 User Operator。

有关部署说明,请查看以下操作:

重要

要部署独立 User Operator,您需要设置环境变量以连接到 Kafka 集群。如果要使用 Cluster Operator 部署 User Operator,则不需要设置这些环境变量,因为 Cluster Operator 将设置它们。

6.4.1. 配置 Kafka 用户

使用 KafkaUser 资源的属性来配置 Kafka 用户。

您可以使用 oc apply 来创建或修改用户,oc delete 来删除现有的用户。

例如:

  • oc apply -f <user_config_file>
  • oc delete KafkaUser &lt ;user_name>

用户代表 Kafka 客户端。配置 Kafka 用户时,您可以启用客户端访问 Kafka 所需的用户身份验证和授权机制。所用的机制必须与对应的 Kafka 配置匹配。有关使用 KafkaKafkaUser 资源保护对 Kafka 代理的访问的更多信息,请参阅 保护对 Kafka 代理的访问

先决条件

流程

  1. 配置 KafkaUser 资源。

    这个示例使用 ACL 指定 TLS 验证和简单授权。

    Kafka 用户配置示例

    apiVersion: kafka.strimzi.io/v1beta2
    kind: KafkaUser
    metadata:
      name: my-user
      labels:
        strimzi.io/cluster: my-cluster
    spec:
      authentication:
        type: tls
      authorization:
        type: simple
        acls:
          # Example consumer Acls for topic my-topic using consumer group my-group
          - resource:
              type: topic
              name: my-topic
              patternType: literal
            operation: Read
            host: "*"
          - resource:
              type: topic
              name: my-topic
              patternType: literal
            operation: Describe
            host: "*"
          - resource:
              type: group
              name: my-group
              patternType: literal
            operation: Read
            host: "*"
          # Example Producer Acls for topic my-topic
          - resource:
              type: topic
              name: my-topic
              patternType: literal
            operation: Write
            host: "*"
          - resource:
              type: topic
              name: my-topic
              patternType: literal
            operation: Create
            host: "*"
          - resource:
              type: topic
              name: my-topic
              patternType: literal
            operation: Describe
            host: "*"

  2. 在 OpenShift 中创建 KafkaUser 资源。

    oc apply -f <user_config_file>
  3. 等待用户就绪状态更改为 True

    oc get kafkausers -o wide -w -n <namespace>

    Kafka 用户状态

    NAME       CLUSTER     AUTHENTICATION  AUTHORIZATION READY
    my-user-1  my-cluster  tls             simple        True
    my-user-2  my-cluster  tls             simple
    my-user-3  my-cluster  tls             simple        True

    READY 输出显示为 True 时,用户创建成功。

  4. 如果 READY 列留空,则从资源 YAML 或 User Operator 日志中获取有关状态的更多详细信息。

    消息提供有关当前状态的原因的详细信息。

    oc get kafkausers my-user-2 -o yaml

    有关具有 NotReady 状态的用户的详情

    # ...
    status:
      conditions:
      - lastTransitionTime: "2022-06-10T10:07:37.238065Z"
        message: Simple authorization ACL rules are configured but not supported in the
          Kafka cluster configuration.
        reason: InvalidResourceException
        status: "True"
        type: NotReady

    在本例中,用户未就绪的原因是,因为 Kafka 配置中没有启用简单的授权。

    用于简单授权的 Kafka 配置

      apiVersion: kafka.strimzi.io/v1beta2
      kind: Kafka
      metadata:
        name: my-cluster
      spec:
        kafka:
          # ...
          authorization:
            type: simple

    在更新 Kafka 配置后,其状态会显示用户已就绪。

    oc get kafkausers my-user-2 -o wide -w -n <namespace>

    用户的状态更新

    NAME       CLUSTER     AUTHENTICATION  AUTHORIZATION READY
    my-user-2  my-cluster  tls             simple        True

    获取详细信息不会显示任何信息。

    oc get kafkausers my-user-2 -o yaml

    有关具有 READY 状态的用户的详情

    # ...
    status:
      conditions:
      - lastTransitionTime: "2022-06-10T10:33:40.166846Z"
        status: "True"
        type: Ready

6.4.2. 使用资源请求和限值配置 User Operator

您可以将资源(如 CPU 和内存)分配给 User Operator,并为其消耗的资源数量设置限值。

先决条件

  • Cluster Operator 正在运行。

流程

  1. 根据需要,在编辑器中更新 Kafka 集群配置:

    oc edit kafka MY-CLUSTER
  2. Kafka 资源中的 spec.entityOperator.userOperator.resources 属性中,为 User Operator 设置资源请求和限值。

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    spec:
      # Kafka and ZooKeeper sections...
      entityOperator:
        userOperator:
          resources:
            requests:
              cpu: "1"
              memory: 500Mi
            limits:
              cpu: "1"
              memory: 500Mi

    保存文件并退出编辑器。Cluster Operator 会自动应用更改。

6.5. 配置功能门

AMQ Streams 操作器支持 功能门,以启用或禁用某些功能和功能。启用功能门更改了相关 Operator 的行为,并为 AMQ Streams 部署引入该功能。

功能门的默认状态是 enableddisabled

要修改功能门的默认状态,请在 Operator 配置中使用 STRIMZI_FEATURE_GATES 环境变量。您可以使用这个单一环境变量修改多个功能门。指定以逗号分隔的功能门名称和前缀列表。+ 前缀可启用功能门,而 - 前缀会禁用它。

启用 FeatureGate1 并禁用 FeatureGate2的功能门配置示例

env:
  - name: STRIMZI_FEATURE_GATES
    value: +FeatureGate1,-FeatureGate2

6.5.1. ControlPlaneListener 功能门

ControlPlaneListener 功能门默认状态为 enabled

使用 ControlPlaneListener 功能门更改用于 Kafka 集群内间的通信路径。在 AMQ Streams 中,control plane 流量由控制器连接组成,用于维护 Kafka 集群所需状态。data plane 流量主要由领导代理和后续代理间的数据复制组成。

启用 ControlPlaneListener 时,control plane 流量通过端口 9090 上的专用 control plane 侦听程序。data plane 流量在端口 9091 上继续使用内部监听程序。

使用 control plane 监听器可能会提高性能,因为重要的控制器连接(如分区领导更改)不会被代理中的数据复制延迟。

禁用 ControlPlaneListener 功能门

要禁用 ControlPlaneListener 功能门,请在 Cluster Operator 配置中的 STRIMZI_FEATURE_GATES 环境变量中指定 -ControlPlaneListener。当禁用 ControlPlaneListener 功能门时,control plane 和 data plane 流量通过端口 9091 上的同一内部监听程序。这是引入功能门前的默认行为。

重要

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

6.5.2. ServiceAccountPatching 功能门

ServiceAccountPatching 功能门的默认状态 已启用

默认情况下,Cluster Operator 会协调服务帐户并根据需要更新它们。例如,您可以在已经创建操作对象后更改服务帐户标签和注解。要禁用服务帐户修补,禁用 ServiceAccountPatching 功能门。

禁用 ServiceAccountPatching 功能门

要禁用 ServiceAccountPatching 功能门,请在 Cluster Operator 配置中的 STRIMZI_FEATURE_GATES 环境变量中指定 -ServiceAccountPatching ing。

6.5.3. UseStrimziPodSets 功能门

UseStrimziPodSets 功能门默认状态为 disabled

目前,AMQ Streams 依赖于 StatefulSets 为 ZooKeeper 和 Kafka 集群创建和管理 pod。AMQ Streams 创建 StatefulSet,OpenShift 会根据 StatefulSet 定义创建 pod。删除 Pod 后,OpenShift 会负责重新创建它。StatefulSets 的使用有以下限制:

  • Pod 始终根据其索引号创建或删除
  • StatefulSet 中的所有 pod 需要有类似的配置
  • 在 StatefulSet 中更改 Pod 的存储配置复杂

UseStrimziPodSets 功能门引入了用于管理名为 StrimziPodSet 的 pod 的资源。启用功能门后,会使用这个资源而不是 StatefulSets。AMQ Streams 处理 pod 的创建和管理,而不是 OpenShift。使用 StrimziPodSets 而不是 StatefulSets 可提供更多对功能的控制。

启用 UseStrimziPodSets 功能门

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

重要

在将 UseStrimziPodSets 功能门降级到 AMQ Streams 2.0 及更早的版本时,必须禁用使用StrimziPodSets 功能门。

6.5.4. (Preview) UseKRaft 功能门

UseKRaft 功能门的默认状态为 disabled

UseKRaft 功能门在 KRaft (Kafka Raft 元数据)模式下部署 Kafka 集群,而无需 ZooKeeper。此功能门目前仅用于开发和测试。

重要

KRaft 模式还无法在 Apache Kafka 或 AMQ Streams 中提供。

启用 UseKRaft 功能门时,Kafka 集群会在没有 ZooKeeper 的情况下部署。Kafka 自定义资源中的 .spec.zookeeper 属性将被忽略,但仍然需要存在。UseKRaft 功能门提供了一个 API,用于配置 Kafka 集群节点及其角色。API 仍在开发中,预期在 KRaft 模式生产就绪前更改。

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

  • 不支持从 ZooKeeper 移动到 KRaft 集群或其他方法。
  • 不支持升级和降级 Apache Kafka 版本或 AMQ Streams operator。用户可能需要删除集群,升级 Operator 并部署一个新的 Kafka 集群。
  • 不支持 Entity Operator (包括用户 Operator 和主题操作器)。spec.entityOperator 属性 必须被删除(从 Kafka 自定义资源中)。
  • 不支持简单的授权。
  • 不支持 SCRAM-SHA-512 验证。
  • 不支持 JBOD 存储。可以使用 type: jbod 存储,但 JBOD 数组只能包含一个磁盘。
  • 存活度和就绪度探测被禁用。
  • 所有 Kafka 节点都有 controllerbroker KRaft 角色。不支持具有独立 controllerbroker 节点的 Kafka 集群。

启用 UseKRaft 功能门

要启用 UseKRaft 功能门,请在 Cluster Operator 配置中的 STRIMZI_FEATURE_GATES 环境变量中指定 +UseKRaft

重要

UseKRaft 功能门取决于 UseStrimziPodSets 功能门。启用 UseKRaft 功能门时,请确保也启用了 USeStrimziPodSets 功能门。

6.5.5. 功能门发行版本

功能门的成熟度有三个阶段:

  • alpha - 通常默认禁用
  • beta - 通常默认启用
  • GA (GA)- 通常总是启用

Alpha 阶段功能可能是实验性或不稳定,可能随时更改,或不充分测试用于生产用途。测试良好的测试阶段功能已充分测试,其功能不太可能改变。GA 阶段功能稳定,不应在以后改变。如果 alpha 和 beta 阶段功能没有证明有用,则会移除它们。

  • ControlPlaneListener 功能门移到 AMQ Streams 2.0 中的 beta 阶段。
  • ServiceAccountPatching 功能门移到 AMQ Streams 2.0 中的 beta 阶段。
  • UseStrimziPodSets 功能门目前位于 alpha 阶段。
  • UseKRaft 功能门仅适用于开发,目前没有计划迁移至 beta 阶段的版本。
注意

功能门在到达 GA 时可能会被删除。这意味着该功能已合并到 AMQ Streams 核心功能中,且无法禁用。

表 6.1. 功能门和 AMQ Streams 版本在移到 alpha、beta 或 GA 时
功能门alphabetaGA

ControlPlaneListener

1.8

2.0

-

ServiceAccountPatching

1.8

2.0

-

UseStrimziPodSets

2.1

-

-

UseKRaft

2.2

-

-

如果启用了功能门,您可能需要在从特定的 AMQ Streams 版本升级或降级前禁用它。下表显示了在升级或降级 AMQ Streams 版本时需要禁用哪些功能门。

表 6.2. 功能门在升级或降级 AMQ Streams 时禁用
禁用功能门从 AMQ Streams 版本升级降级到 AMQ Streams 版本

ControlPlaneListener

1.7 及更早版本

1.7 及更早版本

UseStrimziPodSets

-

2.0 及更早版本

6.6. 使用 Prometheus 指标监控 Operator

AMQ Streams operator 会公开 Prometheus 指标。指标会自动启用并包含有关以下信息:

  • 协调数
  • Operator 正在处理的自定义资源数量
  • 协调持续时间
  • 来自操作器的 JVM 指标

另外,我们提供了一个 Grafana 仪表板示例。

有关 Prometheus 的更多信息,请参阅《 OpenShift 部署与升级 AMQ Streams 》中的 介绍指标到 Kafka

第 7 章 用于集群重新平衡的 Cruise Control

Cruise Control 是一个用于自动化 Kafka 操作的开源系统,如监控集群工作负载、基于预定义的限制重新平衡集群,以及检测和修复异常。它包括四个主要组件(即 Load Monitor、Anomaly Detector 和 Executor-​ 以及用于客户端交互的 REST API)。

您可以将 Cruise Control 部署到 AMQ Streams 集群,并使用它来 重新平衡 Kafka 集群。您可以通过配置 Kafka 资源来部署 Cruise Control。您可以通过 KafkaRebalance 资源执行重新平衡,这会生成并应用优化提议。

AMQ Streams 使用 REST API 来支持以下 Cruise Control 功能:

  • 从优化目标生成优化方案。
  • 根据优化提议,重新平衡 Kafka 集群。

    优化目标

    优化目标描述了通过重新平衡实现的特定目标。例如,在代理之间更均匀地分发主题副本。您可以更改通过配置包含的目标。目标定义为硬目标或软目标。您可以通过 Cruise Control 部署配置来增加硬目标。您还有适合以下类别的主要、默认和用户提供的目标。

    • 硬目标是 预先设置的,必须符合才能成功进行优化的提议。
    • 对于成功进行优化方案,不需要满足软目标。如果意味着满足所有硬目标,可以排在设置它们。
    • 主要目标从 Cruise Control 中继承。有些情况下会预先设置为一个硬目标。默认使用主要目标来优化提议。
    • 默认目标 与主目标相同。您可以指定您自己的默认目标集合。
    • 用户提供的目标是 为生成特定优化方案而配置的默认目标的子集。
    优化方案

    优化建议由您要从重新平衡实现的目标组成。您生成了优化的提议,以创建建议的更改摘要以及重新平衡时可能的结果。以特定优先级顺序对目标进行评估。然后,您可以选择批准或拒绝提议。您可以通过调整的目标集来拒绝再次运行该提议。

    您可以使用三种模式之一生成优化方案。

    • full 是默认模式,运行完全重新平衡。
    • add-brokers 是在扩展 Kafka 集群时添加代理时使用的模式。
    • remove-brokers 是在缩减 Kafka 集群时删除代理前所使用的模式。

目前还不支持其他 Cruise Control 功能,包括自我修复、通知、编写目标以及更改主题复制因素。

AMQ Streams 提供 示例配置文件。用于 Cruise Control 的 YAML 配置文件示例在 /cruise-control/ 中提供。

7.1. 为什么使用 Cruise 控制?

Cruise 控制减少了运行高效和均衡 Kafka 集群所涉及的时间和工作量。

典型的集群会随时间推移而变得不会被加载。处理大量消息流量的分区可能不均匀分布到可用的代理中。要重新平衡集群,管理员必须监控代理的负载,并手动重新分配忙碌分区以使用备用容量进行代理。

Cruise Control 自动执行集群重新平衡过程。它根据 CPU、磁盘和网络负载,构建了基于 CPU、磁盘和网络负载的资源利用率 的工作负载模型,并生成优化方案(您可以批准或拒绝)以实现更大的分区分配。一组可配置的优化目标用于计算这些提议。

当您批准优化的提议时,Cruise Control 会将它应用到 Kafka 集群。当集群重新平衡操作时,代理 pod 会更有效地使用,且 Kafka 集群会更均匀地平衡。

其他资源

7.2. 优化目标概述

优化目标是在 Kafka 集群中工作负载重新分配和资源利用率的限制。要重新平衡 Kafka 集群,Cruise Control 使用 优化目标来生成优化 提议,您可以批准或拒绝。

7.2.1. 优先级的目标顺序

AMQ Streams 支持在 Cruise Control 项目中开发的大部分优化目标。支持的目标按默认优先级降序排列,如下所示:

  1. rack-awareness
  2. 一组主题的每个代理的最小领导副本数
  3. 副本容量
  4. 容量目标

    • 磁盘容量
    • 网络入站容量
    • 网络出站容量
    • CPU 容量
  5. 副本分发
  6. 潜在的网络输出
  7. 资源分布目标

    • 磁盘使用分布
    • 网络入站利用率分布
    • 网络出站利用率分布
    • CPU 使用率分发
  8. leader 字节(以字节为单位)分布
  9. 主题副本分发
  10. 领导副本分发
  11. 首选领导机制
  12. in-broker 磁盘容量
  13. intra-broker 磁盘用量分布

有关每个优化目标的更多信息,请参阅 Cruise Control Wiki 中的 Goals

注意

"编写您自己的"目标和 Kafka 分配器目标尚不受支持。

7.2.2. AMQ Streams 自定义资源中的目标配置

您可以在 KafkaKafkaRebalance 自定义资源中配置优化目标。Cruise Control 具有配置,可进行硬优化目标,必须得到满足、默认和用户提供的优化目标。

您可以在以下配置中指定优化目标:

  • Main goals — Kafka.spec.cruiseControl.config.goals
  • 硬目标 TOKEN- Kafka.spec.cruiseControl.config.hard.goals
  • 默认目标 TOKEN - Kafka.spec.cruiseControl.config.default.goals
  • 用户提供的目标 noProxy - KafkaRebalance.spec.goals
注意

资源分发目标取决于代理资源的 容量限制

7.2.3. 硬和软优化目标

硬目标是指 必须满足 优化提议的目标。未配置为硬目标的目标称为 软目标。您可以将软目标视为 最佳 目标:它们 不需要在 优化提议中满足,但包含在优化计算中。违反一个或多个软目标的一个优化方案,但满足所有硬目标是有效的。

Cruise Control 将计算满足所有硬目标以及尽可能多的软目标(按优先级顺序)的优化方案。无法满足所有硬目标的优化建议将由 Cruise 控制而拒绝,而不会发送给用户进行批准。

注意

例如,您可能会有一个软目标,在集群中平均分配主题的副本(主题副本分布目标)。如果这样做可启用所有配置的硬目标,则控制将忽略这个目标。

在 Cruise Control 中,预设了以下 主要优化目标

RackAwareGoal; MinTopicLeadersPerBrokerGoal; ReplicaCapacityGoal; DiskCapacityGoal; NetworkInboundCapacityGoal; NetworkOutboundCapacityGoal; CpuCapacityGoal

您可以通过在 Kafka.spec.cruiseControl.config 中编辑 hard.goals 属性来配置 Cruise Control 部署配置中的硬目标。

  • 要从 Cruise Control 继承 preset hard 目标,请不要在 Kafka.spec.cruiseControl.config中指定 hard.goals 属性
  • 要更改预先设置的硬目标,请使用它们的完全限定域名在 hard.goals 属性中指定所需的目标。

硬优化目标的 Kafka 配置示例

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.NetworkInboundCapacityGoal,
        com.linkedin.kafka.cruisecontrol.analyzer.goals.NetworkOutboundCapacityGoal
      # ...

增加配置的硬目标数量将减少减少 Cruise 控制生成有效优化方案的可能性。

如果在 KafkaRebalance 自定义资源中指定 skipHardGoalCheck: true,则 Cruise Control 不会检查 用户提供的优化目标(在 KafkaRebalance.spec.goals中)包含 所有配置的 硬目标(hard.goals)。因此,如果不是全部,则用户提供的优化目标在 hard.goals 列表中,即使指定 skipHardGoalCheck: true,也会将它们视为硬目标。

7.2.4. 主要优化目标

所有用户都提供了 主要的优化目标。不列在主要优化目标中未列出的目标不适用于 Cruise Control 操作。

除非更改 Cruise Control 部署配置,AMQ Streams 会从 Cruise Control 继承以下主要优化目标,以降序排列:

RackAwareGoal; ReplicaCapacityGoal; DiskCapacityGoal; NetworkInboundCapacityGoal; NetworkOutboundCapacityGoal; CpuCapacityGoal; ReplicaDistributionGoal; PotentialNwOutGoal; DiskUsageDistributionGoal; NetworkInboundUsageDistributionGoal; NetworkOutboundUsageDistributionGoal; CpuUsageDistributionGoal; TopicReplicaDistributionGoal; LeaderReplicaDistributionGoal; LeaderBytesInDistributionGoal; PreferredLeaderElectionGoal

其中一些目标被预先设置为 硬目标

为了降低复杂性,我们建议您使用继承的主优化目标,除非您需要 完全 排除在 KafkaRebalance 资源中使用的一个或多个目标。如果需要,可在 默认的优化目标配置中修改主要优化 目标的优先级顺序。

如果需要,在 Cruise Control 部署配置中配置主要的优化目标: Kafka.spec.cruiseControl.config.goals

  • 要接受继承的主要优化目标,请不要在 Kafka.spec.cruiseControl.config 中指定 goals 属性。
  • 如果您需要修改继承的主要优化目标,请在 goals 配置选项中指定目标列表(按优先级降序排列)。
注意

如果您更改了继承的主优化目标,您必须确保在 Kafka.spec.cruiseControl.config 中的 hard.goals 属性中配置,这是您配置的主要优化目标的子集。否则,在生成优化方案时出现错误。

7.2.5. 默认优化目标

Cruise Control 使用默认优化目标 来生成 缓存的优化建议。有关缓存的优化方案的更多信息,请参阅 第 7.3 节 “优化提议概述”

您可以通过在 KafkaRebalance 自定义资源中设置 用户提供的优化目标 来覆盖默认的优化目标。

除非在 Cruise Control 部署配置中 指定 default.goals,否则主要的优化目标将用作默认的优化目标。在这种情况下,缓存的优化提议会使用主要优化目标生成。

  • 要使用主优化目标作为默认目标,请不要在 Kafka.spec.cruiseControl.config 中指定 default.goals 属性。
  • 要修改默认的优化目标,请编辑 Kafka.spec.cruiseControl.config 中的 default.goals 属性。您必须使用主要优化目标的子集。

默认优化目标的 Kafka 配置示例

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:
      default.goals: >
        com.linkedin.kafka.cruisecontrol.analyzer.goals.RackAwareGoal,
        com.linkedin.kafka.cruisecontrol.analyzer.goals.ReplicaCapacityGoal,
        com.linkedin.kafka.cruisecontrol.analyzer.goals.DiskCapacityGoal
      # ...

如果没有指定默认的优化目标,则会使用主优化目标生成缓存的提议。

7.2.6. 用户提供的优化目标

用户提供的优化目标 缩小了特定优化提议的配置的默认目标。您可以在 KafkaRebalance 自定义资源的 spec.goals 中根据需要设置它们:

KafkaRebalance.spec.goals

用户提供的优化目标可为不同的场景生成优化方案。例如,您可能想在不考虑磁盘容量或磁盘利用率的情况下优化 Kafka 集群中的领导副本分布。因此,您可以创建一个 KafkaRebalance 自定义资源,其中包含一个用于领导副本分布的单一用户提供的目标。

用户提供的优化目标必须:

  • 包括所有配置的 硬目标,或发生错误
  • 成为主要优化目标的子集

要忽略生成优化提议时配置的硬目标,请将 skipHardGoalCheck: true 属性添加到 KafkaRebalance 自定义资源。请参阅 第 7.6 节 “生成优化方案”

其他资源

7.3. 优化提议概述

您可以使用 KafkaRebalance 资源来生成并应用推荐的更改。优化的 提议 是生成更平衡的 Kafka 集群的建议更改概述,在代理中平均分配分区工作负载。

每个优化建议都基于用于生成 它的优化目标 集合,取决于代理资源的任何配置容量限制

所有优化的提议都是对提议重新平衡的影响的估算。您可以批准或拒绝提议。您不能在不生成优化提议的情况下批准集群重新平衡。

您可以以以下重新平衡模式之一运行优化提议:

  • full
  • add-brokers
  • remove-brokers

7.3.1. 重新平衡模式

您可以使用 KafkaRebalance 自定义资源的 spec.mode 属性指定一个重新平衡模式。

full
通过将副本移到集群中的所有代理中,完整 模式会运行完全重新平衡。如果 KafkaRebalance 自定义资源中没有定义 spec.mode 属性,则这是默认模式。
add-brokers
add-brokers 模式通过添加一个或多个代理来扩展 Kafka 集群后使用。通常,在扩展 Kafka 集群后,新代理仅用于托管新创建的主题的分区。如果没有创建新的主题,则不会使用新添加的代理,并且现有代理保留在同一负载下。通过在向集群添加代理后立即使用 add-brokers 模式,重新平衡操作会将副本从现有代理移到新添加的代理中。您可以使用 KafkaRebalance 自定义资源的 spec.brokers 属性将新代理指定为列表。
remove-brokers
remove-brokers 模式通过删除一个或多个代理来缩减 Kafka 集群。如果您缩减 Kafka 集群,代理也会关闭,即使它们的主机副本也是如此。这可能导致死机分区,并可能导致某些分区处于最小 ISR 下(in-sync 副本)。为了避免这个问题,remove-brokers 模式会从要删除的代理中移出副本。当这些代理不再托管副本时,可以安全地运行缩减操作。您可以在 KafkaRebalance 自定义资源的 spec.brokers 属性中指定您移除的代理。

通常,通过在代理中分散负载,使用 完整 重新平衡模式来重新平衡 Kafka 集群。只有在您要扩展集群或缩减并相应地重新平衡副本时,才使用 add-brokersremove-brokers 模式。

运行重新平衡的步骤在三种不同模式之间是相同的。唯一区别是通过 spec.mode 属性指定模式,如果需要,列出已添加或将通过 spec.brokers 属性删除的代理。

7.3.2. 优化方案的结果

当生成优化提议时,返回摘要和代理负载。

概述
摘要包含在 KafkaRebalance 资源中。摘要介绍了所提议的集群重新平衡概述,并指示涉及的更改规模。KafkaRebalance 资源的 Status.OptimizationResult 属性中包括成功生成的优化建议概述。提供的信息是全面优化提议的摘要。
代理负载
代理负载存储在包含作为 JSON 字符串数据的 ConfigMap 中。代理负载显示在所提议重新平衡的值之前和之后,您可以看到对集群中的每个代理的影响。

7.3.3. 批准或拒绝优化提议

优化建议摘要显示了建议的更改范围。

您可以使用 KafkaRebalance 资源的名称返回命令行的摘要。

返回优化方案概述

oc describe kafkarebalance <kafka_rebalance_resource_name> -n <namespace>

您还可以使用 jq 命令行 JSON parser 工具。

使用 jq 返回优化的提议概述

oc get kafkarebalance -o json | jq <jq_query>.

使用摘要来确定是否批准或拒绝优化提议。

批准优化方案
您可以通过设置 KafkaRebalance 资源的 strimzi.io/rebalance 注解来 批准 优化的提议。Cruise Control 将提议应用到 Kafka 集群,并启动集群重新平衡操作。
拒绝优化的提议
如果您选择不批准优化方案,您可以更改优化目标更新任何重新平衡性能调优选项,然后生成另一个提议。您可以使用 strimzi.io/refresh 注解为 KafkaRebalance 资源生成一个新的优化建议。

使用优化提议来评估重新平衡所需的移动。例如,摘要描述了 inter-broker 和 in-broker 的移动。在不同的代理间重新平衡数据移动数据。在使用 JBOD 存储配置时,代理会在同一代理上的磁盘间移动数据。即使您无法继续并批准提议,这些信息也很有用。

您可能会拒绝优化的提议,或延迟其批准,因为在重新平衡时 Kafka 集群上的额外负载。

在以下示例中,建议建议在单独的代理之间重新平衡数据。重新平衡涉及在代理间移动 55 分区副本(总计 12MB 数据)。虽然对分区副本的干预移动会对性能有严重影响,但数据总量并不大。如果总数据较大,您可以拒绝提议,或当批准重新平衡时限制 Kafka 集群性能的影响。

重新平衡性能调优选项有助于降低数据移动的影响。如果可以扩展重新平衡周期,您可以将重新平衡分成较小的批处理。一次减少数据移动可减少群集的负载。

优化建议概述示例

Name:         my-rebalance
Namespace:    myproject
Labels:       strimzi.io/cluster=my-cluster
Annotations:  API Version:  kafka.strimzi.io/v1alpha1
Kind:         KafkaRebalance
Metadata:
# ...
Status:
  Conditions:
    Last Transition Time:  2022-04-05T14:36:11.900Z
    Status:                ProposalReady
    Type:                  State
  Observed Generation:     1
  Optimization Result:
    Data To Move MB:  0
    Excluded Brokers For Leadership:
    Excluded Brokers For Replica Move:
    Excluded Topics:
    Intra Broker Data To Move MB:         12
    Monitored Partitions Percentage:      100
    Num Intra Broker Replica Movements:   0
    Num Leader Movements:                 24
    Num Replica Movements:                55
    On Demand Balancedness Score After:   82.91290759174306
    On Demand Balancedness Score Before:  78.01176356230222
    Recent Windows:                       5
  Session Id:                             a4f833bd-2055-4213-bfdd-ad21f95bf184

提议也会将 24 个分区领导人移到不同的代理中。这需要一个对 ZooKeeper 配置的更改,这对性能有较低的影响。

均衡的分数是在处理建议前和之后的 Kafka 集群总体平衡的衡量。均衡分数基于优化目标。如果满足所有目标,则分数为 100。对于不满足的每个目标,分数降低。比较 balancedness 分数,以查看 Kafka 集群是否少于其重新平衡。

7.3.4. 优化建议概述属性

下表说明了优化建议部分中包含的属性。

表 7.1. 优化建议概述中包含的属性
JSON 属性Description

numIntraBrokerReplicaMovements

集群代理磁盘之间传输的分区副本数量。

重新平衡操作期间的性能影响 :相对高,但小于 numReplicaMovements

excludedBrokersForLeadership

尚不受支持。返回空列表。

numReplicaMovements

在独立代理之间移动的分区副本数量。

重新平衡操作期间的性能影响 :相对高.

onDemandBalancednessScoreBefore, onDemandBalancednessScoreAfter

Kafka 集群的整体 平衡 度量,在生成优化建议前和之后。

分数的计算是通过减去每个违反软目标的 BalancednessScore 的总和(从 100 为单位)。Cruise Control 会根据几个因素为每个优化目标分配一个 BalancednessScore,包括在 默认.goal 或用户提供的目标列表 中包括优先级目标。

Before 分数基于 Kafka 集群的当前配置。After 分数基于生成的优化提议。

intraBrokerDataToMoveMB

在同一代理上的磁盘间移动的每个分区副本的总和(请参阅 numIntraBrokerReplicaMovements)。

重新平衡操作期间的性能影响 :变量.集群重新平衡所需的时间越大,完成集群重新平衡所需的时间。在同一代理上的磁盘间移动大量数据的影响要低于独立的代理(请参阅 dataToMoveMB)。

recentWindows

优化提议的指标窗口数量。

dataToMoveMB

将移到一个单独的代理的每个分区副本的大小总和(请参阅 numReplicaMovements)。

重新平衡操作期间的性能影响 :变量.集群重新平衡所需的时间越大,完成集群重新平衡所需的时间。

monitoredPartitionsPercentage

Kafka 集群中由优化提议覆盖的分区百分比。受 excludedTopics 数量的影响。

excludedTopics

如果您在 KafkaRebalance 资源的 spec.excludedTopicsRegex 属性中指定正则表达式,则此处列出与该表达式匹配的所有主题名称。这些主题不包括在优化书中分区副本/领导移动的计算。

numLeaderMovements

领导程序切换到不同副本的分区数量。这包括对 ZooKeeper 配置的更改。

重新平衡操作期间的性能影响 :相对较低的.

excludedBrokersForReplicaMove

尚不受支持。返回空列表。

7.3.5. 代理负载属性

代理负载作为 JSON 格式的字符串存储在 ConfigMap 中(与 KafkaRebalance 自定义资源的名称相同)。此 JSON 字符串由一个 JSON 对象组成,其中包含每个代理 ID 的键,用于链接到每个代理的指标。每个指标由三个值组成:第一种是应用优化的提议前的指标值,第二个是应用提议后的指标的预期值,第三个值是前两个值(之前减号)。

注意

当 KafkaRebalance 资源处于 ProposalReady 状态时,ConfigMap 会出现,并在重新平衡完成后保留。

您可以使用 ConfigMap 的名称从命令行查看其数据。

返回 ConfigMap 数据

oc describe configmaps <my_rebalance_configmap_name> -n <namespace>

您还可以使用 jq 命令行 JSON parser 工具从 ConfigMap 中提取 JSON 字符串。

使用 jq 从 ConfigMap 中提取 JSON 字符串

oc get configmaps <my_rebalance_configmap_name> -o json | jq '.["data"]["brokerLoad.json"]|fromjson|.'

下表说明了优化提议的代理负载 ConfigMap 中包含的属性:

JSON 属性Description

领导者

这个代理中的副本数量是分区领导的。

replicas

此代理上的副本数量。

cpuPercentage

CPU 使用率作为定义容量的百分比。

diskUsedPercentage

磁盘利用率作为定义容量的百分比。

diskUsedMB

绝对磁盘使用量(以 MB 为单位)。

networkOutRate

代理的网络输出率总数。

leaderNetworkInRate

此代理上所有分区领导副本的网络输入率。

followerNetworkInRate

此代理中所有后续副本的网络输入率。

potentialMaxNetworkOutRate

如果此代理成为当前主机的所有副本的领导人,则这种代理成为当前主机的所有副本的领导数,这将实现的最多网络输出率。

7.3.6. 缓存的优化方案

Cruise Control 会根据配置的默认 优化目标维护一个缓存的优化提议。从工作负载模型生成,缓存的优化方案每 15 分钟更新一次,以反映 Kafka 集群的当前状态。如果您使用默认优化目标生成优化建议,Cruise Control 将返回最新的缓存提议。

要更改缓存的优化建议刷新间隔,请编辑 Cruise Control 部署配置中的 proposal.expiration.ms 设置。对于快速更改的集群,请考虑一个较短的间隔,但这会增加 Cruise Control 服务器中的负载。

7.4. 重新平衡性能调整概述

您可以为集群重新平衡调整几个性能调优选项。这些选项控制在重新平衡中分区副本和领导移动的方式,以及分配给重新平衡操作的带宽。

7.4.1. 分区重新分配命令

优化 建议由单独的分区重新分配命令组成。当您 批准 提议时,Cruise Control 服务器会将这些命令应用到 Kafka 集群。

分区重新分配命令由以下一种操作组成:

  • 分区移动:传输分区副本及其数据到新位置。分区移动可以采用以下两种形式之一:

    • inter-broker move:分区副本被移到不同代理上的日志目录中。
    • intra-broker 移动:分区副本被移到同一代理的不同日志目录中。
  • 领导移动:这涉及切换分区副本的领导机。

将控制问题分区重新分配给批处理中的 Kafka 集群。重新平衡期间集群的性能会受到每个批处理中包含的每种移动次数的影响。

7.4.2. 副本移动策略

集群重新平衡性能也会受到 副本移动策略 影响,该策略应用于分区重新分配命令的批处理。默认情况下,Cruise Control 使用 BaseReplicaMovementStrategy,它只是按照生成的顺序应用这些命令。但是,如果提早出现一些非常大的分区重新分配,这个策略可能会减慢其他重新分配的应用程序。

Cruise Control 提供了四个备用副本移动策略,可用于优化提议:

  • PrioritizeSmallReplicaMovementStrategy: Order 重新分配以升序大小。
  • PrioritizeLargeReplicaMovementStrategy: order 重新分配以降序排列。
  • PostponeUrpReplicaMovementStrategy: Prioritize 重新分配没有同步副本的分区副本。
  • PrioritizeMinIsrWithOfflineReplicasStrategy: Prioritizements with (At/Under) MinISR 分区带有离线副本。只有在 Kafka 自定义资源的 spec 中被设置为 true 时,只有在 cruiseControl.config.concurrency.adjuster.min.isr.check.enabled 时,此策略才能正常工作。

这些策略可以配置为序列。第一个策略尝试使用其内部逻辑比较两个分区重新分配。如果重新分配项同等,则它将按顺序传递到下一策略,以确定顺序顺序等。

7.4.3. in-broker 磁盘平衡

在同一代理上的磁盘间移动大量数据比独立的代理之间的影响要小。如果您正在运行一个 Kafka 部署,它使用带有同一代理的多个磁盘的 JBOD 存储,Cruise Control 可以在磁盘间平衡分区。

注意

如果您将 JBOD 存储与单一磁盘配合使用,在代理磁盘平衡中,则会导致一个有 0 分区移动的成成,因为没有磁盘之间的平衡。

要执行 intra-broker 磁盘平衡,请在 KafkaRebalance.spec 下将 重新平衡Disk 设置为 true。当将 rebalanceDisk 设置为 true 时,不要在 KafkaRebalance.spec 中设置 goals 字段,因为 Cruise Control 会自动设置 intra-broker 目标并忽略 inter-broker 目标。Cruise Control 不同时执行 inter-broker 和 in-broker 平衡。

7.4.4. 重新平衡调整选项

Cruise Control 提供了多个配置选项来调优上面讨论的重新平衡参数。在使用 Kafka 配置和部署 Cruise 控制 时,您可以设置这些调整选项,或 优化概率 级别:

  • Cruise Control server 设置可以在 Kafka. spec.cruiseControl.config 下的 Kafka 自定义资源中设置。
  • 单个重新平衡性能配置可以在 KafkaRebalance.spec 下设置。

下表总结了相关的配置。

表 7.2. 重新平衡性能调整配置
Cruise Control 属性KafkaRebalance 属性默认Description

num.concurrent.partition.movements.per.broker

concurrentPartitionMovementsPerBroker

5

每个分区重新分配批量的最大代理分区移动数

num.concurrent.intra.broker.partition.movements

concurrentIntraBrokerPartitionMovements

2

每个分区重新分配批量的最大内代理分区移动数

num.concurrent.leader.movements

concurrentLeaderMovements

1000

每个分区重新分配批量的分区领导更改的最大数量

default.replication.throttle

replicationThrottle

null (无限制)

分配给分区的带宽(以字节/秒为单位)

default.replica.movement.strategies

replicaMovementStrategies

BaseReplicaMovementStrategy

用于决定针对生成的提议执行分区重新分配命令的策略列表(按优先级顺序)。对于 server 设置,使用具有策略类完全限定名称(add com.linkedin.kafka.cruisecontrol.executor.strategy. strategy)的逗号分隔列表。对于 KafkaRebalance 资源设置,请使用策略类名称的 YAML 数组。

-

rebalanceDisk

false

启用 in-broker 磁盘平衡,用于平衡同一代理上磁盘之间的磁盘空间利用率。只适用于使用多个磁盘的 JBOD 存储的 Kafka 部署。

更改默认设置会影响重新平衡完成所需的时间,并在重新平衡期间在 Kafka 集群上放置负载。使用较低值可减少负载,但会增加所需的时间,反之亦然。

7.5. 使用 Kafka 配置和部署 Cruise 控制

通过 Kafka 资源配置,Cluster Operator 可以在部署 Kafka 集群时部署 Cruise Control。您可以使用 Kafka 资源的 cruiseControl 属性来配置部署。为每个 Kafka 集群部署一个 Cruise Control 实例。

在 Cruise Control config 中使用 goals 配置来指定优化目标,以生成优化建议。您可以使用 brokerCapacity 更改与资源分布相关的目标的默认容量限制。如果代理在带有异构网络资源的节点上运行,您可以使用 overrides 为各个代理设置网络容量限制。

如果将空对象({})用于 cruiseControl 配置,则所有属性都使用其默认值。

先决条件

  • OpenShift 集群
  • 正在运行的 Cluster Operator

流程

  1. 编辑 Kafka 资源的 cruiseControl 属性。

    您可以在以下示例配置中显示您可以配置的属性:

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    metadata:
      name: my-cluster
    spec:
      # ...
      cruiseControl:
        brokerCapacity: 1
          inboundNetwork: 10000KB/s
          outboundNetwork: 10000KB/s
          # ...
        config: 2
          default.goals: > 3
            com.linkedin.kafka.cruisecontrol.analyzer.goals.RackAwareGoal,
            com.linkedin.kafka.cruisecontrol.analyzer.goals.ReplicaCapacityGoal,
            com.linkedin.kafka.cruisecontrol.analyzer.goals.DiskCapacityGoal
            # ...
          hard.goals: >
            com.linkedin.kafka.cruisecontrol.analyzer.goals.NetworkInboundCapacityGoal,
            com.linkedin.kafka.cruisecontrol.analyzer.goals.NetworkOutboundCapacityGoal
            # ...
          cpu.balance.threshold: 1.1
          metadata.max.age.ms: 300000
          send.buffer.bytes: 131072
          webserver.http.cors.enabled: true 4
          webserver.http.cors.origin: "*"
          webserver.http.cors.exposeheaders: "User-Task-ID,Content-Type"
          # ...
        resources: 5
          requests:
            cpu: 1
            memory: 512Mi
          limits:
            cpu: 2
            memory: 2Gi
        logging: 6
            type: inline
            loggers:
              rootLogger.level: "INFO"
        template: 7
          pod:
            metadata:
              labels:
                label1: value1
            securityContext:
              runAsUser: 1000001
              fsGroup: 0
            terminationGracePeriodSeconds: 120
        readinessProbe: 8
          initialDelaySeconds: 15
          timeoutSeconds: 5
        livenessProbe:
          initialDelaySeconds: 15
          timeoutSeconds: 5
        metricsConfig: 9
          type: jmxPrometheusExporter
          valueFrom:
            configMapKeyRef:
              name: cruise-control-metrics
              key: metrics-config.yml
    # ...
    1
    2
    3
    优化目标配置,可包括用于默认优化目标的配置(默认为)、主要优化目标(目标)和硬目标(hard.goals)。
    4
    为对 Cruise Control API 的只读访问 启用并配置 CORS
    5
    用于保留 支持的资源、当前 cpu 和内存 的请求,以及指定可消耗的最大资源数量。
    6
    通过 ConfigMap 直接添加(内联)或间接(外部 )的控制 日志记录器和日志级别。自定义 ConfigMap 必须放在 log4j.properties 键下。Cruise Control 有一个名为 rootLogger.level 的单个日志记录器。您可以将日志级别设置为 INFO、ERROR、WARN、TRACE、DEBUG、FATAL 或 OFF。
    7
    模板自定义。此处为 pod 调度了额外的安全属性。
    8
    状况检查,了解何时重启容器(持续)以及容器是否可以接受流量(就绪状态)。
    9
    启用 Prometheus 指标。在本例中,为 Prometheus JMX Exporter 配置指标(默认指标导出器)。
  2. 创建或更新资源:

    oc apply -f <kafka_configuration_file>
  3. 检查部署的状态:

    oc get deployments -n <my_cluster_operator_namespace>

    输出显示了部署名称和就绪状态

    NAME                      READY  UP-TO-DATE  AVAILABLE
    my-cluster-cruise-control 1/1    1           1

    my-cluster 是 Kafka 集群的名称。

    READY 显示 ready/expected 的副本数量。当 AVAILABLE 输出显示为 1 时,部署成功。

自动创建的主题

下表显示了在部署 Cruise Control 时自动创建的三个主题。这些主题需要 Cruise Control 才能正常工作,且不得删除或更改。您可以使用指定的配置选项更改主题名称。

表 7.3. 自动创建的主题
自动创建的主题配置默认主题名称创建者功能

metric.reporter.topic

strimzi.cruisecontrol.metrics

AMQ Streams Metrics Reporter

将 Metrics Reporter 中的原始指标存储在每个 Kafka 代理中。

partition.metric.sample.store.topic

strimzi.cruisecontrol.partitionmetricsamples

Sything Control

存储每个分区的派生指标。它们由 指标示例聚合器 创建。

broker.metric.sample.store.topic

strimzi.cruisecontrol.modeltrainingsamples

Sything Control

存储用于创建 Cluster Workload Model 的指标示例。

要防止删除 Cruise Control 所需的记录,在自动创建的主题中禁用了日志压缩。

注意

如果在启用了 Cruise Control 的 Kafka 集群中更改自动创建主题的名称,旧的主题不会被删除,应手动删除旧的主题。

接下来要执行的操作

配置和部署 Cruise Control 后,您可以生成优化提议

7.6. 生成优化方案

当您创建或更新 KafkaRebalance 资源时,Cruise Control 会根据配置的 优化 目标为 Kafka 集群生成 优化建议。分析优化方案中的信息,并决定是否批准它。您可以使用优化探测的结果来重新平衡 Kafka 集群。

您可以以以下模式之一运行优化方案:

  • full (默认)
  • add-brokers
  • remove-brokers

您使用的模式取决于您是否在在 Kafka 集群中运行的所有代理之间进行重新平衡,还是要在扩展或缩减 Kafka 集群前重新平衡。如需更多信息,请参阅 使用代理扩展 重新平衡模式

先决条件

流程

  1. 创建 KafkaRebalance 资源并指定适当的模式。

    完整 模式(默认)

    要使用 Kafka 资源 中定义的默认优化目标,请将 spec 属性留空。默认情况下,Cruise Control 重新平衡 Kafka 集群以 完全 模式。

    默认有完整重新平衡的配置示例

    apiVersion: kafka.strimzi.io/v1beta2
    kind: KafkaRebalance
    metadata:
      name: my-rebalance
      labels:
        strimzi.io/cluster: my-cluster
    spec: {}

    您还可以通过 spec.mode 属性指定 完整的 模式,运行完整的重新平衡。

    指定 完整模式的 配置示例

    apiVersion: kafka.strimzi.io/v1beta2
    kind: KafkaRebalance
    metadata:
      name: my-rebalance
      labels:
        strimzi.io/cluster: my-cluster
    spec:
      mode: full

    add-brokers 模式

    如果要在扩展后重新平衡 Kafka 集群,请指定 add-brokers 模式。

    在这个模式中,现有副本被移到新添加的代理中。您需要指定一个代理作为列表。

    指定 add-brokers 模式的配置示例

    apiVersion: kafka.strimzi.io/v1beta2
    kind: KafkaRebalance
    metadata:
      name: my-rebalance
      labels:
        strimzi.io/cluster: my-cluster
    spec:
      mode: add-brokers
      brokers: [3, 4] 1

    1
    由扩展操作添加的新添加的代理列表。这个属性是必需的。
    remove-brokers 模式

    如果要在缩减前重新平衡 Kafka 集群,请指定 remove-brokers 模式。

    在这个模式中,副本会从要删除的代理中移出。您需要指定要删除的代理作为列表。

    指定 remove-brokers 模式的配置示例

    apiVersion: kafka.strimzi.io/v1beta2
    kind: KafkaRebalance
    metadata:
      name: my-rebalance
      labels:
        strimzi.io/cluster: my-cluster
    spec:
      mode: remove-brokers
      brokers: [3, 4] 1

    1
    要通过缩减操作删除的代理列表。这个属性是必需的。
    注意

    无论使用的重新平衡模式如何,以下步骤以及批准或停止重新平衡的步骤都相同。

  2. 要配置 用户提供的优化目标 而不使用默认的目标,请添加 目标 属性并输入一个或多个目标。

    在以下示例中,机架意识和副本容量配置为用户提供的优化目标:

    apiVersion: kafka.strimzi.io/v1beta2
    kind: KafkaRebalance
    metadata:
      name: my-rebalance
      labels:
        strimzi.io/cluster: my-cluster
    spec:
      goals:
        - RackAwareGoal
        - ReplicaCapacityGoal
  3. 要忽略配置的硬目标,请添加 skipHardGoalCheck: true 属性:

    apiVersion: kafka.strimzi.io/v1beta2
    kind: KafkaRebalance
    metadata:
      name: my-rebalance
      labels:
        strimzi.io/cluster: my-cluster
    spec:
      goals:
        - RackAwareGoal
        - ReplicaCapacityGoal
      skipHardGoalCheck: true
  4. 创建或更新资源:

    oc apply -f <kafka_rebalance_configuration_file>

    Cluster Operator 从 Cruise Control 请求优化探测。这可能需要几分钟时间,具体取决于 Kafka 集群的大小。

  5. 等待优化提议的状态更改为 ProposalReady

    oc get kafkarebalance -o wide -w -n <namespace>
    PendingProposal
    PendingProposal 状态意味着重新平衡 Operator 正在轮询 Cruise Control API 来检查优化提议是否就绪。
    ProposalReady
    ProposalReady 状态表示优化提议已准备好审核和批准。

    当状态变为 ProposalReady 时,优化提议可以批准。

  6. 回顾优化方案。

    优化的提议包含在 KafkaRebalance 资源的 Status.Optimization Result 属性中。

    oc describe kafkarebalance <kafka_rebalance_resource_name>

    优化建议示例

    Status:
      Conditions:
        Last Transition Time:  2020-05-19T13:50:12.533Z
        Status:                ProposalReady
        Type:                  State
      Observed Generation:     1
      Optimization Result:
        Data To Move MB:  0
        Excluded Brokers For Leadership:
        Excluded Brokers For Replica Move:
        Excluded Topics:
        Intra Broker Data To Move MB:         0
        Monitored Partitions Percentage:      100
        Num Intra Broker Replica Movements:   0
        Num Leader Movements:                 0
        Num Replica Movements:                26
        On Demand Balancedness Score After:   81.8666802863978
        On Demand Balancedness Score Before:  78.01176356230222
        Recent Windows:                       1
      Session Id:                             05539377-ca7b-45ef-b359-e13564f1458c

    Optimization Result 部分中的属性描述了待处理的集群重新平衡操作。有关每个属性的描述,请参阅 优化提议的内容

CPU 容量不足

如果 Kafka 集群根据 CPU 使用率过载,您可能在 KafkaRebalance 状态中看到 CPU 容量不足。值得注意的是,这种使用率值不受 excludeTopics 配置的影响。虽然优化建议不会重新分配排除主题的副本,但在利用率计算中仍将考虑它们的负载。

CPU 使用率错误示例

com.linkedin.kafka.cruisecontrol.exception.OptimizationFailureException:
        [CpuCapacityGoal] Insufficient capacity for cpu (Utilization 615.21,
        Allowed Capacity 420.00, Threshold: 0.70). Add at least 3 brokers with
        the same cpu capacity (100.00) as broker-0. Add at least 3 brokers with
        the same cpu capacity (100.00) as broker-0.

注意

该错误以百分比而不是 CPU 内核数显示 CPU 容量。因此,它不会直接映射到 Kafka 自定义资源中配置的 CPU 数量。它类似于每个代理有一个 虚拟 CPU,它有在 Kafka.spec.kafka.resources.limits.cpu 中配置的 CPU 周期。这不会影响重新平衡行为,因为 CPU 使用率和容量之间的比例保持不变。

接下来要执行的操作

第 7.7 节 “批准优化方案”

7.7. 批准优化方案

如果它的状态是 ProposalReady,您可以批准 Cruise Control 生成的 优化提议。然后,Cruise Control 将对 Kafka 集群应用优化建议,将分区重新分配给代理和更改分区领导。

小心

这不是空运行。在批准优化方案前,您必须:

先决条件

流程

对您要批准的优化提议执行这些步骤。

  1. 除非新生成的优化提议,否则请检查它是否基于有关 Kafka 集群状态的最新信息。要做到这一点,刷新优化方案以确保它使用最新的集群指标:

    1. 使用 strimzi.io/rebalance=refresh 注解 OpenShift 中的 KafkaRebalance 资源:

      oc annotate kafkarebalance <kafka_rebalance_resource_name> strimzi.io/rebalance=refresh
  2. 等待优化提议的状态更改为 ProposalReady

    oc get kafkarebalance -o wide -w -n <namespace>
    PendingProposal
    PendingProposal 状态意味着重新平衡 Operator 正在轮询 Cruise Control API 来检查优化提议是否就绪。
    ProposalReady
    ProposalReady 状态表示优化提议已准备好审核和批准。

    当状态变为 ProposalReady 时,优化提议可以批准。

  3. 批准您希望 Cruise Control 适用的优化方案。

    使用 strimzi.io/rebalance=approve 给 OpenShift 中的 KafkaRebalance 资源标注:

    oc annotate kafkarebalance <kafka_rebalance_resource_name> strimzi.io/rebalance=approve
  4. Cluster Operator 检测到注解的资源,并指示 Cruise Control 来重新平衡 Kafka 集群。
  5. 等待优化提议的状态更改为 Ready

    oc get kafkarebalance -o wide -w -n <namespace>
    重新平衡
    重新平衡 状态意味着重新平衡正在进行。
    Ready
    Ready 状态表示重新平衡已完成。
    NotReady
    NotReady 状态表示发生错误 - 请参阅 KafkaRebalance 资源中的修复问题

    当状态变为 Ready 时,重新平衡即完成。

    要使用同一个 KafkaRebalance 自定义资源来生成另一个优化的提议,请将 刷新 注解应用到自定义资源。这会将自定义资源移到 PendingProposalProposalReady 状态。然后,您可以审查优化方案,并根据需要批准它。

7.8. 停止集群重新平衡

启动后,集群重新平衡操作可能需要一些时间才能完成,并影响 Kafka 集群的整体性能。

如果要停止进行中的集群重新平衡操作,请将 stop 注解应用到 KafkaRebalance 自定义资源。这会指示 Cruise Control 完成当前的分区重新分配,然后停止重新平衡。当重新平衡停止后,已应用完成的分区重新分配量;因此,与开始重新平衡操作之前,Kafka 集群的状态会不同。如果需要进一步重新平衡,您应该生成新的优化提议。

注意

Kafka 集群处于中间(停止)状态的性能可能比初始状态更糟。

先决条件

  • 您已通过使用 approve 注解了 KafkaRebalance 自定义资源来批准优化的提议
  • KafkaRebalance 自定义资源的状态是 重新平衡

流程

  1. 在 OpenShift 中注解 KafkaRebalance 资源:

    oc annotate kafkarebalance rebalance-cr-name strimzi.io/rebalance=stop
  2. 检查 KafkaRebalance 资源的状态:

    oc describe kafkarebalance rebalance-cr-name
  3. 等待状态变为 Stopped

7.9. 修复 KafkaRebalance 资源的问题

如果在创建 KafkaRebalance 资源或与 Cruise Control 交互时出现错误,则会在资源状态中报告错误以及如何修复它的详情。资源也会进入 NotReady 状态。

要继续集群重新平衡操作,您必须在 KafkaRebalance 资源本身或整个 Cruise Control 部署中修复问题。问题可能包括以下内容:

  • KafkaRebalance 资源中的错误参数。
  • 缺少在 KafkaRebalance 资源中指定的 Kafka 集群的 strimzi.io/cluster 标签。
  • Cruise Control 服务器没有部署为 Kafka 资源中的 cruiseControl 属性。
  • 无法访问 Cruise Control 服务器。

修复问题后,您需要将 刷新 注解添加到 KafkaRebalance 资源。在 "refresh" 期间,通过 Cruise Control 服务器请求一个新的优化提议。

先决条件

  • 您已 批准了优化方案
  • 重新平衡操作的 KafkaRebalance 自定义资源的状态是 NotReady

流程

  1. KafkaRebalance 状态获取有关错误的信息:

    oc describe kafkarebalance rebalance-cr-name
  2. 尝试解决 KafkaRebalance 资源中的问题。
  3. 在 OpenShift 中注解 KafkaRebalance 资源:

    oc annotate kafkarebalance rebalance-cr-name strimzi.io/rebalance=refresh
  4. 检查 KafkaRebalance 资源的状态:

    oc describe kafkarebalance rebalance-cr-name
  5. 等待状态变为 PendingProposal,或者直接更改为 ProposalReady

第 8 章 使用 Service Registry 验证模式

您可以将 Red Hat Service Registry 与 AMQ Streams 搭配使用。

Service Registry 是用于在 API 和事件驱动的架构中共享标准事件模式和 API 设计的数据存储。您可以使用 Service Registry 将数据的结构与客户端应用程序分离,并使用 REST 接口在运行时共享和管理您的数据类型和 API 描述。

服务 Registry 存储用于序列化和反序列化消息的 schema,然后从客户端应用程序引用,以确保它们发送和接收的消息与这些架构兼容。Service Registry 为 Kafka producer 和消费者应用程序提供 Kafka 客户端序列化/处理程序。Kafka producer 应用使用 serializers 对符合特定事件架构的消息进行编码。Kafka 使用者应用程序使用 deserializers,它根据特定的模式 ID 来验证消息已被序列化。

您可以使应用程序使用 registry 中的模式。这样可确保一致的模式使用,并帮助在运行时防止数据错误。

其他资源

第 9 章 分布式追踪

通过分布式追踪,您可以跟踪分布式系统中应用程序之间的事务进度。在微服务架构中,跟踪服务间的事务进度。trace 数据可用于监控应用程序性能和调查目标系统和最终用户应用程序的问题。

在 AMQ Streams 中,追踪有助于对消息的端到端跟踪:从源系统到 Kafka,然后从 Kafka 到目标系统和应用程序。它补充了可在 Grafana 仪表板 中查看的指标,以及组件日志记录器。

AMQ Streams 如何支持追踪

在以下组件中内置了对追踪的支持:

  • Kafka Connect
  • MirrorMaker
  • MirrorMaker 2.0
  • AMQ Streams Kafka Bridge

您可以使用自定义资源中的模板配置属性为这些组件启用和配置追踪。

要在 Kafka 产生者、消费者和 Kafka Streams API 应用程序中启用追踪,您可以 instrument 应用程序代码,使用 OpenTracing Apache Kafka Client Instrumentation 库(附带 AMQ Streams)。在检测程序时,客户端会生成 trace 数据;例如,当生成消息或向日志写入偏移时。

注意

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

trace 根据抽样策略抽样,然后在 Jaeger 用户界面中视觉化。

注意

Kafka 代理不支持追踪。

在 AMQ Streams 之外为应用程序和系统设置追踪不在本章范围内。要了解有关此主题的更多信息,请在 OpenTracing 文档中 搜索 "inject and extract"。

步骤概述

要为 AMQ Streams 设置追踪,请按照以下步骤执行:

先决条件

  • Jaeger 后端组件部署到 OpenShift 集群。有关部署说明,请参阅 Jaeger 文档

9.1. OpenTracing 和 Jaeger 概述

AMQ Streams 使用 OpenTracing 和 Jaeger 项目。

OpenTracing 是一种独立于追踪或监控系统的 API 规范。

  • OpenTracing API 用于检测 应用代码
  • 检测的应用程序会在 分布式系统中为独立事务生成追踪
  • trace 由 范围 组成,它们定义一段时间内的特定工作单元

Jaeger 是基于微服务的分布式系统的追踪系统。

  • Jaeger 实施 OpenTracing API,并提供客户端库以用于检测
  • Jaeger 用户界面允许您查询、过滤和分析追踪数据

The Jaeger user interface showing a simple query

其他资源

9.2. 为 Kafka 客户端设置追踪

初始化 Jaeger tracer,以检测您的客户端应用程序以进行分布式追踪。

9.2.1. 为 Kafka 客户端初始化 Jaeger tracer

使用一组 追踪环境变量 配置和初始化 Jaeger tracer。

流程

在每个客户端应用程序中:

  1. 将 Jaeger 的 Maven 依赖项添加到客户端应用程序的 pom.xml 文件中:

    <dependency>
        <groupId>io.jaegertracing</groupId>
        <artifactId>jaeger-client</artifactId>
        <version>1.5.0.redhat-00001</version>
    </dependency>
  2. 使用 追踪环境变量 定义 Jaeger tracer 的配置。
  3. 从您在第两个步骤中定义的环境变量创建 Jaeger tracer:

    Tracer tracer = Configuration.fromEnv().getTracer();
    注意

    有关初始化 Jaeger tracer 的替代方法,请参阅 Java OpenTracing 库 文档。

  4. 将 Jaeger tracer 注册为全局 tracer:

    GlobalTracer.register(tracer);

现在,为要使用的客户端应用程序初始化 Jaeger tracer。

9.2.2. 用于追踪的环境变量

在为 Kafka 客户端配置 Jaeger tracer 时使用这些环境变量。

注意

追踪环境变量是 Jaeger 项目的一部分,可能会有所变化。有关最新的环境变量,请参阅 Jaeger 文档

属性必需Description

JAEGER_SERVICE_NAME

Jaeger tracer 服务的名称。

JAEGER_AGENT_HOST

通过 User Datagram Protocol (UDP)与 jaeger-agent 通信的主机名。

JAEGER_AGENT_PORT

用于通过 UDP 与 jaeger-agent 通信的端口。

JAEGER_ENDPOINT

trace 端点。只有在客户端应用程序将绕过 jaeger-agent 并直接连接到 jaeger-collector 时,才定义此变量。

JAEGER_AUTH_TOKEN

以 bearer 令牌的形式发送到端点的身份验证令牌。

JAEGER_USER

如果使用基本身份验证发送到端点的用户名。

JAEGER_PASSWORD

如果使用基本身份验证发送到端点的密码。

JAEGER_PROPAGATION

用于传播 trace 上下文的以逗号分隔的格式列表。默认为标准 Jaeger 格式。有效值为 jaegerb3w3c

JAEGER_REPORTER_LOG_SPANS

指明报告程序是否还应记录范围。

JAEGER_REPORTER_MAX_QUEUE_SIZE

报告者的最大队列大小。

JAEGER_REPORTER_FLUSH_INTERVAL

报告者的清除间隔,以 ms 为单位。定义 Jaeger reporter flushes span batches 的频率。

JAEGER_SAMPLER_TYPE

用于客户端 trace 的抽样策略:

  • 常数
  • probabilistic
  • 速率限制
  • 远程(默认)

要示例所有 trace,请使用 Constant sampling 策略和参数 1。

如需了解 Jaeger 架构和客户端抽样配置参数概述,请参阅 Jaeger 文档

JAEGER_SAMPLER_PARAM

sampler 参数(数字)。

JAEGER_SAMPLER_MANAGER_HOST_PORT

如果选择了 Remote sampling 策略,要使用的主机名和端口。

JAEGER_TAGS

添加到所有报告的 span 的 tracer 级别标签的逗号分隔列表。

该值也可以使用 ${envVarName:default} 格式来引用环境变量。:default 是可选的,并在找不到环境变量时标识要使用的值。

9.3. 使用 tracer 检查 Kafka 客户端

检测 Kafka producer 和使用者客户端,以及用于分布式追踪的 Kafka Streams API 应用程序。

9.3.1. 提取制作者和消费者以进行追踪

使用 Decorator 模式或 Interceptors 来检测您的 Java 制作者和消费者应用程序代码进行追踪。

流程

在每个制作者和消费者应用程序的应用程序代码中:

  1. 将 OpenTracing 的 Maven 依赖项添加到制作者或消费者的 pom.xml 文件。

    <dependency>
        <groupId>io.opentracing.contrib</groupId>
        <artifactId>opentracing-kafka-client</artifactId>
        <version>0.1.15.redhat-00006</version>
    </dependency>
  2. 使用 Decorator 模式或 Interceptors 检测您的客户端应用程序代码。

    • 使用 Decorator 模式:

      // Create an instance of the KafkaProducer:
      KafkaProducer<Integer, String> producer = new KafkaProducer<>(senderProps);
      
      // Create an instance of the TracingKafkaProducer:
      TracingKafkaProducer<Integer, String> tracingProducer = new TracingKafkaProducer<>(producer,
              tracer);
      
      // Send:
      tracingProducer.send(...);
      
      // Create an instance of the KafkaConsumer:
      KafkaConsumer<Integer, String> consumer = new KafkaConsumer<>(consumerProps);
      
      // Create an instance of the TracingKafkaConsumer:
      TracingKafkaConsumer<Integer, String> tracingConsumer = new TracingKafkaConsumer<>(consumer,
              tracer);
      
      // Subscribe:
      tracingConsumer.subscribe(Collections.singletonList("messages"));
      
      // Get messages:
      ConsumerRecords<Integer, String> records = tracingConsumer.poll(1000);
      
      // Retrieve SpanContext from polled record (consumer side):
      ConsumerRecord<Integer, String> record = ...
      SpanContext spanContext = TracingKafkaUtils.extractSpanContext(record.headers(), tracer);
    • 使用 Interceptors:

      // Register the tracer with GlobalTracer:
      GlobalTracer.register(tracer);
      
      // Add the TracingProducerInterceptor to the sender properties:
      senderProps.put(ProducerConfig.INTERCEPTOR_CLASSES_CONFIG,
                TracingProducerInterceptor.class.getName());
      
      // Create an instance of the KafkaProducer:
      KafkaProducer<Integer, String> producer = new KafkaProducer<>(senderProps);
      
      // Send:
      producer.send(...);
      
      // Add the TracingConsumerInterceptor to the consumer properties:
      consumerProps.put(ConsumerConfig.INTERCEPTOR_CLASSES_CONFIG,
                TracingConsumerInterceptor.class.getName());
      
      // Create an instance of the KafkaConsumer:
      KafkaConsumer<Integer, String> consumer = new KafkaConsumer<>(consumerProps);
      
      // Subscribe:
      consumer.subscribe(Collections.singletonList("messages"));
      
      // Get messages:
      ConsumerRecords<Integer, String> records = consumer.poll(1000);
      
      // Retrieve the SpanContext from a polled message (consumer side):
      ConsumerRecord<Integer, String> record = ...
      SpanContext spanContext = TracingKafkaUtils.extractSpanContext(record.headers(), tracer);
9.3.1.1. 在 Decorator 模式中的自定义 span 名称

span 是 Jaeger 中的逻辑工作单元,包括操作名称、开始时间和持续时间。

要使用 Decorator 模式检测您的制作者和消费者应用程序,请在创建 TracingKafkaProducerTracingKafkaConsumer 对象时将 BiFunction 对象作为附加参数来定义自定义 span 名称。OpenTracing Apache Kafka Client Instrumentation 库包括几个内置范围名称。

示例:使用自定义 span 名称以 Decorator 模式检测客户端应用程序代码

// Create a BiFunction for the KafkaProducer that operates on (String operationName, ProducerRecord consumerRecord) and returns a String to be used as the name:

BiFunction<String, ProducerRecord, String> producerSpanNameProvider =
    (operationName, producerRecord) -> "CUSTOM_PRODUCER_NAME";

// Create an instance of the KafkaProducer:
KafkaProducer<Integer, String> producer = new KafkaProducer<>(senderProps);

// Create an instance of the TracingKafkaProducer
TracingKafkaProducer<Integer, String> tracingProducer = new TracingKafkaProducer<>(producer,
        tracer,
        producerSpanNameProvider);

// Spans created by the tracingProducer will now have "CUSTOM_PRODUCER_NAME" as the span name.

// Create a BiFunction for the KafkaConsumer that operates on (String operationName, ConsumerRecord consumerRecord) and returns a String to be used as the name:

BiFunction<String, ConsumerRecord, String> consumerSpanNameProvider =
    (operationName, consumerRecord) -> operationName.toUpperCase();

// Create an instance of the KafkaConsumer:
KafkaConsumer<Integer, String> consumer = new KafkaConsumer<>(consumerProps);

// Create an instance of the TracingKafkaConsumer, passing in the consumerSpanNameProvider BiFunction:

TracingKafkaConsumer<Integer, String> tracingConsumer = new TracingKafkaConsumer<>(consumer,
        tracer,
        consumerSpanNameProvider);

// Spans created by the tracingConsumer will have the operation name as the span name, in upper-case.
// "receive" -> "RECEIVE"

9.3.1.2. 内置范围名称

在定义自定义范围名称时,您可以在 ClientSpanNameProvider 类中使用以下 BiFunctions。如果没有指定 spanNameProvider,则使用 CONSUMER_OPERATION_NAMEPRODUCER_OPERATION_NAME

BiFunctionDescription

CONSUMER_OPERATION_NAME, PRODUCER_OPERATION_NAME

返回 operationName 作为使用者和"end"的 span name: "receive"。

CONSUMER_PREFIXED_OPERATION_NAME (字符串前缀)、PRODUCER_PREFIXED_OPERATION_NAME (字符串前缀)

返回 前缀operationName 的字符串。

CONSUMER_TOPIC, PRODUCER_TOPIC

以格式 (record.topic ()) 返回消息发送到或检索的主题名称。

PREFIXED_CONSUMER_TOPIC (字符串前缀)、PREFIXED_PRODUCER_TOPIC (字符串前缀)

返回 前缀的 String connection,以及格式为 (record.topic ()) 的主题名称。

CONSUMER_OPERATION_NAME_TOPIC, PRODUCER_OPERATION_NAME_TOPIC

返回操作名称和主题名称:" operationName - record.topic ()"

CONSUMER_PREFIXED_OPERATION_NAME_TOPIC (字符串前缀)、PRODUCER_PREFIXED_OPERATION_NAME_TOPIC (字符串前缀)

返回 前缀 String linkion 和 "operationName - record.topic ()"

9.3.2. 用于追踪的 Kafka Streams 应用程序

本节论述了如何使用 Kafka Streams API 应用程序进行分布式追踪。

流程

在每个 Kafka Streams API 应用程序中:

  1. opentracing-kafka-streams 依赖项添加到 Kafka Streams API 应用程序的 pom.xml 文件中:

    <dependency>
        <groupId>io.opentracing.contrib</groupId>
        <artifactId>opentracing-kafka-streams</artifactId>
        <version>0.1.15.redhat-00006</version>
    </dependency>
  2. 创建 TracingKafkaClientSupplier 供应商接口实例:

    KafkaClientSupplier supplier = new TracingKafkaClientSupplier(tracer);
  3. KafkaStreams 提供供应商接口:

    KafkaStreams streams = new KafkaStreams(builder.build(), new StreamsConfig(config), supplier);
    streams.start();

9.4. 为 MirrorMaker、Kafka Connect 和 Kafka Bridge 设置追踪

MirrorMaker、MirrorMaker 2.0、Kafka Connect 和 AMQ Streams Kafka Bridge 支持分布式追踪。

MirrorMaker 和 MirrorMaker 2.0 中的追踪

对于 MirrorMaker 和 MirrorMaker 2.0,信息会根据源集群追踪到目标集群。trace 数据记录输入并离开 MirrorMaker 或 MirrorMaker 2.0 组件的消息。

Kafka Connect 中的追踪

只有 Kafka Connect 本身生成和使用的消息才会被追踪。要跟踪 Kafka Connect 和外部系统之间发送的消息,您必须在连接器中配置这些系统的追踪。更多信息请参阅 第 2.3.1 节 “配置 Kafka 连接”

在 Kafka Bridge 中的追踪

Kafka Bridge 生成并消耗的消息会被追踪。另外还会跟踪来自客户端应用程序来发送和接收通过 Kafka Bridge 的信息的 HTTP 请求。要具有端到端追踪,您必须在 HTTP 客户端中配置追踪。

9.4.1. 在 MirrorMaker、Kafka Connect 和 Kafka Bridge 资源中启用追踪

更新 KafkaMirrorMakerKafkaMirrorMaker2KafkaConnectKafkaBridge 自定义资源的配置,为每个资源指定并配置 Jaeger tracer 服务。更新 OpenShift 集群中启用了追踪的资源会触发两个事件:

  • 拦截器类在 MirrorMaker、MirrorMaker 2.0、Kafka Connect 或 AMQ Streams Kafka Bridge 中的集成使用者和生产者更新。
  • 对于 MirrorMaker、MirrorMaker 2.0 和 Kafka Connect,追踪代理根据资源中定义的追踪配置初始化 Jaeger tracer。
  • 对于 Kafka Bridge,基于资源中定义的追踪配置由 Kafka Bridge 本身初始化 Jaeger tracer。

流程

为每个 KafkaMirrorMakerKafkaMirrorMaker2KafkaConnectKafkaBridge 资源执行这些步骤。

  1. spec.template 属性中配置 Jaeger tracer 服务。例如:

    Kafka Connect 的 Jaeger tracer 配置

    apiVersion: kafka.strimzi.io/v1beta2
    kind: KafkaConnect
    metadata:
      name: my-connect-cluster
    spec:
      #...
      template:
        connectContainer: 1
          env:
            - name: JAEGER_SERVICE_NAME
              value: my-jaeger-service
            - name: JAEGER_AGENT_HOST
              value: jaeger-agent-name
            - name: JAEGER_AGENT_PORT
              value: "6831"
      tracing: 2
        type: jaeger
      #...

    MirrorMaker 的 Jaeger tracer 配置

    apiVersion: kafka.strimzi.io/v1beta2
    kind: KafkaMirrorMaker
    metadata:
      name: my-mirror-maker
    spec:
      #...
      template:
        mirrorMakerContainer:
          env:
            - name: JAEGER_SERVICE_NAME
              value: my-jaeger-service
            - name: JAEGER_AGENT_HOST
              value: jaeger-agent-name
            - name: JAEGER_AGENT_PORT
              value: "6831"
      tracing:
        type: jaeger
    #...

    MirrorMaker 2.0 的 Jaeger tracer 配置

    apiVersion: kafka.strimzi.io/v1beta2
    kind: KafkaMirrorMaker2
    metadata:
      name: my-mm2-cluster
    spec:
      #...
      template:
        connectContainer:
          env:
            - name: JAEGER_SERVICE_NAME
              value: my-jaeger-service
            - name: JAEGER_AGENT_HOST
              value: jaeger-agent-name
            - name: JAEGER_AGENT_PORT
              value: "6831"
      tracing:
        type: jaeger
    #...

    Kafka Bridge 的 Jaeger tracer 配置

    apiVersion: kafka.strimzi.io/v1beta2
    kind: KafkaBridge
    metadata:
      name: my-bridge
    spec:
      #...
      template:
        bridgeContainer:
          env:
            - name: JAEGER_SERVICE_NAME
              value: my-jaeger-service
            - name: JAEGER_AGENT_HOST
              value: jaeger-agent-name
            - name: JAEGER_AGENT_PORT
              value: "6831"
      tracing:
        type: jaeger
    #...

    1
    使用 追踪环境变量 作为模板配置属性。
    2
    spec.tracing.type 属性设为 jaeger
  2. 创建或更新资源:

    oc apply -f your-file

第 10 章 管理 TLS 证书

AMQ Streams 支持 TLS 用于 Kafka 和 AMQ Streams 组件之间的加密通信。

通信始终在以下组件间加密:

  • Kafka 和 ZooKeeper 之间的通信
  • Kafka 代理间的 Interbroker 通信
  • ZooKeeper 节点间的交互通信
  • AMQ Streams operator 通信 Kafka 代理和 ZooKeeper 节点

Kafka 客户端和 Kafka 代理之间的通信会根据集群的配置加密。对于 Kafka 和 AMQ Streams 组件,TLS 证书也用于身份验证。

Cluster Operator 会自动设置并更新 TLS 证书,以便在集群中启用加密和身份验证。如果您想在 Kafka 代理和客户端之间启用加密或 TLS 身份验证,它还设置其他 TLS 证书。

证书颁发机构(CA)证书由 Cluster Operator 生成,以验证组件和客户端的身份。如果您不想使用 Cluster Operator 生成的 CA,您可以安装自己的集群和客户端 CA 证书

您还可以为启用了 TLS 加密的 TLS 监听器或外部监听程序 提供 Kafka 侦听器证书。使用 Kafka 侦听器证书包含您已掌握的安全基础架构。

注意

您提供的任何证书都不会由 Cluster Operator 更新。

图 10.1. TLS 保护的通信架构示例

安全通信

10.1. 证书授权

要支持加密,每个 AMQ Streams 组件需要自己的私钥和公钥证书。所有组件证书都由称为 集群 CA 的内部证书颁发机构(CA)签名。

同样,使用 TLS 客户端身份验证连接到 AMQ Streams 的每个 Kafka 客户端应用程序都需要提供私钥和证书。第二个内部 CA 用于指定 客户端 CA,用于为 Kafka 客户端签署证书。

10.1.1. CA 证书

集群 CA 和客户端 CA 都有一个自签名的公钥证书。

Kafka 代理配置为信任由集群 CA 或客户端 CA 签名的证书。客户端不需要连接的组件,如 ZooKeeper,只有由集群 CA 签名的信任证书。除非禁用外部监听器的 TLS 加密,客户端应用程序必须信任由集群 CA 签名的证书。对于执行 相互 TLS 身份验证的客户端应用程序,这也适用

默认情况下,AMQ Streams 会自动生成并续订由集群 CA 或客户端 CA 发布的 CA 证书。您可以在 Kafka.spec.clusterCaKafka.spec.clientsCa 对象中配置这些 CA 证书的管理。用户提供的证书不会被更新。

您可以为集群 CA 或客户端 CA 提供自己的 CA 证书。更多信息请参阅 第 10.1.2 节 “安装您自己的 CA 证书”。如果您提供自己的证书,则必须在需要时手动续订。

10.1.2. 安装您自己的 CA 证书

这个步骤描述了如何安装自己的 CA 证书和密钥,而不是使用 Cluster Operator 生成的 CA 证书和私钥。

Cluster Operator 会自动生成和更新以下 secret:

CLUSTER-NAME-cluster-ca
包含集群 CA 私钥的集群 secret。
CLUSTER-NAME-cluster-ca-cert
包含集群 CA 证书的集群 secret。证书包含验证 Kafka 代理身份的公钥。
CLUSTER-NAME-clients-ca
包含客户端 CA 私钥的客户端 secret。
CLUSTER-NAME-clients-ca-cert
包含客户端 CA 证书的客户端 secret。证书包含一个公钥,用于验证客户端访问 Kafka 代理的客户端身份。

AMQ Streams 默认使用这些 secret。

此流程描述了替换 secret 使用您自己的集群或客户端 CA 证书的步骤。

先决条件

  • Cluster Operator 正在运行。
  • Kafka 集群尚未部署。
  • 您自己的 X.509 证书和密钥,采用 PEM 格式集群 CA 或客户端 CA。

    • 如果要使用不是 Root CA 的集群或客户端 CA,则必须在证书文件中包括整个链。链应该按照以下顺序:

      1. 集群或客户端 CA
      2. 一个或多个中间 CA
      3. Root CA
    • 链中的所有 CA 都应该使用 X509v3 基本限制扩展进行配置。基本限制限制证书链的路径长度。
  • 用于转换证书的 OpenSSL TLS 管理工具。

开始前

Cluster Operator 为 CLUSTER-NAME-cluster-ca-cert secret 生成以下文件:

  • 使用 PEM 格式的 CA.crt 集群证书
  • PKCS #12 格式的 CA .p12 集群证书
  • ca.password 以访问 PKCS #12 文件

有些应用程序无法使用 PEM 证书并支持 PKCS #12 证书。您还可以使用 PKCS #12 格式添加您自己的集群证书。

如果您没有 PKCS #12 格式的集群证书,请使用 OpenSSL TLS 管理工具从 ca.crt 文件中生成一个。

证书生成命令示例

openssl pkcs12 -export -in ca.crt --nokeys -out ca.p12 -password pass:P12-PASSWORD -caname ca.crt

P12-PASSWORD 替换为您自己的密码。

您可以为 CLUSTER-NAME-clients-ca-cert secret 执行相同的操作,它还会默认在 PEM 和 PKCS #12 格式中包含证书。

流程

  1. 替换 Cluster Operator 生成的 CA 证书。

    1. 删除现有的 secret。

      oc delete secret CA-CERTIFICATE-SECRET

      ca-CERTIFICATE-SECRETSecret 的名称:

      • 集群 CA 证书的 CLUSTER-NAME-cluster-ca-cert
      • CLUSTER-NAME-clients-ca-cert 用于客户端 CA 证书

      CLUSTER-NAME 替换为 Kafka 集群的名称。

      忽略任何 "Not Exists" 错误。

    2. 创建新 secret。

      仅在 PEM 格式使用证书创建客户端 secret

      oc create secret generic CLUSTER-NAME-clients-ca-cert --from-file=ca.crt=ca.crt

      使用 PEM 和 PKCS #12 格式的证书创建集群 secret

      oc create secret generic CLUSTER-NAME-cluster-ca-cert \
        --from-file=ca.crt=ca.crt \
        --from-file=ca.p12=ca.p12 \
        --from-literal=ca.password=P12-PASSWORD

  2. 替换 Cluster Operator 生成的私钥。

    1. 删除现有的 secret。

      oc delete secret CA-KEY-SECRET

      ca-KEY-SECRET 是 CA 密钥的名称:

      • 集群 CA 键的 CLUSTER-NAME-cluster-ca
      • 客户端 CA 密钥的 CLUSTER-NAME-clients-ca
    2. 创建新 secret。

      oc create secret generic CA-KEY-SECRET --from-file=ca.key=ca.key
  3. 标记 secret。

    oc label secret CA-CERTIFICATE-SECRET strimzi.io/kind=Kafka strimzi.io/cluster=CLUSTER-NAME
    oc label secret CA-KEY-SECRET strimzi.io/kind=Kafka strimzi.io/cluster=CLUSTER-NAME
    • 标签 strimzi.io/kind=Kafka 标识 Kafka 自定义资源。
    • 标签 strimzi.io/cluster=CLUSTER-NAME 标识 Kafka 集群。
  4. 注解 secret

    oc annotate secret CA-CERTIFICATE-SECRET strimzi.io/ca-cert-generation=CA-CERTIFICATE-GENERATION
    oc annotate secret CA-KEY-SECRET strimzi.io/ca-key-generation=CA-KEY-GENERATION
    • 注解 strimzi.io/ca-cert-generation=CA-CERTIFICATE-GENERATION 定义新 CA 证书的生成。
    • 注解 strimzi.io/ca-key-generation=CA-KEY-GENERATION 定义新 CA 密钥的生成。

      如果您要自动替换 Cluster Operator 生成的 CA 证书,请使用现有注解中的下一个增量值,并遵循 替换 CA 密钥流程。如果没有 Cluster Operator 会自动生成的 CA 证书,请从 0 (零)开始作为增量值(strimzi.io/ca-cert-generation=0)作为您自己的 CA 证书。在更新证书时设置更高的增量值。

  5. 为集群创建 Kafka 资源,配置 Kafka.spec.clusterCaKafka.spec.clientsCa 对象来 不使用 生成的 CA。

    配置集群 CA 的片段 Kafka 资源示例,使用您提供的证书

    kind: Kafka
    version: kafka.strimzi.io/v1beta2
    spec:
      # ...
      clusterCa:
        generateCertificateAuthority: false

其他资源

10.2. Secrets

AMQ Streams 使用 secret 为 Kafka 集群、客户端和用户存储私有和公钥证书。secret 用于在 Kafka 代理和代理和客户端之间建立 TLS 加密的连接。它们也用于相互 TLS 身份验证。

集群和客户端 secret 始终对:一个包含公钥,另一个包含私钥。

集群 secret
集群 secret 包含用于为 Kafka 代理证书签名 的集群 CA。连接客户端使用证书与 Kafka 集群建立 TLS 加密连接。证书验证代理身份。
客户端机密
客户端 secret 包含用户用来签署自己的客户端证书的客户端 CA。这允许对 Kafka 集群进行 mutual身份验证。代理通过证书验证客户端的身份。
用户 secret
用户 secret 包含私钥和证书。在创建新用户时,secret 由客户端 CA 创建并签名。密钥和证书用于验证和授权用户访问集群时的用户。

10.2.1. PEM 和 PKCS #12 格式的 secret

secret 以 PEM 和 PKCS #12 格式提供私钥和证书。使用适用于您的客户端的格式。以 PEM 格式使用私钥和证书意味着用户必须从机密中获取它们,并生成相应的信任存储或密钥存储以在其应用程序中使用。PKCS #12 存储提供了可直接使用的信任存储或密钥存储。

PKCS #12 定义了一个归档文件格式(.p12),用于将加密对象存储到单个文件中,并设有密码保护。您可以使用 PKCS #12 管理一个位置的证书和密钥。

每个 secret 都包含特定于 PKCS #12 的字段。

  • .p12 字段包含证书和密钥。
  • .password 字段是保护归档的密码。

所有密钥的大小都是 2048 位,且默认情况下为从初始生成起 365 天有效。您可以更改有效期

10.2.2. Cluster Operator 生成的 secret

Cluster Operator 生成以下证书,该证书保存为 OpenShift 集群中的 secret。AMQ Streams 默认使用这些 secret。

集群 CA 和客户端 CA 为私钥和公钥有单独的 secret。

<cluster_name>-cluster-ca
包含集群 CA 的私钥。AMQ Streams 和 Kafka 组件使用私钥为服务器证书签名。
<cluster_name>-cluster-ca-cert
包含集群 CA 的公钥。Kafka 客户端使用公钥验证它们正通过 TLS 服务器身份验证连接的 Kafka 代理的身份。
<cluster_name>-clients-ca
包含客户端 CA 的私钥。Kafka 客户端在连接到 Kafka 代理时使用私钥为 TLS 客户端身份验证签名新的用户证书。
<cluster_name>-clients-ca-cert
包含客户端 CA 的公钥。Kafka 代理使用公钥验证在使用 TLS 客户端身份验证时验证客户端访问 Kafka 代理的客户端身份。

AMQ Streams 组件间的通信 secret 包括一个由集群 CA 签名的公钥证书。

<cluster_name>-kafka-brokers
包含 Kafka 代理的私钥和公钥。
<cluster_name>-zookeeper-nodes
包含 ZooKeeper 节点的私钥和公钥。
<cluster_name>-cluster-operator-certs
包含加密集群 Operator 和 Kafka 或 ZooKeeper 之间通信的私钥和公钥。
<cluster_name>-entity-topic-operator-certs
包含加密主题 Operator 和 Kafka 或 ZooKeeper 之间通信的私钥和公钥。
<cluster_name>-entity-user-operator-certs
包含加密用户 Operator 和 Kafka 或 ZooKeeper 之间通信的私钥和公钥。
<cluster_name>-cruise-control-certs
包含加密 Cruise Control 和 Kafka 或 ZooKeeper 之间通信的私钥和公钥。
<cluster_name>-kafka-exporter-certs
包含加密 Kafka 导出器和 Kafka 或 ZooKeeper 之间通信的私钥和公钥。
注意

您可以提供自己的服务器证书和私钥,以使用 Kafka 侦听器证书 连接到 Kafka 代理,而不是由集群 CA 或客户端 CA 签名的证书。

10.2.3. 集群 CA secret

集群 CA secret 由 Kafka 集群中的 Cluster Operator 管理。

客户端只需要 <cluster_name> -cluster-ca-cert secret。所有其他集群 secret 都可通过 AMQ Streams 组件访问。如果需要,您可以使用 OpenShift 基于角色的访问控制来执行此操作。

注意

Kafka 客户端应用程序必须信任 <cluster_name> -cluster-ca-cert 中的 CA 证书,以便在通过 TLS 连接到 Kafka 代理时验证 Kafka 代理证书。

表 10.1. < cluster_name>-cluster-ca secret 中的字段
字段Description

ca.key

集群 CA 的当前私钥。

表 10.2. < cluster_name>-cluster-ca-cert secret 中的字段
字段Description

ca.p12

PKCS #12 归档文件用于存储证书和密钥。

ca.password

用于保护 PKCS #12 归档文件的密码。

ca.crt

集群 CA 的当前证书。

表 10.3. < cluster_name>-kafka-brokers secret 中的字段
字段Description

<cluster_name>-kafka-<num>.p12

PKCS #12 归档文件用于存储证书和密钥。

<cluster_name>-kafka-<num>.password

用于保护 PKCS #12 归档文件的密码。

<cluster_name>-kafka-<num>.crt

Kafka 代理 pod < num> 的证书。由 <cluster _name> -cluster-ca 中的当前或以前的集群 CA 私钥签名。

<cluster_name>-kafka-<num>.key

Kafka 代理 pod < num&gt; 的私钥。

表 10.4. < cluster_name>-zookeeper-nodes secret 中的字段
字段Description

<cluster_name>-zookeeper-<num>.p12

PKCS #12 归档文件用于存储证书和密钥。

<cluster_name>-zookeeper-<num>.password

用于保护 PKCS #12 归档文件的密码。

<cluster_name>-zookeeper-<num>.crt

ZooKeeper node < num> 的证书。由 <cluster _name> -cluster-ca 中的当前或以前的集群 CA 私钥签名。

<cluster_name>-zookeeper-<num>.key

ZooKeeper pod < num> 的私钥。

表 10.5. < cluster_name>-cluster-operator-certs secret 中的字段
字段Description

cluster-operator.p12

PKCS #12 归档文件用于存储证书和密钥。

cluster-operator.password

用于保护 PKCS #12 归档文件的密码。

cluster-operator.crt

Cluster Operator 和 Kafka 或 ZooKeeper 之间的 TLS 通信的证书。由 <cluster _name> -cluster-ca 中的当前或以前的集群 CA 私钥签名。

cluster-operator.key

Cluster Operator 和 Kafka 或 ZooKeeper 之间的 TLS 通信的私钥。

表 10.6. < cluster_name>-entity-topic-operator-certs secret 中的字段
字段Description

entity-operator.p12

PKCS #12 归档文件用于存储证书和密钥。

entity-operator.password

用于保护 PKCS #12 归档文件的密码。

entity-operator.crt

主题 Operator 和 Kafka 或 ZooKeeper 之间的 TLS 通信证书。由 <cluster _name> -cluster-ca 中的当前或以前的集群 CA 私钥签名。

entity-operator.key

适用于主题 Operator 和 Kafka 或 ZooKeeper 间的 TLS 通信的私钥。

表 10.7. < cluster_name>-entity-user-operator-certs secret 中的字段
字段Description

entity-operator.p12

PKCS #12 归档文件用于存储证书和密钥。

entity-operator.password

用于保护 PKCS #12 归档文件的密码。

entity-operator.crt

用户 Operator 和 Kafka 或 ZooKeeper 之间的 TLS 通信证书。由 <cluster _name> -cluster-ca 中的当前或以前的集群 CA 私钥签名。

entity-operator.key

用户 Operator 和 Kafka 或 ZooKeeper 之间的 TLS 通信的私钥。

表 10.8. < cluster_name>-cruise-control-certs secret 中的字段
字段Description

cruise-control.p12

PKCS #12 归档文件用于存储证书和密钥。

cruise-control.password

用于保护 PKCS #12 归档文件的密码。

cruise-control.crt

Cruise 控制和 Kafka 或 ZooKeeper 之间的 TLS 通信证书。由 <cluster _name> -cluster-ca 中的当前或以前的集群 CA 私钥签名。

cruise-control.key

用于 Cruise 控制和 Kafka 或 ZooKeeper 之间的 TLS 通信的私钥。

表 10.9. < cluster_name>-kafka-exporter-certs secret 中的字段
字段Description

kafka-exporter.p12

PKCS #12 归档文件用于存储证书和密钥。

kafka-exporter.password

用于保护 PKCS #12 归档文件的密码。

kafka-exporter.crt

Kafka Exporter 和 Kafka 或 ZooKeeper 之间的 TLS 通信证书。由 <cluster _name> -cluster-ca 中的当前或以前的集群 CA 私钥签名。

kafka-exporter.key

Kafka Exporter 和 Kafka 或 ZooKeeper 之间的 TLS 通信的私钥。

10.2.4. 客户端 CA secret

客户端 CA secret 由 Kafka 集群中的 Cluster Operator 管理。

< cluster_name&gt; -clients-ca-cert 中的证书是 Kafka 代理信任的证书。

& lt;cluster_name> -clients-ca secret 用于签署客户端应用程序的证书。如果打算在不使用 User Operator 的情况下发布应用程序证书,则必须访问该 secret。AMQ Streams 组件以及管理访问权限需要被访问。如果需要,您可以使用 OpenShift 基于角色的访问控制来执行此操作。

表 10.10. < cluster_name>-clients-ca secret 中的字段
字段Description

ca.key

客户端 CA 的当前私钥。

表 10.11. < cluster_name>-clients-ca-cert secret 中的字段
字段Description

ca.p12

PKCS #12 归档文件用于存储证书和密钥。

ca.password

用于保护 PKCS #12 归档文件的密码。

ca.crt

客户端 CA 的当前证书。

10.2.5. 用户 secret

用户 secret 由 User Operator 管理。

使用 User Operator 创建用户时,会使用用户名称生成 secret。

表 10.12. user_name secret 中的字段
Secret 名称secret 中的字段Description

<user_name>

user.p12

PKCS #12 归档文件用于存储证书和密钥。

user.password

用于保护 PKCS #12 归档文件的密码。

user.crt

用户的证书,由客户端 CA 签名

user.key

用户的私钥

10.2.6. 在集群 CA secret 中添加标签和注解

通过在 Kafka 自定义资源中配置 clusterCaCert template 属性,您可以在 Cluster Operator 创建的 Cluster CA secret 中添加自定义标签和注解。标签和注解可用于识别对象和添加上下文信息。您可以在 AMQ Streams 自定义资源中配置模板属性。

将标签和注解添加到 secret 的模板自定义示例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    template:
      clusterCaCert:
        metadata:
          labels:
            label1: value1
            label2: value2
          annotations:
            annotation1: value1
            annotation2: value2
    # ...

有关配置模板属性的详情请参考 第 2.8 节 “自定义 OpenShift 资源”

10.2.7. 在 CA secret 中禁用 ownerReference

默认情况下,Cluster 和 Client CA secret 使用设置为 Kafka 自定义资源的 ownerReference 属性创建。这意味着,当删除 Kafka 自定义资源时,OpenShift 也会删除(智能)删除 CA secret。

如果要为新集群重复使用 CA,您可以通过将 Kafka 配置中的 Cluster 和 Client CA secret 的 generateSecretOwnerReference 设置为 false 来禁用 ownerReference。当禁用 ownerReference 时,当删除对应的 Kafka 自定义资源时,OpenShift 不会删除 CA secret。

集群和客户端 CA 禁用 ownerReference s 的 Kafka 配置示例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
# ...
spec:
# ...
  clusterCa:
    generateSecretOwnerReference: false
  clientsCa:
    generateSecretOwnerReference: false
# ...

10.3. 证书续订有效期

集群 CA 和客户端 CA 证书仅在有限的时间段内有效,称为有效期。这通常定义为自生成证书起的天数。

对于 Cluster Operator 自动创建的 CA 证书,您可以配置以下有效期:

  • Cluster CA certificates in Kafka.spec.clusterCa.validityDays
  • Kafka.spec.clientsCa.validityDays中的客户端 CA 证书

两个证书的默认有效期周期为 365 天。手动安装的 CA 证书应该定义了自己的有效期。

当 CA 证书过期时,仍信任该证书的组件和客户端不接受来自由 CA 私钥签名的证书的对等的 TLS 连接。组件和客户端需要信任 新的 CA 证书。

要允许在缺少服务的情况下续订 CA 证书,Cluster Operator 会在旧 CA 证书过期前启动证书续订。

您可以配置 Cluster Operator 创建的证书的续订周期:

  • Kafka.spec.clusterCa.renewalDays中的集群 CA 证书
  • Kafka.spec.clientsCa.renewalDays中的客户端 CA 证书

两个证书的默认续订周期为 30 天。

从当前证书的过期日期后,后来测量续订周期。

针对续订的有效期

Not Before                                     Not After
    |                                              |
    |<--------------- validityDays --------------->|
                              <--- renewalDays --->|

要在创建 Kafka 集群后更改有效期和续订周期,请配置并应用 Kafka 自定义资源,并 手动更新 CA 证书。如果您不手动续订证书,下一次证书被自动续订时将使用新的周期。

证书有效期和续订周期的 Kafka 配置示例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
# ...
spec:
# ...
  clusterCa:
    renewalDays: 30
    validityDays: 365
    generateCertificateAuthority: true
  clientsCa:
    renewalDays: 30
    validityDays: 365
    generateCertificateAuthority: true
# ...

在续订期间,Cluster Operator 的行为取决于证书生成属性的设置,generateCertificateAuthoritygenerateCertificateAuthority

true
如果属性被设置为 true,Cluster Operator 会自动生成 CA 证书,并在续订周期内自动续订。
false
如果属性设置为 false,Cluster Operator 不会生成 CA 证书。如果您要 安装自己的证书,则使用此选项。

10.3.1. 使用自动生成的 CA 证书的续订过程

Cluster Operator 执行以下操作以续订 CA 证书:

  1. 生成新的 CA 证书,但保留现有的密钥。新证书将旧证书替换为对应 Secret 中的名称 ca.crt
  2. 生成新客户端证书(用于 ZooKeeper 节点、Kafka 代理和实体 Operator)。这并非绝对必要,因为签名密钥没有更改,但它会使客户端证书的有效性期与 CA 证书保持同步。
  3. 重启 ZooKeeper 节点,以便他们信任新的 CA 证书并使用新的客户端证书。
  4. 重启 Kafka 代理,以便它们信任新的 CA 证书并使用新的客户端证书。
  5. 重启主题和用户 Operator,以便他们信任新的 CA 证书并使用新的客户端证书。

10.3.2. 客户端证书续订

Cluster Operator 不知道使用 Kafka 集群的客户端应用程序。

当连接到集群时,并确保它们正常工作,客户端应用程序必须:

  • 信任 <cluster> - cluster-ca-cert Secret 中发布的集群 CA 证书。
  • 使用 < user-name> Secret 中发布的凭证来连接集群。

    User Secret 以 PEM 和 PKCS #12 格式提供凭证,或使用 SCRAM-SHA 身份验证时提供密码。User Operator 在创建用户时创建用户凭证。

您必须确保客户端在证书续订后继续工作。续订过程取决于如何配置客户端。

如果要手动置备客户端证书和密钥,您必须生成新的客户端证书,并确保客户端在续订期间使用新证书。续订周期结束时未能执行此操作,可能会导致客户端应用程序无法连接到集群。

注意

对于在同一 OpenShift 集群和命名空间中运行的工作负载,机密可以挂载为卷,以便客户端 Pod 从 Secret 的当前状态构建其密钥存储和信任存储。有关此步骤的详情,请参阅配置内部客户端以信任集群 CA

10.3.3. 手动更新 Cluster Operator 生成的 CA 证书

Cluster Operator 生成的集群和客户端 CA 证书会在对应的证书续订期间开始自动续订。但是,您可以在证书续订周期开始前,使用 strimzi.io/force-renew 注解手动续订这些证书。出于安全考虑,或者您已 更改了证书的续订或有效期期,您可能会这样做。

续订的证书使用与旧证书相同的私钥。

注意

如果您使用自己的 CA 证书,则无法使用 force-renew 注解。相反,请按照流程 更新您自己的 CA 证书

先决条件

  • Cluster Operator 正在运行。
  • 安装 CA 证书和私钥的 Kafka 集群。

流程

  1. strimzi.io/force-renew 注解应用到包含您要续订的 CA 证书的 Secret

    表 10.13. 强制续订证书的 Secret 注解
    证书Secretannotate 命令

    集群 CA

    KAFKA-CLUSTER-NAME-cluster-ca-cert

    oc annotate secret KAFKA-CLUSTER-NAME-cluster-ca-cert strimzi.io/force-renew=true

    客户端 CA

    KAFKA-CLUSTER-NAME-clients-ca-cert

    oc annotate secret KAFKA-CLUSTER-NAME-clients-ca-cert strimzi.io/force-renew=true

    在下一次协调时,Cluster Operator 会为您注解的 Secret 生成新的 CA 证书。如果配置了维护时间窗口,Cluster Operator 会在下一次维护时间窗口首次协调时生成新的 CA 证书。

    客户端应用程序必须重新载入 Cluster Operator 续订的集群和客户端 CA 证书。

  2. 检查 CA 证书的期间:

    例如,使用 openssl 命令:

    oc get secret CA-CERTIFICATE-SECRET -o 'jsonpath={.data.CA-CERTIFICATE}' | base64 -d | openssl x509 -subject -issuer -startdate -enddate -noout

    CA-CERTIFICATE-SECRETSecret 的名称,即 KAFKA-CLUSTER-NAME-cluster-ca-cert,用于集群 CA 证书和 KAFKA-CLUSTER-NAME-clients-ca-cert

    CA-CERTIFICATE 是 CA 证书的名称,如 jsonpath={.data.ca\.crt}

    该命令返回一个 notBeforenotAfter 日期,这是 CA 证书的有效性周期。

    例如,对于集群 CA 证书:

    subject=O = io.strimzi, CN = cluster-ca v0
    issuer=O = io.strimzi, CN = cluster-ca v0
    notBefore=Jun 30 09:43:54 2020 GMT
    notAfter=Jun 30 09:43:54 2021 GMT
  3. 从 Secret 中删除旧证书。

    当组件使用新证书时,旧的证书可能仍在激活。删除旧的证书以移除任何潜在的安全风险。

10.3.4. 替换由 Cluster Operator 生成的 CA 证书使用的私钥

您可以替换由 Cluster Operator 生成的集群 CA 和客户端 CA 证书使用的私钥。当替换私钥时,Cluster Operator 会为新私钥生成新的 CA 证书。

注意

如果您使用自己的 CA 证书,则无法使用 force-replace 注解。相反,请按照流程 更新您自己的 CA 证书

先决条件

  • Cluster Operator 正在运行。
  • 安装 CA 证书和私钥的 Kafka 集群。

流程

  • strimzi.io/force-replace 注解应用到包含您要续订的私钥的 Secret

    表 10.14. 替换私钥的命令
    私钥:Secretannotate 命令

    集群 CA

    CLUSTER-NAME-cluster-ca

    oc annotate secret CLUSTER-NAME-cluster-ca strimzi.io/force-replace=true

    客户端 CA

    CLUSTER-NAME-clients-ca

    oc annotate secret CLUSTER-NAME-clients-ca strimzi.io/force-replace=true

在下一次协调 Cluster Operator 时:

  • 为您注解的 Secret 生成新私钥
  • 生成一个新的 CA 证书

如果配置了维护时间窗口,Cluster Operator 会在下一次维护时间窗口第一次协调时生成新的私钥和 CA 证书。

客户端应用程序必须重新载入 Cluster Operator 续订的集群和客户端 CA 证书。

10.3.5. 更新您自己的 CA 证书

此流程描述了如何更新您使用的 CA 证书而不是 Cluster Operator 生成的证书。

如果您没有更改对应的 CA 密钥,请执行以下步骤。否则,执行 替换您自己的 CA 证书所使用的私钥 的步骤。

如果您使用自己的证书,Cluster Operator 不会自动续订。因此,务必要在证书续订期间遵循这个步骤,以替换很快过期的 CA 证书。

该流程描述了 PEM 格式更新 CA 证书。

先决条件

流程

  1. 更新 CA 证书的 Secret

    编辑现有的 secret 以添加新 CA 证书并更新证书生成注解值。

    oc edit secret <ca_certificate_secret_name>

    <ca_certificate_secret_name > 是 Secret 的名称,这是集群 CA 证书的 < kafka_cluster_name> -cluster-ca-cert,以及客户端 CA 证书的 < kafka_cluster_name> -clients-ca-cert

    以下示例显示了与名为 my-cluster 的 Kafka 集群关联的集群 CA 证书的 secret。

    集群 CA 证书的 secret 配置示例

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

    1
    当前 base64 编码的 CA 证书
    2
    当前 CA 证书生成注解值
  2. 将新 CA 证书编码为 base64。

    cat <path_to_new_certificate> | base64
  3. 更新 CA 证书。

    将上一步中的 base64 编码的 CA 证书复制为 data 下的 ca.crt 属性的值。

  4. 增加 CA 证书生成注解的值。

    使用更高的增量值更新 strimzi.io/ca-cert-generation 注解。例如,将 strimzi.io/ca-cert-generation=0 更改为 strimzi.io/ca-cert-generation=1。如果 Secret 缺少注解,则值将被视为 0, 因此添加带有值 1 的注解。

    当 AMQ Streams 生成证书时,Cluster Operator 会自动递增证书生成注解。要手动续订您自己的 CA 证书,请使用更高的增量值设置注解。该注解需要高于当前 secret 中的值,以便 Cluster Operator 可以部署 Pod 并更新证书。strimzi.io/ca-cert-generation 必须在每次 CA 证书续订时递增。

  5. 使用新的 CA 证书和证书生成注解值保存 secret。

    使用新 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 证书生成注解值

在下一协调中,Cluster Operator 执行 ZooKeeper、Kafka 和其他组件的滚动更新,以信任新的 CA 证书。

如果配置了维护时间窗口,Cluster Operator 会在下一次维护时间窗口中第一次协调时部署 pod。

10.3.6. 替换您自己的 CA 证书使用的私钥

此流程描述了如何更新您使用的 CA 证书和私钥,而不是由 Cluster Operator 生成的证书和密钥。

当您还要更改对应的 CA 密钥时,执行此步骤中的步骤。否则,请执行以下步骤以 续订您自己的 CA 证书

如果您使用自己的证书,Cluster Operator 不会自动续订。因此,务必要在证书续订期间遵循这个步骤,以替换很快过期的 CA 证书。

该流程描述了 PEM 格式更新 CA 证书。

在执行以下步骤前,请确保新 CA 证书的 CN (Common Name)与当前证书不同。例如,当 Cluster Operator 自动续订证书时,它会添加一个 v<version_number& gt; 后缀来标识版本。在每个续订中添加不同的后缀,对您自己的 CA 证书执行相同的操作。通过使用不同的密钥来生成新的 CA 证书,您可以保留 Secret 中存储的当前 CA 证书。

先决条件

流程

  1. 暂停 Kafka 自定义资源的协调。

    1. 在 OpenShift 中注解自定义资源,将 pause-recon ation 注解设置为 true

      oc annotate Kafka <name_of_custom_resource> strimzi.io/pause-reconciliation="true"

      例如,对于名为 my-clusterKafka 自定义资源:

      oc annotate Kafka my-cluster strimzi.io/pause-reconciliation="true"
    2. 检查自定义资源的状态条件是否显示 Reconliation Paused 的更改:

      oc describe Kafka <name_of_custom_resource>

      类型 条件会改变在 lastTransitionTime 中用于 ReconliationPaused

  2. 更新 CA 证书的 Secret

    1. 编辑现有的 secret 以添加新 CA 证书并更新证书生成注解值。

      oc edit secret <ca_certificate_secret_name>

      <ca_certificate_secret_name > 是 Secret 的名称,它是 KAFKA-CLUSTER-NAME-cluster-ca-cert,用于集群 CA 证书和 KAFKA-CLUSTER-NAME-clients-ca-cert

      以下示例显示了与名为 my-cluster 的 Kafka 集群关联的集群 CA 证书的 secret。

      集群 CA 证书的 secret 配置示例

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

      1
      当前 base64 编码的 CA 证书
      2
      当前 CA 证书生成注解值
    2. 重命名当前 CA 证书以保留它。

      data 下的 ca.crt 属性重命名为 ca- <date&gt; .crt,其中 & lt;date > 是证书过期日期,格式为 YEAR-MONTH-DAYTHOUR-MINUTE-SECONDZ。例如,ca-2022-01-26T17-32-00Z.crt:保留 属性的值,因为它要保留当前的 CA 证书。

    3. 将新 CA 证书编码为 base64。

      cat <path_to_new_certificate> | base64
    4. 更新 CA 证书。

      data 下创建一个新的 ca.crt 属性,并将上一步中的 base64 编码的 CA 证书复制为 ca.crt 属性的值。

    5. 增加 CA 证书生成注解的值。

      使用更高的增量值更新 strimzi.io/ca-cert-generation 注解。例如,将 strimzi.io/ca-cert-generation=0 更改为 strimzi.io/ca-cert-generation=1。如果 Secret 缺少注解,则值将被视为 0, 因此添加带有值 1 的注解。

      当 AMQ Streams 生成证书时,Cluster Operator 会自动递增证书生成注解。要手动续订您自己的 CA 证书,请使用更高的增量值设置注解。该注解需要高于当前 secret 中的值,以便 Cluster Operator 可以部署 Pod 并更新证书。strimzi.io/ca-cert-generation 必须在每次 CA 证书续订时递增。

    6. 使用新的 CA 证书和证书生成注解值保存 secret。

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

      apiVersion: v1
      kind: Secret
      data:
        ca.crt: GCa6LS3RTHeKFiFDGBOUDYFAZ0F... 1
        ca-2022-01-26T17-32-00Z.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0F... 2
      metadata:
        annotations:
          strimzi.io/ca-cert-generation: "1" 3
        labels:
          strimzi.io/cluster: my-cluster
          strimzi.io/kind: Kafka
        name: my-cluster-cluster-ca-cert
        #...
      type: Opaque

      1
      新的 base64 编码的 CA 证书
      2
      旧的 base64 编码的 CA 证书
      3
      新的 CA 证书生成注解值
  3. 更新用于为新 CA 证书签名的 CA 密钥的 Secret

    1. 编辑现有 secret 以添加新 CA 密钥并更新密钥生成注解值。

      oc edit secret <ca_key_name>

      <ca_key_name > 是 CA 键的名称,它是集群 CA 键的 < kafka_cluster_name> -cluster-ca,客户端 CA 键的 < kafka_cluster_name> -clients-ca

      以下示例显示了与名为 my-cluster 的 Kafka 集群关联的集群 CA 密钥的 secret。

      集群 CA 密钥的 secret 配置示例

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

      1
      当前 base64 编码的 CA 密钥
      2
      当前 CA 密钥生成注解值
    2. 将 CA 密钥编码为 base64。

      cat <path_to_new_key> | base64
    3. 更新 CA 密钥。

      将上一步中的 base64 编码的 CA 密钥复制为 data 下的 ca.key 属性的值。

    4. 增加 CA 密钥生成注解的值。

      使用更高的增量值更新 strimzi.io/ca-key-generation 注解。例如,将 strimzi.io/ca-key-generation=0 更改为 strimzi.io/ca-key-generation=1。如果 Secret 缺少注解,它将被视为 0, 因此添加带有值 1 的注解。

      当 AMQ Streams 生成证书时,Cluster Operator 会自动递增密钥生成注解。要手动将自己的 CA 证书与新的 CA 密钥续订,请使用更高的增量值设置注解。该注解需要高于当前 secret 中的值,以便 Cluster Operator 可以部署 Pod 并更新证书和密钥。strimzi.io/ca-key-generation 必须在每次 CA 证书续订时递增。

  4. 使用新的 CA 密钥和密钥生成注解值保存 secret。

    使用新的 CA 密钥更新 secret 配置示例

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

    1
    新的 base64 编码的 CA 密钥
    2
    新的 CA 密钥生成注解值
  5. 从暂停中恢复。

    要恢复 Kafka 自定义资源协调,请将 pause-reconation 注解设置为 false

    oc annotate --overwrite Kafka <name_of_custom_resource> strimzi.io/pause-reconciliation="false"

    您还可以通过删除 pause-reconciliation 注解来执行此操作。

    oc annotate Kafka <name_of_custom_resource> strimzi.io/pause-reconciliation-

在下一协调中,Cluster Operator 执行 ZooKeeper、Kafka 和其他组件的滚动更新,以信任新的 CA 证书。滚动更新完成后,Cluster Operator 将启动一个新服务器证书,以生成由新 CA 密钥签名的新服务器证书。

如果配置了维护时间窗口,Cluster Operator 会在下一次维护时间窗口中第一次协调时部署 pod。

10.4. TLS 连接

10.4.1. zookeeper 通信

所有端口上的 ZooKeeper 节点之间的通信以及客户端与 ZooKeeper 使用 TLS 加密。

Kafka 代理和 ZooKeeper 节点之间的通信也被加密。

10.4.2. Kafka 间代理通信

Kafka 代理之间的通信总是使用 TLS 加密。

除非启用了 ControlPlaneListener 功能门,否则所有 inter-broker 通讯都通过端口 9091 上的内部监听程序。如果您启用功能门,则来自 control plane 的流量会通过端口 9090 上的内部 control plane 侦听。来自 data plane 的流量会继续在端口 9091 上使用现有的内部监听程序。

这些内部监听程序不适用于 Kafka 客户端。

10.4.3. 主题和用户 Operator

所有 Operator 使用加密来与 Kafka 和 ZooKeeper 通信。在主题和用户 Operator 中,在与 ZooKeeper 通信时使用 TLS sidecar。

10.4.4. Sything Control

Cruise Control 使用加密来与 Kafka 和 ZooKeeper 进行通信。与 ZooKeeper 通信时使用 TLS sidecar。

10.4.5. Kafka 客户端连接

Kafka 代理和客户端之间的加密或未加密的通信使用 spec.kafka.listenerstls 属性进行配置。

10.5. 配置内部客户端以信任集群 CA

此流程描述了如何配置位于 OpenShift 集群内部的 Kafka 客户端 - 连接到 TLS 侦听器 - 以信任集群 CA 证书。

为内部客户端达到此目的的最简单方法是使用卷挂载访问包含所需 证书和密钥 的 Secret。

按照以下步骤为基于 Java 的 Kafka Producer、消费者和流 API 配置集群 CA 签名的信任证书。

根据集群 CA 的证书格式选择以下步骤: PKCS #12 (.p12)或 PEM (.crt)。

步骤描述了如何挂载 Cluster Secret,将 Kafka 集群的身份验证到客户端 pod。

先决条件

  • Cluster Operator 必须正在运行。
  • 需要在 OpenShift 集群中有一个 Kafka 资源。
  • 您需要在 OpenShift 集群上使用 TLS 连接的 Kafka 客户端应用程序,并需要信任集群 CA 证书。
  • 客户端应用程序必须与 Kafka 资源在同一命名空间中运行。

使用 PKCS #12 格式(.p12)

  1. 在定义客户端 pod 时,将集群 Secret 挂载为卷。

    例如:

    kind: Pod
    apiVersion: v1
    metadata:
      name: client-pod
    spec:
      containers:
      - name: client-name
        image: client-name
        volumeMounts:
        - name: secret-volume
          mountPath: /data/p12
        env:
        - name: SECRET_PASSWORD
          valueFrom:
            secretKeyRef:
              name: my-secret
              key: my-password
      volumes:
      - name: secret-volume
        secret:
          secretName: my-cluster-cluster-ca-cert

    我们在这里挂载:

    • PKCS #12 文件为准确路径,可以配置
    • 在环境变量中,密码可用于 Java 配置
  2. 使用以下属性配置 Kafka 客户端:

    • 安全协议选项:

      • security.protocol:在使用 TLS 加密时(使用或没有 TLS 身份验证)时的 SSL
      • security.protocol: SASL_SSL 在通过 TLS 使用 SCRAM-SHA 验证时。
    • SSL.truststore.location,使用导入证书的 truststore 位置。
    • SSL.truststore.password,密码为,用于访问信任存储。
    • SSL.truststore.type=PKCS12 来识别信任存储类型。

使用 PEM 格式(.crt)

  1. 在定义客户端 pod 时,将集群 Secret 挂载为卷。

    例如:

    kind: Pod
    apiVersion: v1
    metadata:
      name: client-pod
    spec:
      containers:
      - name: client-name
        image: client-name
        volumeMounts:
        - name: secret-volume
          mountPath: /data/crt
      volumes:
      - name: secret-volume
        secret:
          secretName: my-cluster-cluster-ca-cert
  2. 将证书与使用 X.509 格式的证书的客户端一起使用。

10.6. 配置外部客户端以信任集群 CA

此流程描述了如何配置位于 OpenShift 集群外的 Kafka 客户端 - 连接到外部 监听程序 - 以信任集群 CA 证书。当旧的客户端 CA 证书被替换时,在设置客户端和续订期间,请按照以下步骤操作。

按照以下步骤为基于 Java 的 Kafka Producer、消费者和流 API 配置集群 CA 签名的信任证书。

根据集群 CA 的证书格式选择以下步骤: PKCS #12 (.p12)或 PEM (.crt)。

步骤描述了如何从 Cluster Secret 获取证书,以验证 Kafka 集群的身份。

重要

在 CA 证书续订期间,<cluster-name> -cluster-ca-cert Secret 将包含多个 CA 证书。客户端必须 将它们添加到 其信任存储中。

先决条件

  • Cluster Operator 必须正在运行。
  • 需要在 OpenShift 集群中有一个 Kafka 资源。
  • 您需要在 OpenShift 集群外使用 TLS 连接的 Kafka 客户端应用程序,并需要信任集群 CA 证书。

使用 PKCS #12 格式(.p12)

  1. 从 Kafka 集群的 CLUSTER-NAME-cluster-ca-cert Secret 中提取集群 CA 证书和密码。

    oc get secret CLUSTER-NAME-cluster-ca-cert -o jsonpath='{.data.ca\.p12}' | base64 -d > ca.p12
    oc get secret CLUSTER-NAME-cluster-ca-cert -o jsonpath='{.data.ca\.password}' | base64 -d > ca.password

    CLUSTER-NAME 替换为 Kafka 集群的名称。

  2. 使用以下属性配置 Kafka 客户端:

    • 安全协议选项:

      • security.protocol:在使用 TLS 加密时(使用或没有 TLS 身份验证)时的 SSL
      • security.protocol: SASL_SSL 在通过 TLS 使用 SCRAM-SHA 验证时。
    • SSL.truststore.location,使用导入证书的 truststore 位置。
    • SSL.truststore.password,密码为,用于访问信任存储。如果 truststore 不需要,可以省略此属性。
    • SSL.truststore.type=PKCS12 来识别信任存储类型。

使用 PEM 格式(.crt)

  1. 从 Kafka 集群的 CLUSTER-NAME-cluster-ca-cert Secret 中提取集群 CA 证书。

    oc get secret CLUSTER-NAME-cluster-ca-cert -o jsonpath='{.data.ca\.crt}' | base64 -d > ca.crt
  2. 将证书与使用 X.509 格式的证书的客户端一起使用。

10.7. Kafka 侦听器证书

您可以为启用 TLS 加密的任何监听程序提供自己的服务器证书和私钥。这些用户提供的证书称为 Kafka 侦听器证书

提供 Kafka 侦听器证书允许您利用现有的安全基础架构,如您组织的私有 CA 或公共 CA。Kafka 客户端需要信任用于为监听程序证书签名的 CA。

在需要时,您必须手动续订 Kafka 侦听器证书。

10.7.1. 提供您自己的 Kafka 侦听器证书

此流程演示了如何将侦听器配置为使用您自己的私钥和服务器证书,称为 Kafka 侦听器证书

您的客户端应用程序应使用 CA 公钥作为可信证书,以验证 Kafka 代理的身份。

先决条件

  • OpenShift 集群。
  • Cluster Operator 正在运行。
  • 对于每个监听程序,由外部 CA 签名的兼容服务器证书。

流程

  1. 创建包含私钥和服务器证书的 Secret

    oc create secret generic my-secret --from-file=my-listener-key.key --from-file=my-listener-certificate.crt
  2. 编辑集群的 Kafka 资源。配置侦听器,以在 configuration.brokerCertChainAndKey 属性中使用 Secret、证书文件和私钥文件。

    启用 TLS 加密的 负载均衡器外部监听程序配置示例

    # ...
    listeners:
      - name: plain
        port: 9092
        type: internal
        tls: false
      - name: external
        port: 9094
        type: loadbalancer
        tls: true
        authentication:
          type: tls
        configuration:
          brokerCertChainAndKey:
            secretName: my-secret
            certificate: my-listener-certificate.crt
            key: my-listener-key.key
    # ...

    TLS 侦听器配置示例

    # ...
    listeners:
      - name: plain
        port: 9092
        type: internal
        tls: false
      - name: tls
        port: 9093
        type: internal
        tls: true
        authentication:
          type: tls
        configuration:
          brokerCertChainAndKey:
            secretName: my-secret
            certificate: my-listener-certificate.crt
            key: my-listener-key.key
    # ...

  3. 应用新配置以创建或更新资源:

    oc apply -f kafka.yaml

    Cluster Operator 启动 Kafka 集群的滚动更新,这会更新监听程序的配置。

    注意

    如果您在已由 TLS 或外部监听程序使用的 Secret 中更新 Kafka 侦听器证书,也会启动滚动更新。

10.7.2. Kafka 监听器的服务器证书中的替代主题

要将 TLS 主机名验证用于您自己的 Kafka 侦听器证书,您必须为每个监听器使用正确的主题备用名称(SAN)。证书 SAN 必须为以下项指定主机名:

  • 集群中的所有 Kafka 代理
  • Kafka 集群 bootstrap 服务

如果 CA 支持通配符证书,您可以使用通配符证书。

10.7.2.1. TLS 侦听器 SAN 示例

使用以下示例,帮助您为 TLS 监听器在证书中指定 SAN 的主机名。

通配符示例

//Kafka brokers
*.<cluster-name>-kafka-brokers
*.<cluster-name>-kafka-brokers.<namespace>.svc

// Bootstrap service
<cluster-name>-kafka-bootstrap
<cluster-name>-kafka-bootstrap.<namespace>.svc

非通配符示例

// Kafka brokers
<cluster-name>-kafka-0.<cluster-name>-kafka-brokers
<cluster-name>-kafka-0.<cluster-name>-kafka-brokers.<namespace>.svc
<cluster-name>-kafka-1.<cluster-name>-kafka-brokers
<cluster-name>-kafka-1.<cluster-name>-kafka-brokers.<namespace>.svc
# ...

// Bootstrap service
<cluster-name>-kafka-bootstrap
<cluster-name>-kafka-bootstrap.<namespace>.svc

10.7.2.2. 外部监听程序 SAN 示例

对于启用了 TLS 加密的外部监听程序,您需要在证书中指定的主机名取决于外部监听程序 类型

表 10.15. 每种类型的外部监听程序的 SAN
外部监听程序类型在 SANs 中,指定…​

Route(路由)

所有 Kafka 代理 路由和 bootstrap 路由 地址。

您可以使用匹配的通配符名称。

loadbalancer

所有 Kafka 代理 负载均衡器和 bootstrap 负载均衡器地址 的地址

您可以使用匹配的通配符名称。

NodePort

Kafka 代理 Pod 可能调度到的所有 OpenShift worker 节点的地址。

您可以使用匹配的通配符名称。

第 11 章 管理 AMQ Streams

本章论述了维护 AMQ Streams 部署的任务。

11.1. 使用自定义资源

您可以使用 oc 命令检索信息,并在 AMQ Streams 自定义资源上执行其他操作。

使用带有自定义资源 status 子资源的 oc,您可以获取有关资源的信息。

11.1.1. 在自定义资源上执行 oc 操作

使用 oc 命令,如 get, describe, edit, 或 delete, 对资源类型执行操作。例如,oc get kafkatopics 检索所有 Kafka 主题和 oc get kafkas 列表,检索所有部署的 Kafka 集群。

引用资源类型时,您可以使用单数和复数名称: oc get kafkas 获取与 oc get kafka 相同的结果。

您还可以使用资源 的短名称。学习短名称可在管理 AMQ Streams 时节省时间。Kafka 的短名称为 k,因此也可以运行 oc get k 来列出所有 Kafka 集群。

oc get k

NAME         DESIRED KAFKA REPLICAS   DESIRED ZK REPLICAS
my-cluster   3                        3
表 11.1. 每个 AMQ Streams 资源的长和短名称
AMQ Streams 资源长名称短名称

Kafka

kafka

k

Kafka 主题

kafkatopic

kt

Kafka 用户

kafkauser

ku

Kafka Connect

kafkaconnect

kc

Kafka Connector

kafkaconnector

kctr

Kafka Mirror Maker

kafkamirrormaker

kmm

Kafka Mirror Maker 2

kafkamirrormaker2

kmm2

Kafka Bridge

kafkabridge

kb

Kafka Rebalance

kafkarebalance

kr

11.1.1.1. 资源类型( resource category)

自定义资源的类别也可以在 oc 命令中使用。

所有 AMQ Streams 自定义资源都属于类别 strimzi,因此您可以使用 strimzi 获取所有 AMQ Streams 资源。

例如,运行 oc get strimzi 列出了给定命名空间中的所有 AMQ Streams 自定义资源。

oc get strimzi

NAME                                   DESIRED KAFKA REPLICAS DESIRED ZK REPLICAS
kafka.kafka.strimzi.io/my-cluster      3                      3

NAME                                   PARTITIONS REPLICATION FACTOR
kafkatopic.kafka.strimzi.io/kafka-apps 3          3

NAME                                   AUTHENTICATION AUTHORIZATION
kafkauser.kafka.strimzi.io/my-user     tls            simple

oc get strimzi -o name 命令返回所有资源类型和资源名称。-o name 选项以 type/name 格式获取输出

oc get strimzi -o name

kafka.kafka.strimzi.io/my-cluster
kafkatopic.kafka.strimzi.io/kafka-apps
kafkauser.kafka.strimzi.io/my-user

您可以将这一 strimzi 命令与其他命令组合。例如,您可以将它传递到 oc delete 命令,以删除单个命令中的所有资源。

oc delete $(oc get strimzi -o name)

kafka.kafka.strimzi.io "my-cluster" deleted
kafkatopic.kafka.strimzi.io "kafka-apps" deleted
kafkauser.kafka.strimzi.io "my-user" deleted

在单个操作中删除所有资源可能很有用,例如,当您测试了新的 AMQ Streams 功能时。

11.1.1.2. 查询子资源的状态

还有其他值,您可以传递给 -o 选项。例如,通过使用 -o yaml 以 YAML 格式获取输出。使用 -o json 将其返回为 JSON。

您可以在 oc get --help 中看到所有选项。

其中一个最有用的选项是 JSONPath 支持,它允许您传递 JSONPath 表达式来查询 Kubernetes API。JSONPath 表达式可以提取或导航任何资源的特定部分。

例如,您可以使用 JSONPath 表达式 {.status.listeners[? (@.name=="tls")].bootstrapServers} 从 Kafka 自定义资源的状态获取 bootstrap 地址,并在 Kafka 客户端中使用它。

在这里,该命令会找到名为 tls 的监听程序的 bootstrapServers 值:

oc get kafka my-cluster -o=jsonpath='{.status.listeners[?(@.name=="tls")].bootstrapServers}{"\n"}'

my-cluster-kafka-bootstrap.myproject.svc:9093

通过更改名称条件,您也可以获取其他 Kafka 监听器的地址。

您可以使用 jsonpath 从任何自定义资源中提取任何其他属性或属性组。

11.1.2. AMQ Streams 自定义资源状态信息

几个资源具有一个 status 属性,如下表中所述。

表 11.2. 自定义资源状态属性
AMQ Streams 资源架构参考发布状态信息 on…​

Kafka

第 12.2.55 节 “KafkaStatus 模式参考”

Kafka 集群。

KafkaConnect

第 12.2.85 节 “KafkaConnectStatus schema 参考”

Kafka Connect 集群(如果部署)。

KafkaConnector

第 12.2.123 节 “KafkaConnectorStatus schema 参考”

KafkaConnector 资源(如果部署)。

KafkaMirrorMaker

第 12.2.111 节 “KafkaMirrorMakerStatus 模式参考”

Kafka MirrorMaker 工具(如果部署)。

KafkaTopic

第 12.2.89 节 “KafkaTopicStatus 模式参考”

Kafka 集群中的 Kafka 主题。

KafkaUser

第 12.2.105 节 “KafkaUserStatus schema 参考”

Kafka 集群中的 Kafka 用户。

KafkaBridge

第 12.2.120 节 “KafkaBridgeStatus schema reference”

AMQ Streams Kafka Bridge (如果部署)。

资源的 status 属性提供资源的信息:

  • 当前状态,在 status.conditions 属性中
  • 最后观察到的生成,在 status.observedGeneration 属性中

status 属性还提供特定于资源的信息。例如:

  • KafkaStatus 提供有关监听程序地址的信息,以及 Kafka 集群的 id。
  • KafkaConnectStatus 为 Kafka Connect 连接器提供 REST API 端点。
  • KafkaUserStatus 提供 Kafka 用户的用户名,以及存储其凭证的 Secret
  • KafkaBridgeStatus 提供 HTTP 地址,外部客户端应用程序可以访问 Bridge 服务。

资源的当前状态可用于跟踪与资源相关的进度,达到其所需状态,如 spec 属性所定义。状态条件提供资源更改和事件详细信息以及防止或延迟 Operator 实现资源所需状态的时间和原因。

最后观察到的生成 是 Cluster Operator 最后协调的资源的生成。如果 observedGeneration 的值与 metadata.generation 的值不同,Operator 还没有处理对该资源的最新更新。如果这些值相同,状态信息会显示对资源的最新更改。

AMQ Streams 创建并维护自定义资源的状态,定期评估自定义资源的当前状态并相应地更新其状态。当使用 oc edit 在自定义资源上执行更新时,则 其状态 不可编辑。此外,更改 状态 不会影响 Kafka 集群的配置。

此处我们看到为 Kafka 自定义资源指定的 status 属性。

带有状态的 Kafka 自定义资源

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
spec:
  # ...
status:
  conditions: 1
  - lastTransitionTime: 2021-07-23T23:46:57+0000
    status: "True"
    type: Ready 2
  observedGeneration: 4 3
  listeners: 4
  - addresses:
    - host: my-cluster-kafka-bootstrap.myproject.svc
      port: 9092
    type: plain
  - addresses:
    - host: my-cluster-kafka-bootstrap.myproject.svc
      port: 9093
    certificates:
    - |
      -----BEGIN CERTIFICATE-----
      ...
      -----END CERTIFICATE-----
    type: tls
  - addresses:
    - host: 172.29.49.180
      port: 9094
    certificates:
    - |
      -----BEGIN CERTIFICATE-----
      ...
      -----END CERTIFICATE-----
    type: external
  clusterId: CLUSTER-ID 5
# ...

1
状态条件 描述与从现有资源信息中无法推断的状态相关的标准,或者特定于资源实例。
2
Ready 条件指示 Cluster Operator 当前是否认为 Kafka 集群可以处理流量。
3
observedGeneration 表示由 Cluster Operator 最后协调的 Kafka 自定义资源的生成。
4
侦听器 根据类型描述当前的 Kafka bootstrap 地址。
5
Kafka 集群 ID。
重要

目前还不支持带有 nodeport 的外部监听程序的自定义资源状态中的地址。

注意

状态中列出的 Kafka bootstrap 地址不表示这些端点或 Kafka 集群处于就绪状态。

访问状态信息

您可以从命令行访问资源的状态信息。更多信息请参阅 第 11.1.3 节 “查找自定义资源的状态”

11.1.3. 查找自定义资源的状态

这个步骤描述了如何查找自定义资源的状态。

先决条件

  • OpenShift 集群。
  • Cluster Operator 正在运行。

流程

  • 指定自定义资源,并使用 -o jsonpath 选项应用标准 JSONPath 表达式来选择 status 属性:

    oc get kafka <kafka_resource_name> -o jsonpath='{.status}'

    此表达式返回指定自定义资源的所有状态信息。您可以使用点表示法(如 status.listenersstatus.observedGeneration )来微调您要查看的状态信息。

其他资源

11.2. 暂停对自定义资源的协调

有时,暂停由 AMQ Streams Operator 管理的自定义资源协调很有用,以便您可以执行修复或进行更新。如果协调暂停,Operator 将忽略对自定义资源所做的任何更改,直到暂停结束为止。

如果要暂停自定义资源的协调,请在其配置中将 strimzi.io/pause- reconation 注解设置为 true。这会指示适当的 Operator 暂停自定义资源协调。例如,您可以将注解应用到 KafkaConnect 资源,以便 Cluster Operator 协调暂停。

您还可以创建启用 pause 注解的自定义资源。创建自定义资源,但会忽略它。

先决条件

  • 管理自定义资源的 AMQ Streams Operator 正在运行。

流程

  1. 在 OpenShift 中注解自定义资源,将 pause-reconation 设置为 true

    oc annotate <kind_of_custom_resource> <name_of_custom_resource> strimzi.io/pause-reconciliation="true"

    例如,对于 KafkaConnect 自定义资源:

    oc annotate KafkaConnect my-connect strimzi.io/pause-reconciliation="true"
  2. 检查自定义资源的状态条件是否显示 Reconliation Paused 的更改:

    oc describe <kind_of_custom_resource> <name_of_custom_resource>

    类型 条件会改变在 lastTransitionTime 中用于 ReconliationPaused

    带有暂停协调条件类型的自定义资源示例

    apiVersion: kafka.strimzi.io/v1beta2
    kind: KafkaConnect
    metadata:
      annotations:
        strimzi.io/pause-reconciliation: "true"
        strimzi.io/use-connector-resources: "true"
      creationTimestamp: 2021-03-12T10:47:11Z
      #...
    spec:
      # ...
    status:
      conditions:
      - lastTransitionTime: 2021-03-12T10:47:41.689249Z
        status: "True"
        type: ReconciliationPaused

恢复暂停

  • 要恢复协调,您可以将注解设置为 false,或删除注解。

11.3. 使用 AMQ Streams Drain Cleaner 驱除 pod

Kafka 和 ZooKeeper pod 可能会在 OpenShift 升级、维护和 pod 重新调度过程中被驱除。如果您的 Kafka 代理和 ZooKeeper pod 由 AMQ Streams 部署,您可以使用 AMQ Streams Drain Cleaner 工具来处理 pod 驱除。由于 AMQ Streams Drain Cleaner 将处理驱除而不是 OpenShift,所以您需要将 Kafka 部署的 podDisruptionBudget 设置为 0 ( 零)。然后,OpenShift 将不再允许自动驱除 pod。

通过部署 AMQ Streams Drain Cleaner,您可以使用 Cluster Operator 移动 Kafka pod 而不是 OpenShift。Cluster Operator 确保主题永远不会被复制。Kafka 可在驱除过程中保持运行。Cluster Operator 会等待主题同步,因为 OpenShift worker 节点会持续排空。

准入 Webhook 通知 AMQ Streams Drain Cleaner 到 Kubernetes API 的 pod 驱除请求。然后,AMQ Streams Drain Cleaner 会向 pod 添加滚动更新注解,以便排空 pod。这会通知 Cluster Operator 执行被驱除的 pod 的滚动更新。

注意

如果不使用 AMQ Streams Drain Cleaner,您可以添加 pod 注解来手动执行滚动更新

Webhook 配置

AMQ Streams Drain Cleaner 部署文件包含一个 ValidatingWebhookConfiguration 资源文件。资源提供了将 webhook 注册到 Kubernetes API 的配置。

配置定义了 Kubernetes API 在发生 pod 驱除请求时遵循 的规则。规则指定,只有与 pod/eviction 子资源 相关的 CREATE 操作才会被拦截。如果满足这些规则,API 会转发通知。

clientConfig 指向 AMQ Streams Drain Cleaner 服务,以及公开 webhook 的 /drainer 端点。Webhook 使用安全 TLS 连接,需要身份验证。caBundle 属性指定验证 HTTPS 通信的证书链。证书以 Base64 编码。

pod 驱除通知的 Webhook 配置

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
# ...
webhooks:
  - name: strimzi-drain-cleaner.strimzi.io
    rules:
      - apiGroups:   [""]
        apiVersions: ["v1"]
        operations:  ["CREATE"]
        resources:   ["pods/eviction"]
        scope:       "Namespaced"
    clientConfig:
      service:
        namespace: "strimzi-drain-cleaner"
        name: "strimzi-drain-cleaner"
        path: /drainer
        port: 443
        caBundle: Cg==
    # ...

11.3.1. 先决条件

要部署和使用 AMQ Streams Drain Cleaner,您需要下载部署文件。

AMQ Streams Drain Cleaner 部署文件可从 AMQ Streams 软件下载页面

11.3.2. 部署 AMQ Streams Drain Cleaner

将 AMQ Streams Drain Cleaner 部署到运行 Cluster Operator 和 Kafka 集群的 OpenShift 集群。

先决条件

  • 您已 下载 AMQ Streams Drain Cleaner 部署文件
  • 您有一个高度可用的 Kafka 集群部署,它运行了您要更新的 OpenShift worker 节点。
  • 我们将复制主题以实现高可用性。

    主题配置指定至少 3 个复制因素,最小同步副本的数量为复制因素的数量减 1。

    Kafka 主题复制以实现高可用性

    apiVersion: kafka.strimzi.io/v1beta2
    kind: KafkaTopic
    metadata:
      name: my-topic
      labels:
        strimzi.io/cluster: my-cluster
    spec:
      partitions: 1
      replicas: 3
      config:
        # ...
        min.insync.replicas: 2
        # ...

排除 ZooKeeper

如果您不想包含 ZooKeeper,您可以从 AMQ Streams Drain Cleaner Deployment 配置文件中删除 --zookeeper 命令选项。

apiVersion: apps/v1
kind: Deployment
spec:
  # ...
  template:
    spec:
      serviceAccountName: strimzi-drain-cleaner
      containers:
        - name: strimzi-drain-cleaner
          # ...
          command:
            - "/application"
            - "-Dquarkus.http.host=0.0.0.0"
            - "--kafka"
            - "--zookeeper" 1
          # ...
1
删除这个选项,以从 AMQ Streams Drain Cleaner 操作中排除 ZooKeeper。

流程

  1. 使用 Kafka 资源中的 模板 设置,为您的 Kafka 部署配置 pod 中断预算 0 ( 零)。

    指定 pod 中断预算

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    metadata:
      name: my-cluster
      namespace: myproject
    spec:
      kafka:
        template:
          podDisruptionBudget:
            maxUnavailable: 0
    
      # ...
      zookeeper:
        template:
          podDisruptionBudget:
            maxUnavailable: 0
      # ...

    将最大 pod 中断预算缩减为零可防止 OpenShift 在出现自愿中断时自动驱除 pod,从而使 AMQ Streams Drain Cleaner 和 AMQ Streams Cluster Operator 保留为 AMQ Streams Cluster Operator,以在不同的 worker 节点上部署 OpenShift 将调度的 pod。

    如果要使用 AMQ Streams Drain Cleaner 来排空 ZooKeeper 节点,为 ZooKeeper 添加相同的配置。

  2. 更新 Kafka 资源:

    oc apply -f <kafka_configuration_file>
  3. 部署 AMQ Streams Drain Cleaner。

    oc apply -f ./install/drain-cleaner/openshift

11.3.3. 使用 AMQ Streams Drain Cleaner

使用 AMQ Streams Drain Cleaner 与 Cluster Operator 结合使用,将 Kafka 代理或 ZooKeeper pod 从正在排空的节点移动。运行 AMQ Streams Drain Cleaner 时,它会使用滚动更新 pod 注解来注解 pod。Cluster Operator 根据注解执行滚动更新。

流程

  1. 排空托管 Kafka 代理或 ZooKeeper pod 的指定 OpenShift 节点。

    oc get nodes
    oc drain <name-of-node> --delete-emptydir-data --ignore-daemonsets --timeout=6000s --force
  2. 检查 AMQ Streams Drain Cleaner 日志中的驱除事件,以验证 pod 是否已注解重启。

    AMQ Streams Drain Cleaner 日志显示 pod 的注解

    INFO ... Received eviction webhook for Pod my-cluster-zookeeper-2 in namespace my-project
    INFO ... Pod my-cluster-zookeeper-2 in namespace my-project will be annotated for restart
    INFO ... Pod my-cluster-zookeeper-2 in namespace my-project found and annotated for restart
    
    INFO ... Received eviction webhook for Pod my-cluster-kafka-0 in namespace my-project
    INFO ... Pod my-cluster-kafka-0 in namespace my-project will be annotated for restart
    INFO ... Pod my-cluster-kafka-0 in namespace my-project found and annotated for restart

  3. 检查 Cluster Operator 日志中的协调事件,以验证滚动更新。

    Cluster Operator 日志显示滚动更新

    INFO  PodOperator:68 - Reconciliation #13(timer) Kafka(my-project/my-cluster): Rolling Pod my-cluster-zookeeper-2
    INFO  PodOperator:68 - Reconciliation #13(timer) Kafka(my-project/my-cluster): Rolling Pod my-cluster-kafka-0
    INFO  AbstractOperator:500 - Reconciliation #13(timer) Kafka(my-project/my-cluster): reconciled

11.4. 手动启动 Kafka 和 ZooKeeper 集群的滚动更新

AMQ Streams 支持在资源中使用注解,通过 Cluster Operator 手动触发 Kafka 和 ZooKeeper 集群的滚动更新。滚动更新使用新资源的 pod。

通常只在特殊情况下需要手动对特定 pod 或一组 pod 执行滚动更新。但是,如果通过 Cluster Operator 执行滚动更新,而不是直接删除 pod,而是要删除以下内容:

  • 手动删除 pod 不会与 Cluster Operator 操作冲突,如同时删除其他 pod。
  • Cluster Operator 逻辑处理 Kafka 配置规格,如 in-sync 副本数。

11.4.1. 先决条件

要执行手动滚动更新,您需要一个正在运行的 Cluster Operator 和 Kafka 集群。

有关运行的信息 ,请参阅 OpenShift 中的部署和升级 AMQ Streams 指南:

11.4.2. 使用 pod 管理注解执行滚动更新

这个步骤描述了如何触发 Kafka 集群的滚动更新或 ZooKeeper 集群。

要触发更新,您可以在用来管理集群中运行的 pod 的资源中添加注解。您注解 StatefulSetStrimziPodSet 资源(如果您启用了 UseStrimziPodSets 功能门)。

流程

  1. 查找控制您要手动更新的 Kafka 或 ZooKeeper pod 的资源名称。

    例如,如果您的 Kafka 集群名为 my-cluster,则对应的名称为 my-cluster-kafkamy-cluster-zookeeper

  2. 使用 oc annotate 来注解 OpenShift 中的相应资源。

    注解 StatefulSet

    oc annotate statefulset <cluster_name>-kafka strimzi.io/manual-rolling-update=true
    
    oc annotate statefulset <cluster_name>-zookeeper strimzi.io/manual-rolling-update=true

    注解 StrimziPodSet

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

  3. 等待下一次协调发生(默认为两分钟)。只要协调过程检测到注解,就会触发对注解中所有 pod 的滚动更新。当完成所有 Pod 的滚动更新时,该注解会从资源中移除。

11.4.3. 使用 Pod 注解执行滚动更新

此流程描述了如何使用 OpenShift Pod 注解手动触发现有 Kafka 集群或 ZooKeeper 集群的滚动更新。当注解多个 pod 时,连续滚动更新会在同一个协调运行内执行。

先决条件

您可以在 Kafka 集群上执行滚动更新,无论所使用的主题复制因素是什么。但是,要让 Kafka 在更新期间保持运行状态,您需要满足以下条件:

  • 使用您要更新的节点运行的高可用性 Kafka 集群部署。
  • 为高可用性而复制的主题.

    主题配置指定至少 3 个复制因素,最小同步副本的数量为复制因素的数量减 1。

    Kafka 主题复制以实现高可用性

    apiVersion: kafka.strimzi.io/v1beta2
    kind: KafkaTopic
    metadata:
      name: my-topic
      labels:
        strimzi.io/cluster: my-cluster
    spec:
      partitions: 1
      replicas: 3
      config:
        # ...
        min.insync.replicas: 2
        # ...

流程

  1. 查找您要手动更新的 Kafka 或 ZooKeeper Pod 的名称。

    例如,如果您的 Kafka 集群名为 my-cluster,则对应的 Pod 名称是 my-cluster-kafka-indexmy-cluster-zookeeper-index索引 从零开始,结尾为副本数减一。

  2. 注解 OpenShift 中的 Pod 资源。

    使用 oc annotate:

    oc annotate pod cluster-name-kafka-index strimzi.io/manual-rolling-update=true
    
    oc annotate pod cluster-name-zookeeper-index strimzi.io/manual-rolling-update=true
  3. 等待下一次协调发生(默认为两分钟)。当在协调过程检测到注解时,就会触发被注解的 Pod 的滚动更新。完成容器集的滚动更新后,该注解会从 Pod 中删除。

11.5. 使用标签和注解发现服务

通过服务发现,可以更轻松地在与 AMQ Streams 相同的 OpenShift 集群中运行客户端应用程序,以便与 Kafka 集群交互。

为用于访问 Kafka 集群的服务生成 服务发现 标签和注解:

  • 内部 Kafka bootstrap 服务
  • HTTP Bridge 服务

此标签有助于使服务发现,注释提供了客户端应用程序可用于连接的连接详情。

对于 Service 资源,服务发现标签 strimzi.io/discovery 被设置为 true。服务发现注解具有相同的密钥,为每一服务提供 JSON 格式的连接详情。

内部 Kafka bootstrap 服务示例
apiVersion: v1
kind: Service
metadata:
  annotations:
    strimzi.io/discovery: |-
      [ {
        "port" : 9092,
        "tls" : false,
        "protocol" : "kafka",
        "auth" : "scram-sha-512"
      }, {
        "port" : 9093,
        "tls" : true,
        "protocol" : "kafka",
        "auth" : "tls"
      } ]
  labels:
    strimzi.io/cluster: my-cluster
    strimzi.io/discovery: "true"
    strimzi.io/kind: Kafka
    strimzi.io/name: my-cluster-kafka-bootstrap
  name: my-cluster-kafka-bootstrap
spec:
  #...
HTTP Bridge 服务示例
apiVersion: v1
kind: Service
metadata:
  annotations:
    strimzi.io/discovery: |-
      [ {
        "port" : 8080,
        "tls" : false,
        "auth" : "none",
        "protocol" : "http"
      } ]
  labels:
    strimzi.io/cluster: my-bridge
    strimzi.io/discovery: "true"
    strimzi.io/kind: KafkaBridge
    strimzi.io/name: my-bridge-bridge-service

11.5.1. 返回服务的连接详情

您可以在从命令行获取服务时指定发现标签或对应的 API 调用来查找服务。

oc get service -l strimzi.io/discovery=true

检索服务发现标签时,返回连接详情。

11.6. 从持久性卷恢复集群

如果仍存在,您可以从持久性卷(PV)中恢复 Kafka 集群。

您可能希望进行此操作,例如:

  • 命名空间被意外删除
  • 整个 OpenShift 集群都会丢失,但 PV 仍然保留在基础架构中

11.6.1. 从命名空间删除中恢复

有可能从命名空间删除恢复,因为持久性卷和命名空间之间的关系。PersistentVolume (PV)是位于命名空间外的存储资源。PV 使用一个位于命名空间中的 PersistentVolumeClaim (PVC)挂载到 Kafka pod 中。

PV 的重新声明(reclaim)策略指定了在删除命名空间时如何执行操作的集群。如果 reclaim 策略被设置为:

  • 删除 (默认),当在一个命名空间中删除 PVC 时 PV 会被删除
  • Retain,当删除命名空间时 PV 不会删除。

如果确保在命名空间被意外删除时可以从 PV 中进行恢复,需要使用 persistentVolumeReclaimPolicy 属性在 PV 规格中将策略从 Delete 重置为 Retain

apiVersion: v1
kind: PersistentVolume
# ...
spec:
  # ...
  persistentVolumeReclaimPolicy: Retain

另外,PV 可以继承关联的存储类的重新声明策略。存储类用于动态卷分配。

通过为存储类配置 reclaimPolicy 属性,使用存储类的 PV 会使用适当的重新声明策略创建。使用 storageClassName 属性为 PV 配置存储类。

apiVersion: v1
kind: StorageClass
metadata:
  name: gp2-retain
parameters:
  # ...
# ...
reclaimPolicy: Retain
apiVersion: v1
kind: PersistentVolume
# ...
spec:
  # ...
  storageClassName: gp2-retain
注意

如果您使用 Retain 作为 reclaim 策略,但要删除整个集群,则需要手动删除 PV。否则,它们不会被删除,可能会对资源造成不必要的开支。

11.6.2. 恢复丢失 OpenShift 集群

当集群丢失时,如果集群在基础架构中保留,您可以使用磁盘/卷中的数据恢复集群。恢复过程与删除命名空间相同,假设 PV 可以恢复,且被手动创建。

11.6.3. 从持久性卷恢复已删除的集群

这个步骤描述了如何从持久性卷(PV)中恢复删除的集群。

在这种情况下,主题 Operator 会标识 Kafka 中存在的主题,但 KafkaTopic 资源不存在。

当您获得重新创建集群的步骤时,有两个选项:

  1. 当您可以恢复所有 KafkaTopic 资源时,请使用 选项 1

    因此,在集群启动前必须恢复 KafkaTopic 资源,以便 Topic Operator 不会删除对应的主题。

  2. 当无法恢复所有 KafkaTopic 资源时,请使用 选项 2

    在这种情况下,您在没有 Topic Operator 的情况下部署集群,删除 Topic Operator 主题存储元数据,然后使用 Topic Operator 重新部署 Kafka 集群,以便可以从对应的主题重新创建 KafkaTopic 资源。

注意

如果没有部署 Topic Operator,则只需要恢复 PersistentVolumeClaim (PVC)资源。

开始前

在这一流程中,PV 挂载到正确的 PVC 中,以避免数据崩溃。为 PVC 指定一个 volumeName,它必须与 PV 的名称匹配。

如需更多信息,请参阅:

注意

此流程不包括 KafkaUser 资源的恢复,必须手动重新创建。如果需要保留密码和证书,在创建 KafkaUser 资源前必须重新创建 secret。

流程

  1. 检查集群中 PV 的信息:

    oc get pv

    为带有数据的 PV 会显示信息。

    显示对此流程很重要的列示例:

    NAME                                         RECLAIMPOLICY CLAIM
    pvc-5e9c5c7f-3317-11ea-a650-06e1eadd9a4c ... Retain ...    myproject/data-my-cluster-zookeeper-1
    pvc-5e9cc72d-3317-11ea-97b0-0aef8816c7ea ... Retain ...    myproject/data-my-cluster-zookeeper-0
    pvc-5ead43d1-3317-11ea-97b0-0aef8816c7ea ... Retain ...    myproject/data-my-cluster-zookeeper-2
    pvc-7e1f67f9-3317-11ea-a650-06e1eadd9a4c ... Retain ...    myproject/data-0-my-cluster-kafka-0
    pvc-7e21042e-3317-11ea-9786-02deaf9aa87e ... Retain ...    myproject/data-0-my-cluster-kafka-1
    pvc-7e226978-3317-11ea-97b0-0aef8816c7ea ... Retain ...    myproject/data-0-my-cluster-kafka-2
    • NAME 显示每个 PV 的名称。
    • RECLAIM POLICY 显示 PV 被保留
    • CLAIM 显示指向原始 PVC 的链接。
  2. 重新创建原始命名空间:

    oc create namespace myproject
  3. 重新创建原始 PVC 资源规格,将 PVC 链接到适当的 PV:

    例如:

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: data-0-my-cluster-kafka-0
    spec:
      accessModes:
      - ReadWriteOnce
      resources:
        requests:
          storage: 100Gi
      storageClassName: gp2-retain
      volumeMode: Filesystem
      volumeName: pvc-7e1f67f9-3317-11ea-a650-06e1eadd9a4c
  4. 编辑 PV 规格以删除绑定原始 PVC 的 claimRef 属性。

    例如:

    apiVersion: v1
    kind: PersistentVolume
    metadata:
      annotations:
        kubernetes.io/createdby: aws-ebs-dynamic-provisioner
        pv.kubernetes.io/bound-by-controller: "yes"
        pv.kubernetes.io/provisioned-by: kubernetes.io/aws-ebs
      creationTimestamp: "<date>"
      finalizers:
      - kubernetes.io/pv-protection
      labels:
        failure-domain.beta.kubernetes.io/region: eu-west-1
        failure-domain.beta.kubernetes.io/zone: eu-west-1c
      name: pvc-7e226978-3317-11ea-97b0-0aef8816c7ea
      resourceVersion: "39431"
      selfLink: /api/v1/persistentvolumes/pvc-7e226978-3317-11ea-97b0-0aef8816c7ea
      uid: 7efe6b0d-3317-11ea-a650-06e1eadd9a4c
    spec:
      accessModes:
      - ReadWriteOnce
      awsElasticBlockStore:
        fsType: xfs
        volumeID: aws://eu-west-1c/vol-09db3141656d1c258
      capacity:
        storage: 100Gi
      claimRef:
        apiVersion: v1
        kind: PersistentVolumeClaim
        name: data-0-my-cluster-kafka-2
        namespace: myproject
        resourceVersion: "39113"
        uid: 54be1c60-3319-11ea-97b0-0aef8816c7ea
      nodeAffinity:
        required:
          nodeSelectorTerms:
          - matchExpressions:
            - key: failure-domain.beta.kubernetes.io/zone
              operator: In
              values:
              - eu-west-1c
            - key: failure-domain.beta.kubernetes.io/region
              operator: In
              values:
              - eu-west-1
      persistentVolumeReclaimPolicy: Retain
      storageClassName: gp2-retain
      volumeMode: Filesystem

    在示例中,删除了以下属性:

    claimRef:
      apiVersion: v1
      kind: PersistentVolumeClaim
      name: data-0-my-cluster-kafka-2
      namespace: myproject
      resourceVersion: "39113"
      uid: 54be1c60-3319-11ea-97b0-0aef8816c7ea
  5. 部署 Cluster Operator。

    oc create -f install/cluster-operator -n my-project
  6. 重新创建集群。

    根据您是否有足够的 KafkaTopic 资源来重新创建集群,请按照以下步骤操作。

    选项 1: 如果您拥有丢失集群之前存在的 所有 KafkaTopic 资源,包括内部主题,如从 __consumer_offsets 的提交偏移:

    1. 重新创建所有 KafkaTopic 资源。

      在部署集群前重新创建资源非常重要,否则主题 Operator 将删除主题。

    2. 部署 Kafka 集群。

      例如:

      oc apply -f kafka.yaml

    选项 2: 如果您没有丢失集群前存在的所有 KafkaTopic 资源:

    1. 与使用第一个选项一样部署 Kafka 集群,但部署前从 Kafka 资源中删除 topicOperator 属性。

      如果在部署中包含 Topic Operator,主题 Operator 将删除所有主题。

    2. 从 Kafka 集群删除内部主题存储主题:

      oc run kafka-admin -ti --image=registry.redhat.io/amq7/amq-streams-kafka-32-rhel8:2.2.2 --rm=true --restart=Never -- ./bin/kafka-topics.sh --bootstrap-server localhost:9092 --topic __strimzi-topic-operator-kstreams-topic-store-changelog --delete && ./bin/kafka-topics.sh --bootstrap-server localhost:9092 --topic __strimzi_store_topic --delete

      命令必须与用于访问 Kafka 集群的监听程序和身份验证类型对应。

    3. 使用 topicOperator 属性重新部署 Kafka 集群以重新创建 KafkaTopic 资源来启用主题 Operator。

      例如:

      apiVersion: kafka.strimzi.io/v1beta2
      kind: Kafka
      metadata:
        name: my-cluster
      spec:
        #...
        entityOperator:
          topicOperator: {} 1
          #...
    1
    此处我们显示了默认配置,该配置没有额外属性。您可以使用 第 12.2.45 节 “EntityTopicOperatorSpec 模式参考” 中描述的属性指定所需的配置。
  7. 列出 KafkaTopic 资源来验证恢复:

    oc get KafkaTopic

11.7. 使用 Kafka 静态配额插件在代理上设置限制

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

您可以为制作者和消费者带宽设置字节速率阈值。总限值分布在访问代理的所有客户端上。例如,您可以为制作者设置字节的阈值 40 MBps。如果两个制作者正在运行,则它们各自限制为 20 MBps 吞吐量。

存储配额在软限制和硬限制之间节流 Kafka 磁盘存储限制。限制适用于所有可用磁盘空间。生产者在软限制和硬限制之间逐渐下降。限制可防止磁盘填满速度超过其容量。完整磁盘可能会导致难以修复的问题。硬限制是最大存储限制。

注意

对于 JBOD 存储,限制适用于所有磁盘。如果代理使用两个 1 TB 磁盘,且配额是 1.1 TB,一个磁盘可能会填满,而其他磁盘几乎为空。

先决条件

  • 管理 Kafka 集群的 Cluster Operator 正在运行。

流程

  1. Kafka 资源的 config 添加插件属性。

    这个示例配置中会显示插件属性。

    Kafka 静态配额插件配置示例

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    metadata:
      name: my-cluster
    spec:
      kafka:
        # ...
        config:
          client.quota.callback.class: io.strimzi.kafka.quotas.StaticQuotaCallback 1
          client.quota.callback.static.produce: 1000000 2
          client.quota.callback.static.fetch: 1000000 3
          client.quota.callback.static.storage.soft: 400000000000 4
          client.quota.callback.static.storage.hard: 500000000000 5
          client.quota.callback.static.storage.check-interval: 5 6

    1
    加载 Kafka 静态配额插件。
    2
    设置制作者字节级阈值。本示例中的 1 Mbps.
    3
    设置消费者字节速率的阈值。本示例中的 1 Mbps.
    4
    为存储设置较低的软限制。在本示例中,400 GB。
    5
    为存储设置较高的硬限制。本例中有 500 GB。
    6
    设置存储检查间隔(以秒为单位)。本例中的 5 秒。您可以将其设置为 0 来禁用检查。
  2. 更新资源。

    oc apply -f <kafka_configuration_file>

其他资源

11.8. 常见问题解答

第 12 章 自定义资源 API 参考

12.1. 常见配置属性

常见配置属性适用于多个资源。

12.1.1. replicas

使用 replicas 属性配置副本。

复制的类型取决于资源。

  • KafkaTopic 使用复制因素来配置 Kafka 集群中每个分区的副本数。
  • Kafka 组件使用副本来配置部署中的 pod 数量,以提供更好的可用性和可扩展性。
注意

在 OpenShift 上运行 Kafka 组件时,可能不需要运行多个副本以实现高可用性。部署组件的节点崩溃时,OpenShift 会自动将 Kafka 组件 pod 重新调度到不同的节点。但是,使用多个副本运行 Kafka 组件可更快地出现故障转移时间,因为其他节点将启动并运行。

12.1.2. bootstrapServers

使用 bootstrapServers 属性配置 bootstrap 服务器列表。

bootstrap 服务器列表可以引用没有在同一 OpenShift 集群中部署的 Kafka 集群。它们也可以引用 AMQ Streams 未部署的 Kafka 集群。

如果在同一 OpenShift 集群中,每个列表必须最好包含名为 CLUSTER-NAME-kafka-bootstrap 和端口号的 Kafka 集群 bootstrap 服务。如果 AMQ Streams 但在不同的 OpenShift 集群上部署,列表内容取决于用来公开集群的方法(路由、入口、节点端口或负载均衡器)。

当将 Kafka 与 AMQ Streams 管理的 Kafka 集群一起使用时,您可以根据给定集群的配置指定 bootstrap 服务器列表。

12.1.3. ssl

使用特定 密码套件 作为 TLS 版本,为客户端连接使用三个允许的 ssl 配置选项。密码套件结合了用于安全连接和数据传输的算法。

您还可以配置 ssl.endpoint.identification.algorithm 属性来启用或禁用主机名验证。

SSL 配置示例

# ...
spec:
  config:
    ssl.cipher.suites: "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384" 1
    ssl.enabled.protocols: "TLSv1.2" 2
    ssl.protocol: "TLSv1.2" 3
    ssl.endpoint.identification.algorithm: HTTPS 4
# ...

1
TLS 的密码套件使用 ECDHE 密钥交换机制、RSA 身份验证算法、AES 批量设置算法和 SHA384 MAC 算法的组合。
2
SSl 协议 TLSv1.2 已启用。
3
指定用于生成 SSL 上下文的 TLSv1.2 协议。允许的值是 TLSv1.1TLSv1.2
4
通过设置为 HTTPS 来启用主机名验证。空字符串禁用验证。

12.1.4. trustedCertificates

tls 设置为配置 TLS 加密后,使用 trustedCertificates 属性提供一个 secret 列表,并在其中提供存储为 X.509 格式的密钥名称。

您可以使用 Cluster Operator 为 Kafka 集群创建的 secret,或者您可以使用自己的 TLS 证书文件,然后从文件创建 Secret

oc create secret generic MY-SECRET \
--from-file=MY-TLS-CERTIFICATE-FILE.crt

TLS 加密配置示例

tls:
  trustedCertificates:
    - secretName: my-cluster-cluster-cert
      certificate: ca.crt
    - secretName: my-cluster-cluster-cert
      certificate: ca2.crt

如果证书存储在同一 secret 中,可以多次列出它。

如果要启用 TLS,但使用 Java 附带的默认公共证书颁发机构集合,您可以指定 trustedCertificates 为空数组:

使用默认 Java 证书启用 TLS 的示例

tls:
  trustedCertificates: []

有关配置 TLS 客户端身份验证的详情,请参考 KafkaClientAuthenticationTls schema 引用

12.1.5. 资源

配置 资源的 requestslimits,以控制 AMQ Streams 容器的资源。您可以为 memorycpu 资源指定 requests 和 limits。请求应该足以确保 Kafka 的稳定性能。

如何在生产环境中配置资源取决于多个因素。例如,应用可能会在 OpenShift 集群中共享资源。

对于 Kafka,部署的以下方面可能会影响您需要的资源:

  • 消息吞吐量和大小
  • 处理消息的网络线程数量
  • 制作者和消费者的数量
  • 主题和分区的数量

为资源请求指定的值会被保留,并始终可供容器使用。资源限值指定给定容器可以消耗的最大资源。请求和限制之间的数量不是保留的,可能并不总是可用。容器仅可在有限制时才使用最多的资源。资源限值是临时的,可重新分配。

资源请求和限值

Boundaries of a resource requests and limits

如果您在没有请求或反之设置限值,OpenShift 会将相同的值用于这两个请求。为资源保证服务质量设置相等的请求和限值,因为 OpenShift 不会终止容器,除非容器超过其限值。

您可以为一个或多个支持的资源配置资源请求和限值。

资源配置示例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    #...
    resources:
      requests:
        memory: 64Gi
        cpu: "8"
      limits:
        memory: 64Gi
        cpu: "12"
  entityOperator:
    #...
    topicOperator:
      #...
      resources:
        requests:
          memory: 512Mi
          cpu: "1"
        limits:
          memory: 512Mi
          cpu: "1"

Topic Operator 和 User Operator 的资源请求和限值在 Kafka 资源中设置。

如果资源请求超过 OpenShift 集群中的可用可用资源,则 pod 不会被调度。

注意

AMQ Streams 使用 OpenShift 语法来指定 内存和 cpu 资源。有关在 OpenShift 中管理计算资源的更多信息,请参阅管理容器的计算资源

内存资源

在配置内存资源时,请考虑组件的总要求。

Kafka 在 JVM 中运行,并使用操作系统页面缓存在写入磁盘前存储消息数据。Kafka 的内存请求应该适合 JVM 堆和页面缓存。您可以配置 jvmOptions 属性 来控制最小和最大堆大小。

其他组件不依赖于页面缓存。您可以在不配置 jvmOptions 来控制堆大小的情况下配置内存资源。

内存请求和限值以兆字节、千兆字节和千兆字节为单位指定。在规格中使用以下后缀:

  • M 表示 MB
  • g 代表千兆字节
  • Mi 代表兆字节
  • Gi 代表千兆字节

使用不同内存单元的资源示例

# ...
resources:
  requests:
    memory: 512Mi
  limits:
    memory: 2Gi
# ...

有关内存规格和其他支持的单元的详情,请参考

CPU 资源

CPU 请求应该足以随时提供可靠的性能。CPU 请求和限制指定为 coresmillicpus/millicores

CPU 内核指定为整数(5 个 CPU 内核)或十进制(2.5 CPU 内核)。1000 毫秒1 个 CPU 内核相同。

CPU 单元示例

# ...
resources:
  requests:
    cpu: 500m
  limits:
    cpu: 2.5
# ...

1 个 CPU 内核的计算功能可能因部署 OpenShift 的平台而异。

有关 CPU 规格的更多信息,请参阅 CPU 机制

12.1.6. image

使用 image 属性配置组件使用的容器镜像。

只有在需要使用不同容器 registry 或自定义镜像的特殊情况下,才建议覆盖容器镜像。

例如,如果您的网络不允许访问 AMQ Streams 使用的容器存储库,您可以复制 AMQ Streams 镜像或从源进行构建。但是,如果配置的镜像与 AMQ Streams 镜像不兼容,它可能无法正常工作。

容器镜像的副本也可以进行自定义并可用于调试。

您可以使用以下资源中的 image 属性指定要用于组件的容器镜像:

  • Kafka.spec.kafka
  • Kafka.spec.zookeeper
  • Kafka.spec.entityOperator.topicOperator
  • Kafka.spec.entityOperator.userOperator
  • Kafka.spec.entityOperator.tlsSidecar
  • KafkaConnect.spec
  • KafkaMirrorMaker.spec
  • KafkaMirrorMaker2.spec
  • KafkaBridge.spec

为 Kafka、Kafka Connect 和 Kafka MirrorMaker 配置 镜像属性

Kafka、Kafka Connect 和 Kafka MirrorMaker 支持多个 Kafka 版本。每个组件都需要自己的镜像。不同 Kafka 版本的默认镜像在以下环境变量中配置:

  • STRIMZI_KAFKA_IMAGES
  • STRIMZI_KAFKA_CONNECT_IMAGES
  • STRIMZI_KAFKA_MIRROR_MAKER_IMAGES

这些环境变量包含 Kafka 版本及其对应镜像之间的映射。映射与 镜像和 版本 属性一起使用:

  • 如果自定义资源中未给出 imageversion,则版本将默认为 Cluster Operator 的默认 Kafka 版本,且镜像将是环境变量中与此版本对应的镜像。
  • 如果给定 镜像 但不提供 版本,则使用给定镜像,并且假定 版本为 Cluster Operator 的默认 Kafka 版本。
  • 如果给出了 版本,但 镜像 不是,则使用环境变量中与给定版本对应的镜像。
  • 如果同时指定了 version镜像,则使用给定的镜像。镜像假定为包含带有给定版本的 Kafka 镜像。

不同组件 的镜像和 版本 可在以下属性中配置:

  • 对于 spec.kafka.imagespec.kafka.version 中的 Kafka。
  • 对于 spec.imagespec.version 中的 Kafka Connect 和 Kafka MirrorMaker。
警告

建议您仅提供 版本,并将 image 属性保留为未指定状态。这可减少配置自定义资源时出错的机会。如果您需要更改用于不同版本的 Kafka 的镜像,最好配置 Cluster Operator 的环境变量。

在其他资源中配置 image 属性

对于其他自定义资源中的 image 属性,在部署期间将使用给定值。如果缺少 image 属性,则会使用 Cluster Operator 配置中指定 的镜像。如果 Cluster Operator 配置中没有定义镜像名称,则使用默认值。

  • 对于主题 Operator:

    1. STRIMZI_DEFAULT_TOPIC_OPERATOR_IMAGE 环境变量中指定的容器镜像。
    2. registry.redhat.io/amq7/amq-streams-rhel8-operator:2.2.2 容器镜像。
  • 对于 User Operator:

    1. STRIMZI_DEFAULT_USER_OPERATOR_IMAGE 环境变量中指定的容器镜像。
    2. registry.redhat.io/amq7/amq-streams-rhel8-operator:2.2.2 容器镜像。
  • 对于实体 Operator TLS sidecar:

    1. STRIMZI_DEFAULT_TLS_SIDECAR_ENTITY_OPERATOR_IMAGE 环境变量中指定的容器镜像。
    2. registry.redhat.io/amq7/amq-streams-kafka-32-rhel8:2.2.2 容器镜像。
  • 对于 Kafka 导出器:

    1. 在 Cluster Operator 配置中的 STRIMZI_DEFAULT_KAFKA_EXPORTER_IMAGE 环境变量中指定的容器镜像。
    2. registry.redhat.io/amq7/amq-streams-kafka-32-rhel8:2.2.2 容器镜像。
  • 对于 Kafka Bridge:

    1. 在 Cluster Operator 配置中的 STRIMZI_DEFAULT_KAFKA_BRIDGE_IMAGE 环境变量中指定的容器镜像。
    2. registry.redhat.io/amq7/amq-streams-bridge-rhel8:2.2.2 容器镜像。
  • 对于 Kafka 代理初始化器:

    1. 在 Cluster Operator 配置中的 STRIMZI_DEFAULT_KAFKA_INIT_IMAGE 环境变量中指定的容器镜像。
    2. registry.redhat.io/amq7/amq-streams-rhel8-operator:2.2.2 容器镜像。

容器镜像配置示例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    image: my-org/my-image:latest
    # ...
  zookeeper:
    # ...

12.1.7. livenessProbereadinessProbe 状况检查

使用 livenessProbereadinessProbe 属性配置 AMQ Streams 中支持的健康检查探测。

状况检查是定期测试,验证应用程序的健康状态。当 Healthcheck 探测失败时,OpenShift 会假定应用处于健康状态,并尝试修复它。

有关探测的详情,请参阅 配置存活度和就绪度探测

livenessProbereadinessProbe 支持以下选项:

  • initialDelaySeconds
  • timeoutSeconds
  • periodSeconds
  • successThreshold
  • failureThreshold

存活度和就绪度探测配置示例

# ...
readinessProbe:
  initialDelaySeconds: 15
  timeoutSeconds: 5
livenessProbe:
  initialDelaySeconds: 15
  timeoutSeconds: 5
# ...

有关 livenessProbereadinessProbe 选项的更多信息,请参阅 探测模式参考

12.1.8. metricsConfig

使用 metricsConfig 属性来启用和配置 Prometheus 指标。

metricsConfig 属性包含对 ConfigMap 的引用,该 ConfigMap 具有 Prometheus JMX Exporter 的额外配置。AMQ Streams 支持使用 Prometheus JMX exporter 的 Prometheus 指标,将 Apache Kafka 和 ZooKeeper 支持的 JMX 指标转换为 Prometheus 指标。

要在不进一步配置的情况下启用 Prometheus metrics 导出,您可以在 metricsConfig.valueFrom.configMapKeyRef.key 下引用包含空文件的 ConfigMap。当引用空文件时,所有指标都会公开,只要它们尚未重命名。

带有 Kafka 指标配置的 ConfigMap 示例

kind: ConfigMap
apiVersion: v1
metadata:
  name: my-configmap
data:
  my-key: |
    lowercaseOutputName: true
    rules:
    # Special cases and very specific rules
    - pattern: kafka.server<type=(.+), name=(.+), clientId=(.+), topic=(.+), partition=(.*)><>Value
      name: kafka_server_$1_$2
      type: GAUGE
      labels:
       clientId: "$3"
       topic: "$4"
       partition: "$5"
    # further configuration

Kafka 的指标配置示例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    metricsConfig:
      type: jmxPrometheusExporter
      valueFrom:
        configMapKeyRef:
          name: my-config-map
          key: my-key
    # ...
  zookeeper:
    # ...

启用指标后,它们会在端口 9404 上公开。

当资源中没有定义 metricsConfig (或已弃用 指标)属性时,会禁用 Prometheus 指标。

有关设置和部署 Prometheus 和 Grafana 的更多信息,请参阅在 OpenShift 指南中的部署和升级 AMQ Streams 中将 指标引入到 Kafka

12.1.9. jvmOptions

以下 AMQ Streams 组件在 Java 虚拟机(JVM)中运行:

  • Apache Kafka
  • Apache ZooKeeper
  • Apache Kafka Connect
  • Apache Kafka MirrorMaker
  • AMQ Streams Kafka Bridge

要在不同平台和构架中优化其性能,您可以在以下资源中配置 jvmOptions 属性:

  • Kafka.spec.kafka
  • Kafka.spec.zookeeper
  • Kafka.spec.entityOperator.userOperator
  • Kafka.spec.entityOperator.topicOperator
  • Kafka.spec.cruiseControl
  • KafkaConnect.spec
  • KafkaMirrorMaker.spec
  • KafkaMirrorMaker2.spec
  • KafkaBridge.spec

您可以在配置中指定以下选项:

-Xms
JVM 启动后最少初始分配堆大小
-Xmx
最大堆大小
-XX
JVM 的高级运行时选项
javaSystemProperties
其他系统属性
gcLoggingEnabled
启用垃圾收集器日志记录
注意

JVM 设置(如 -Xmx-Xms )接受的单元与对应镜像中 JDK java 二进制文件接受的单元相同。因此,1g1G 表示 1、073、741、824 字节,Gi 不是有效的单元后缀。这与用于 内存请求和限制的单元不同,它遵循 OpenShift 约 1G 表示 1,000,000,000 字节,1Gi 表示 1,073,741,824 字节。

-Xms-Xmx 选项

除了为容器设置内存请求和限制值外,您还可以使用 -Xms-Xmx JVM 选项为您的 JVM 设置特定的堆大小。使用 -Xms 选项设置初始堆大小和 -Xmx 选项,以设置最大堆大小。

指定堆大小,以便对分配给 JVM 的内存拥有更多控制权。堆大小应该最好地使用容器 的内存限值(和请求), 而不超过它。堆大小和任何其他内存要求需要在指定的内存限值内容纳。如果您没有在配置中指定堆大小,但配置内存资源限制(和请求),Cluster Operator 会自动实施默认堆大小。Cluster Operator 根据内存资源配置百分比设置默认的最大值和最小堆值。

下表显示了默认的堆值。

表 12.1. 组件的默认堆设置
组件分配给堆的可用内存百分比最大限制

Kafka

50%

5 GB

ZooKeeper

75%

2 GB

Kafka Connect

75%

None

MirrorMaker 2.0

75%

None

MirrorMaker

75%

None

Sything Control

75%

None

Kafka Bridge

50%

31 Gi

如果没有指定内存限制(和请求),则 JVM 的最小堆大小设为 128M。JVM 的最大堆大小没有被定义,以允许内存根据需要增加。这是测试和开发中单一节点环境的理想选择。

设置适当的内存请求可能会阻止以下内容:

  • 如果节点上运行的其他容器集的内存压力,OpenShift 会终止容器。
  • OpenShift 将容器调度到内存不足的节点。如果 -Xms 设为 -Xmx,则容器将立即崩溃;如果没有,则容器将在以后崩溃。

在本例中,JVM 将 2 GiB (=2,147,483,648 字节)用于其堆。JVM 内存用量总量可能比最大堆大小大。

示例 -Xmx-Xms 配置

# ...
jvmOptions:
  "-Xmx": "2g"
  "-Xms": "2g"
# ...

为初始(-Xms)和最大值(-Xmx)堆大小设置相同的值可以避免 JVM 必须在启动时分配内存,因为可能分配比真正需要的堆多。

重要

容器执行大量磁盘 I/O,如 Kafka 代理容器,需要可用内存用作操作系统页面缓存。对于这些容器,请求的内存应显著大于 JVM 使用的内存。

-XX 选项

-XX 选项用于配置 Apache Kafka 的 KAFKA_JVM_PERFORMANCE_OPTS 选项。

示例 -XX 配置

jvmOptions:
  "-XX":
    "UseG1GC": true
    "MaxGCPauseMillis": 20
    "InitiatingHeapOccupancyPercent": 35
    "ExplicitGCInvokesConcurrent": true

-XX 配置生成的 JVM 选项

-XX:+UseG1GC -XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35 -XX:+ExplicitGCInvokesConcurrent -XX:-UseParNewGC

注意

如果没有指定 -XX 选项,则使用 KAFKA_JVM_PERFORMANCE_OPTS 的默认 Apache Kafka 配置。

javaSystemProperties

javaSystemProperties 用于配置其他 Java 系统属性,如调试实用程序。

javaSystemProperties 配置示例

jvmOptions:
  javaSystemProperties:
    - name: javax.net.debug
      value: ssl

有关 jvmOptions 的更多信息,请参见 JvmOptions 模式参考

12.1.10. 垃圾收集器日志记录

jvmOptions 属性还允许您启用和禁用垃圾回收器(GC)日志记录。GC 日志记录默认为禁用。要启用它,请按如下所示设置 gcLoggingEnabled 属性:

GC 日志记录配置示例

# ...
jvmOptions:
  gcLoggingEnabled: true
# ...

12.2. 模式属性

12.2.1. Kafka 模式参考

属性Description

spec

Kafka 和 ZooKeeper 集群的规格和主题 Operator。

KafkaSpec

status

Kafka 和 ZooKeeper 集群的状态,以及主题 Operator。

KafkaStatus

12.2.2. KafkaSpec 模式参考

使用的: Kafka

属性Description

kafka

Kafka 集群配置。

KafkaClusterSpec

zookeeper

ZooKeeper 集群的配置。

ZookeeperClusterSpec

entityOperator

配置实体 Operator。

EntityOperatorSpec

clusterCa

集群证书颁发机构配置。

certificateAuthority

clientsCa

配置客户端证书颁发机构。

certificateAuthority

cruiseControl

配置控制部署。在指定时部署 Cruise Control 实例。

CruiseControlSpec

kafkaExporter

Kafka 导出器配置。Kafka Exporter 可以提供额外的指标,例如主题/分区中的使用者组。

KafkaExporterSpec

maintenanceTimeWindows

维护任务的时间窗口列表(即证书续订)。每次时间窗都由 cron 表达式定义。

字符串数组

12.2.3. KafkaClusterSpec 模式参考

使用的: KafkaSpec

KafkaClusterSpec 模式属性的完整列表

配置 Kafka 集群。

12.2.3.1. 监听器

使用 监听程序 属性配置监听程序来提供对 Kafka 代理的访问。

在没有身份验证的情况下配置普通(未加密)监听器的示例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
spec:
  kafka:
    # ...
    listeners:
      - name: plain
        port: 9092
        type: internal
        tls: false
    # ...
  zookeeper:
    # ...

12.2.3.2. config

使用 config 属性将 Kafka 代理选项配置为密钥。

可以提供标准 Apache Kafka 配置,仅限于不直接由 AMQ Streams 管理的属性。

无法配置与以下内容相关的配置选项:

  • 安全(加密、验证和授权)
  • 侦听器配置
  • 代理 ID 配置
  • 配置日志数据目录
  • 在代理间通信
  • zookeeper 连接性

这些值可以是以下 JSON 类型之一:

  • 字符串
  • Number
  • 布尔值

除了直接由 AMQ Streams 管理的选项外,您可以指定并配置 Apache Kafka 文档 中列出的选项。具体来说,所有与以下字符串之一相等或开始的配置选项都会被禁止:

  • 监听器
  • 广告:
  • 代理.
  • 侦听器.
  • host.name
  • port
  • inter.broker.listener.name
  • SASL:
  • SSL.
  • 安全性.
  • 密码.
  • principal.builder.class
  • log.dir
  • zookeeper.connect
  • zookeeper.set.acl
  • 授权者.
  • super.user

当在 config 属性中存在禁止选项时,它会被忽略,并将警告消息输出到 Cluster Operator 日志文件。所有其他支持选项都传递给 Kafka。

禁止的选项有例外。对于将特定 密码套件 用于 TLS 版本的客户端连接,您可以配置允许的 ssl 属性。您还可以配置 zookeeper.connection.timeout.ms 属性来设置建立 ZooKeeper 连接的最大时间。

Kafka 代理配置示例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    config:
      num.partitions: 1
      num.recovery.threads.per.data.dir: 1
      default.replication.factor: 3
      offsets.topic.replication.factor: 3
      transaction.state.log.replication.factor: 3
      transaction.state.log.min.isr: 1
      log.retention.hours: 168
      log.segment.bytes: 1073741824
      log.retention.check.interval.ms: 300000
      num.network.threads: 3
      num.io.threads: 8
      socket.send.buffer.bytes: 102400
      socket.receive.buffer.bytes: 102400
      socket.request.max.bytes: 104857600
      group.initial.rebalance.delay.ms: 0
      ssl.cipher.suites: "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384"
      ssl.enabled.protocols: "TLSv1.2"
      ssl.protocol: "TLSv1.2"
      zookeeper.connection.timeout.ms: 6000
    # ...

12.2.3.3. brokerRackInitImage

启用机架感知后,Kafka 代理 pod 使用 init 容器从 OpenShift 集群节点收集标签。可以使用 brokerRackInitImage 属性配置用于此容器的容器镜像。当缺少 brokerRackInitImage 字段时,会按优先级顺序使用以下镜像:

  1. 在 Cluster Operator 配置中的 STRIMZI_DEFAULT_KAFKA_INIT_IMAGE 环境变量中指定的容器镜像。
  2. registry.redhat.io/amq7/amq-streams-rhel8-operator:2.2.2 容器镜像。

brokerRackInitImage 配置示例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    rack:
      topologyKey: topology.kubernetes.io/zone
    brokerRackInitImage: my-org/my-image:latest
    # ...

注意

建议您仅在需要使用其他容器 registry 的特殊情况下覆盖容器镜像。例如,因为您的网络不允许访问 AMQ Streams 使用的容器 registry。在这种情况下,您应该复制 AMQ Streams 镜像,或者从源构建它们。如果配置的镜像与 AMQ Streams 镜像不兼容,则可能无法正常工作。

12.2.3.4. logging

Kafka 都有自己的可配置的日志记录器:

  • log4j.logger.org.I0Itec.zkclient.ZkClient
  • log4j.logger.org.apache.zookeeper
  • log4j.logger.kafka
  • log4j.logger.org.apache.kafka
  • log4j.logger.kafka.request.logger
  • log4j.logger.kafka.network.Processor
  • log4j.logger.kafka.server.KafkaApis
  • log4j.logger.kafka.network.RequestChannel$
  • log4j.logger.kafka.controller
  • log4j.logger.kafka.log.LogCleaner
  • log4j.logger.state.change.logger
  • log4j.logger.kafka.authorizer.logger

Kafka 使用 Apache log4j 日志记录器实现。

使用 logging 属性配置日志记录器和日志记录器级别。

您可以通过直接指定日志记录器和级别(在线)或使用自定义(外部) ConfigMap 来设置日志级别。如果使用 ConfigMap,您可以将 logging.valueFrom.configMapKeyRef.name 属性设置为包含外部日志记录配置的 ConfigMap 的名称。在 ConfigMap 中,日志记录配置使用 log4j.properties 来描述。logging.valueFrom.configMapKeyRef.namelogging.valueFrom.configMapKeyRef.key 属性都是必须的。当 Cluster Operator 运行时,会使用指定的日志记录配置创建 ConfigMap,然后在每次协调后重新创建。如果没有指定自定义 ConfigMap,则会使用默认的日志记录设置。如果没有设置特定的日志记录器值,则会继承该日志记录器的上级日志记录器设置。有关日志级别的更多信息,请参阅 Apache 日志记录服务

此处会看到 内联外部日志记录 的示例。

内联日志

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
spec:
  # ...
  kafka:
    # ...
    logging:
      type: inline
      loggers:
        kafka.root.logger.level: "INFO"
  # ...

外部日志记录

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
spec:
  # ...
  logging:
    type: external
    valueFrom:
      configMapKeyRef:
        name: customConfigMap
        key: kafka-log4j.properties
  # ...

任何尚未配置级别的可用日志记录器都设置为 OFF

如果使用 Cluster Operator 部署 Kafka,则会动态应用对 Kafka 日志记录级别的更改。

如果使用外部日志记录,则在日志附加器更改时触发滚动更新。

垃圾收集器(GC)

也可以使用 jvmOptions 属性 来启用(或禁用)垃圾收集器日志记录。

12.2.3.5. KafkaClusterSpec 模式属性
属性Description

version

kafka 代理版本。默认为 3.2.3。参阅用户文档来了解升级或降级版本所需的流程。

字符串

replicas

集群中的 pod 数量。

整数

image

pod 的 docker 镜像。默认值取决于配置的 Kafka.spec.kafka.version

字符串

监听器

配置 Kafka 代理的监听程序。

GenericKafkaListener 数组

config

带有以下前缀的 Kafka 代理配置属性无法设置:监听器、代理、侦听器、host.name、端口、inter.broker.listener.name、sasl.、ssl、security.、password.、log.dir、zookeeper.connect、zookeeper.set.acl、zookeeper.ssl、zookeeper.ssl zookeeper.clientCnxnSocket, authorizer., super.user, cruise.control.metrics.metrics.control.metrics.reporter.bootstrap.servers,node.id, process.roles, controller. (zookeeper.connection.timeout.ms, ssl.cipher.suites, ssl.cipher.suites, SSL.protocol, ssl.enabled.protocols,cruise.control.topic.num.partitions, cruise.control.metrics.replication.replication. reasons, cruise.control.metrics.topic.retention.ms,cruise.metrics.metrics.auto.create.auto.create.retries, cruise.control.topic.autocreate.autocreate.auto.ms.ms,cruise.metrics.topic.auto.retries, cruise.control.topic.auto cruise.control.topic.min.insync.replicas,controller.quorum.election.backoff.max.ms, controller.quorum.election.timeout.ms, controller.quorum.fetch.timeout.ms)。

map

storage

存储配置(磁盘)。无法更新。这个类型取决于给定对象中的 storage.type 属性的值,它必须是 [ephemeral、persistent-claim 和 jbod] 之一。

EphemeralStorage, PersistentClaimStorage, JbodStorage

授权

Kafka 代理的授权配置。类型取决于给定对象中的 authorization.type 属性的值,它必须是 [simple, opa, keycloak, custom] 之一。

KafkaAuthorizationSimple, KafkaAuthorizationOpa, KafkaAuthorizationKeycloak, KafkaAuthorizationCustom

rack

配置 broker.rack 代理配置。

rack

brokerRackInitImage

用于初始化 代理的 init 容器的镜像。rack

字符串

livenessProbe

Pod 存活度检查。

探测

readinessProbe

Pod 就绪度检查.

探测

jvmOptions

pod 的 JVM 选项。

JvmOptions

jmxOptions

Kafka 代理的 JMX 选项。

KafkaJmxOptions

资源

要保留的 CPU 和内存资源。如需更多信息,请参阅 core/v1 资源查询的外部文档

ResourceRequirements

metricsConfig

指标配置。这个类型取决于给定对象中的 metricsConfig.type 属性的值,它必须是 [jmxPrometheusExporter] 之一。

JmxPrometheusExporterMetrics

logging

Kafka 的日志记录配置。类型取决于给定对象中的 logging.type 属性的值,它必须是 [inline, external] 中的一个。

InlineLogging, ExternalLogging

模板

Kafka 集群资源的模板。通过该模板,用户可以指定如何生成 StatefulSetPodServices

KafkaClusterTemplate

12.2.4. GenericKafkaListener 模式参考

使用的: KafkaClusterSpec

GenericKafkaListener 模式属性的完整列表

配置监听程序以连接到 OpenShift 内部和外部的 Kafka 代理。

您可以在 Kafka 资源中配置监听程序。

显示监听程序配置的 Kafka 资源示例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    #...
    listeners:
      - name: plain
        port: 9092
        type: internal
        tls: false
      - name: tls
        port: 9093
        type: internal
        tls: true
        authentication:
          type: tls
      - name: external1
        port: 9094
        type: route
        tls: true
      - name: external2
        port: 9095
        type: ingress
        tls: true
        authentication:
          type: tls
        configuration:
          bootstrap:
            host: bootstrap.myingress.com
          brokers:
          - broker: 0
            host: broker-0.myingress.com
          - broker: 1
            host: broker-1.myingress.com
          - broker: 2
            host: broker-2.myingress.com
    #...

12.2.4.1. 监听器

您可以使用 Kafka 资源中的 监听程序 属性配置 Kafka 代理监听程序。侦听器定义为数组。

监听程序配置示例

listeners:
  - name: plain
    port: 9092
    type: internal
    tls: false

在 Kafka 集群中,名称和端口必须是唯一的。名称最多可包含 25 个字符,由小写字母和数字组成。允许的端口号为 9092 及更高版本,除了端口 9404 和 9999 除外,后者已用于 Prometheus 和 JMX。

通过为每个监听器指定唯一名称和端口,您可以配置多个监听程序。

12.2.4.2. type

这个类型设置为 内部,或将外部监听器设置为 路由loadbalancernodeportingress

internal

您可以使用 tls 属性或不加密配置内部监听程序。

内部 监听程序配置示例

#...
spec:
  kafka:
    #...
    listeners:
      #...
      - name: plain
        port: 9092
        type: internal
        tls: false
      - name: tls
        port: 9093
        type: internal
        tls: true
        authentication:
          type: tls
    #...

route

配置外部监听程序,以使用 OpenShift Routes 和 HAProxy 路由器公开 Kafka。

为每个 Kafka 代理 pod 创建专用的 Route。创建额外 路由 以作为 Kafka bootstrap 地址。Kafka 客户端可以使用这些 路由 连接到端口 443 上的 Kafka。客户端通过端口 443 连接默认的路由器端口,但流量会被路由到您配置的端口,本例中为 9094

路由 监听程序配置示例

#...
spec:
  kafka:
    #...
    listeners:
      #...
      - name: external1
        port: 9094
        type: route
        tls: true
    #...

ingress

配置一个外部监听程序,以使用 Kubernetes IngressNGINX Ingress Controller 来公开 Kafka。

为每个 Kafka 代理 pod 创建专用的 Ingress 资源。创建额外的 Ingress 资源,以用作 Kafka bootstrap 地址。Kafka 客户端可以使用这些 Ingress 资源连接到端口 443 上的 Kafka。客户端通过端口 443 连接默认的控制器端口,但流量会被路由到您配置的端口,本例中为 9095

您必须使用 GenericKafkaListenerConfigurationBootstrapGenericKafkaListenerConfigurationBroker 属性指定 bootstrap 和 per-broker 服务使用的主机名。

入口 监听程序配置示例

#...
spec:
  kafka:
    #...
    listeners:
      #...
      - name: external2
        port: 9095
        type: ingress
        tls: true
        authentication:
          type: tls
        configuration:
          bootstrap:
            host: bootstrap.myingress.com
          brokers:
          - broker: 0
            host: broker-0.myingress.com
          - broker: 1
            host: broker-1.myingress.com
          - broker: 2
            host: broker-2.myingress.com
  #...

注意

使用 Ingress 的外部监听程序目前只使用 Kubernetes 的 NGINX Ingress Controller 进行测试。

LoadBalancer

配置外部监听程序以公开 Kafka Loadbalancer 类型 服务

为每个 Kafka 代理 pod 创建一个新的负载均衡器服务。创建了一个额外的负载均衡器来充当 Kafka bootstrap 地址。loadbalancers 侦听指定的端口号,本例中为端口 9094

您可以使用 loadBalancerSourceRanges 属性配置 源范围 来限制对指定的 IP 地址的访问。

loadbalancer 侦听器配置示例

#...
spec:
  kafka:
    #...
    listeners:
      - name: external3
        port: 9094
        type: loadbalancer
        tls: true
        configuration:
          loadBalancerSourceRanges:
            - 10.0.0.0/8
            - 88.208.76.87/32
    #...

nodeport

配置外部监听程序,以使用 NodePort 类型 Services 来公开 Kafka。

Kafka 客户端直接连接到 OpenShift 节点。创建额外的 NodePort 服务类型用作 Kafka bootstrap 地址。

为 Kafka 代理 pod 配置公告的地址时,AMQ Streams 使用给定 pod 在运行的节点的地址。您可以使用 preferredNodePortAddressType 属性配置 检查的第一个地址类型作为节点地址

节点端口 监听程序配置示例

#...
spec:
  kafka:
    #...
    listeners:
      #...
      - name: external4
        port: 9095
        type: nodeport
        tls: false
        configuration:
          preferredNodePortAddressType: InternalDNS
    #...

注意

使用节点端口公开 Kafka 集群时,当前不支持 TLS 主机名验证。

12.2.4.3. port

端口号是 Kafka 集群中使用的端口,这可能不是客户端用来访问的端口。

  • LoadBalancer 侦听程序使用指定的端口号,作为 内部 监听程序
  • Ingress路由 监听程序使用端口 443 进行访问
  • NodePort 侦听程序使用 OpenShift 分配的端口号

对于客户端连接,请使用监听程序的 bootstrap 服务的地址和端口。您可以从 Kafka 资源的状态中检索它。

检索客户端连接的地址和端口的示例

oc get kafka <kafka_cluster_name> -o=jsonpath='{.status.listeners[?(@.name=="<listener_name>")].bootstrapServers}{"\n"}'

注意

监听器无法配置为使用设置代理通信的端口(9090 和 9091)和指标(9404)。

12.2.4.4. tls

TLS 属性是必需的。

默认情况下不启用 TLS 加密。要启用它,请将 tls 属性设置为 true

TLS 加密总是 与路由 监听程序一起使用。

12.2.4.5. 身份验证

侦听器的身份验证可指定为:

  • 双向 TLS (tls)
  • SCRAM-SHA-512 (scram-sha-512)
  • 基于令牌的 OAuth 2.0 (oauth)
  • 自定义(自定义)
12.2.4.6. networkPolicyPeers

使用 networkPolicyPeers 配置网络策略,以限制访问网络级别的监听程序。以下示例显示了 为纯文本tls 侦听器配置的 networkPolicyPeers 配置。

listeners:
  #...
  - name: plain
    port: 9092
    type: internal
    tls: true
    authentication:
      type: scram-sha-512
    networkPolicyPeers:
      - podSelector:
          matchLabels:
            app: kafka-sasl-consumer
      - podSelector:
          matchLabels:
            app: kafka-sasl-producer
  - name: tls
    port: 9093
    type: internal
    tls: true
    authentication:
      type: tls
    networkPolicyPeers:
      - namespaceSelector:
          matchLabels:
            project: myproject
      - namespaceSelector:
          matchLabels:
            project: myproject2
# ...

在示例中:

  • 只有与 labels app: kafka-sasl-consumerapp: kafka-sasl-producer 匹配的应用程序 pod 可以连接到 普通 的监听程序。应用程序 pod 必须与 Kafka 代理在同一命名空间中运行。
  • 只有在与标签 project: myproject and project: myproject2 的命名空间中运行的应用程序 pod 才可以连接到 tls 侦听程序。

networkPolicyPeers 字段的语法与 NetworkPolicy 资源中的 from 字段相同。

12.2.4.7. GenericKafkaListener 模式属性
属性Description

name

侦听器的名称。名称将用于识别监听程序和相关的 OpenShift 对象。该名称必须在给定的 Kafka 集群中唯一。名称可以包含小写字母字符和数字,最多为 11 个字符。

字符串

port

Kafka 内监听器使用的端口号。端口号必须在给定的 Kafka 集群中唯一。允许的端口号为 9092 及更高版本,除了端口 9404 和 9999 除外,后者已用于 Prometheus 和 JMX。根据监听程序类型,端口号可能与连接 Kafka 客户端的端口号不同。

整数

type

侦听器的类型。目前,支持的类型有 内部routeloadbalancernodeportingress

  • 内部 类型仅在 OpenShift 集群内部公开 Kafka。
  • 路由 类型使用 OpenShift 路由来公开 Kafka。
  • LoadBalancer 类型使用 LoadBalancer 类型服务来公开 Kafka。
  • NodePort 类型 使用 NodePort 类型服务来公开 Kafka。
  • Ingress 类型使用 OpenShift Nginx Ingress 来公开 Kafka。

字符串(一个 [ingress, internal, route, loadbalancer, nodeport])

tls

在监听器上启用 TLS 加密。这是必需的属性。

布尔值

身份验证

此侦听器的身份验证配置。这个类型取决于给定对象中的 authentication.type 属性的值,它必须是 [tls, scram-sha-512, oauth, custom] 之一。

KafkaListenerAuthenticationTls, KafkaListenerAuthenticationScramSha512, KafkaListenerAuthenticationOAuth, KafkaListenerAuthenticationCustom

配置

其他侦听器配置。

GenericKafkaListenerConfiguration

networkPolicyPeers

应连接到此侦听器的对等点列表。使用逻辑 OR 操作组合此列表中的对等点。如果此字段为空或缺失,则此监听器将允许所有连接。如果此字段存在且至少包含一个项目,则监听程序只允许与此列表中至少匹配一个项目的流量。如需更多信息,请参阅 networking.k8s.io/v1 networkpolicypeer 的外部文档

NetworkPolicyPeer 数组

12.2.5. KafkaListenerAuthenticationTls 模式参考

使用的: GenericKafkaListener

type 属性是一种差异性,用于区分来自 KafkaListenerAuthenticationScramSha512KafkaListenerAuthenticationTls 类型、KafkaListenerAuthenticationOAuthKafkaListenerAuthenticationCustom。它必须具有类型为 KafkaListenerAuthenticationTls 的值 tls

属性Description

type

必须为 tls

字符串

12.2.6. KafkaListenerAuthenticationScramSha512 模式参考

使用的: GenericKafkaListener

type 属性是一种差异性,用于区分来自 KafkaListenerAuthenticationTls, KafkaListenerAuthenticationOAuth, KafkaListenerAuthenticationCustomKafkaListenerAuthenticationScramSha512 类型。对于类型 KafkaListenerAuthenticationScramSha512,它需要值 scram-sha-512

属性Description

type

必须为 scram-sha-512

字符串

12.2.7. KafkaListenerAuthenticationOAuth 模式参考

使用的: GenericKafkaListener

type 属性是一种差异性,用于区分 KafkaListenerAuthentication OAuth 类型来自 KafkaListenerAuthenticationTlsKafkaListenerAuthenticationScramSha512KafkaListenerAuthenticationCustom。对于类型 KafkaListenerAuthenticationOAuth,它需要带有值 oauth

属性Description

accessTokenIsJwt

配置访问令牌是否被视为 JWT。如果授权服务器返回不透明令牌,则必须将其设置为 false。默认值为 true

布尔值

checkAccessTokenType

配置访问令牌类型检查是否执行。如果授权服务器在 JWT 令牌中不包含 'typ' 声明,则此项应设为 false。默认值为 true

布尔值

checkAudience

启用或禁用受众检查。受众检查确定令牌的接收者。如果启用了受众检查,还必须使用 clientId 属性配置 OAuth 客户端 ID。Kafka 代理将拒绝在其 aud (audience) 声明中没有其 clientId 的令牌。默认值为 false

布尔值

checkIssuer

启用或禁用签发者检查。默认情况下,使用由 validIssuerUri 配置的值来检查签发者。默认值为 true

布尔值

clientAudience

在向授权服务器的令牌端点发出请求时使用的对象。用于交集身份验证并使用 clientIdsecret 方法通过 PLAIN 配置 OAuth 2.0。

字符串

clientId

Kafka 代理可以用来对授权服务器进行身份验证的 OAuth 客户端 ID,并使用 introspect 端点 URI。

字符串

clientScope

向授权服务器的令牌端点发出请求时使用的范围。用于交集身份验证并使用 clientIdsecret 方法通过 PLAIN 配置 OAuth 2.0。

字符串

clientSecret

链接到包含 Kafka 代理可以用来进行授权服务器进行身份验证的 OAuth 客户端 secret 的 OpenShift Secret,并使用 introspect 端点 URI。

GenericSecretSource

connectTimeoutSeconds

连接授权服务器时出现连接超时(以秒为单位)。如果没有设置,则有效连接超时为 60 秒。

整数

customClaimCheck

JSONPath 过滤器查询以应用到 JWT 令牌,或对内省端点的响应进行额外的令牌验证。默认情况下不设置。

字符串

disableTlsHostnameVerification

启用或禁用 TLS 主机名验证。默认值为 false

布尔值

enableECDSA

enableECDSA 属性已弃用。通过安装 BouncyCastle crypto provider 启用或禁用 ECDSA 支持。ECDSA 支持始终被启用。BouncyCastle 库不再被 AMQ Streams 打包。值将被忽略。

布尔值

enableOauthBearer

启用或禁用 SASL_OAUTHBEARER 的 OAuth 身份验证。默认值为 true

布尔值

enablePlain

启用或禁用 SASL_PLAIN 的 OAuth 身份验证。使用这种机制时,不支持重新身份验证。默认值为 false

布尔值

fallbackUserNameClaim

如果不存在 userNameClaim 指定的声明,则将用于用户 ID 的回退用户名声明。当 client_credentials 身份验证仅会导致在另一个声明中提供客户端 ID 时,这很有用。只有在设置了 userNameClaim 时,它才会生效。

字符串

fallbackUserNamePrefix

要用于 fallbackUserNameClaim 值的前缀来构造用户 ID。这只有在 fallbackUserNameClaim 为 true 时才生效,并且声明的值存在。在防止名称冲突时,将用户名和客户端 ID 映射到相同的用户 id 空间非常有用。

字符串

groupsClaim

JSONPath 查询,用于在身份验证过程中提取用户的组。提取的组可被自定义授权者使用。默认情况下不提取任何组。

字符串

groupsClaimDelimiter

用于在将组提取为单个 String 值而不是 JSON 数组的分隔符。默认值为 ','(comma)。

字符串

introspectionEndpointUri

令牌内省端点的 URI,可用于验证不透明的非JWT 令牌。

字符串

jwksEndpointUri

JWKS 证书端点的 URI,可用于本地 JWT 验证。

字符串

jwksExpirySeconds

配置 JWKS 证书被视为有效的频率。到期间隔必须至少为 60 秒,然后在 jwksRefreshSeconds 中指定刷新间隔。默认为 360 秒。

整数

jwksMinRefreshPauseSeconds

连续两次刷新之间的最短暂停。遇到未知签名密钥时,立即调度刷新,但会始终等待这个最小暂停。默认为 1 秒。

整数

jwksRefreshSeconds

配置 JWKS 证书刷新的频率。刷新间隔必须至少为 60 秒,然后是 jwksExpirySeconds 中指定的到期间隔。默认值为 300 秒。

整数

maxSecondsWithoutReauthentication

经过身份验证的会话在无需再身份验证的情况下保持有效的最多秒数。这可让 Apache Kafka 重新验证功能,并在访问令牌过期时导致会话过期。如果访问令牌在最大时间或达到最大时间前过期,客户端必须重新验证,否则服务器将丢弃连接。默认不设置 - 经过身份验证的用户会话会在访问令牌过期时过期。这个选项只适用于 SASL_OAUTHBEARER 身份验证机制(在 enableOauthBearertrue时)。

整数

readTimeoutSeconds

连接到授权服务器时读取超时(以秒为单位)。如果没有设置,则有效读取超时为 60 秒。

整数

tlsTrustedCertificates

TLS 与 OAuth 服务器连接的可信证书。

CertSecretSource 数组

tokenEndpointUri

客户端通过 clientIdsecret 进行身份验证时,用于 SASL_PLAIN 机制的 Token 端点的 URI。如果设置,客户端可以通过 SASL_PLAIN 验证,方法是将 用户名 设置为 clientId,并将 密码设为 客户端 secret,也可以通过将用户名设置为 account username,并将密码设置为 account username,并将 password 设置为前缀为 $accessToken:。如果没有设置这个选项,则 密码 始终被解释为访问令牌(没有前缀),用户名作为帐户用户名 (因此名为 'no-client-credentials' 模式)。

字符串

type

必须是 oauth

字符串

userInfoEndpointUri

当 Introspection Endpoint 没有返回可以用于用户 ID 的信息时,User Info Endpoint 的 URI 用作回退来获取用户 ID。

字符串

userNameClaim

JWT 身份验证令牌声明的名称、Introspection Endpoint 响应或 User Info Endpoint 响应,用于提取用户 ID。默认为 sub

字符串

validIssuerUri

用于身份验证的令牌签发者的 URI。

字符串

validTokenType

Introspection Endpoint 返回的 token_type 属性的有效值。没有默认值,默认情况下不选中。

字符串

12.2.8. GenericSecretSource 模式参考

使用的: KafkaClientAuthenticationOAuth, KafkaListenerAuthenticationCustom, KafkaListenerAuthenticationOAuth

属性Description

key

secret 值存储在 OpenShift Secret 中的键。

字符串

secretName

包含 secret 值的 OpenShift Secret 名称。

字符串

12.2.9. CertSecretSource 模式参考

中使用的:client Tls , KafkaAuthorizationKeycloak, KafkaClientAuthenticationOAuth, KafkaListenerAuthenticationOAuth

属性Description

certificate

Secret 中文件证书的名称。

字符串

secretName

包含证书的 Secret 的名称。

字符串

12.2.10. KafkaListenerAuthenticationCustom schema 参考

使用的: GenericKafkaListener

KafkaListenerAuthenticationCustom schema 属性的完整列表

要配置自定义身份验证,请将 type 属性设置为 custom

自定义身份验证允许使用任何类型的 kafka-supported 验证。

自定义 OAuth 身份验证配置示例

spec:
  kafka:
    config:
      principal.builder.class: SimplePrincipal.class
    listeners:
      - name: oauth-bespoke
        port: 9093
        type: internal
        tls: true
        authentication:
          type: custom
          sasl: true
          listenerConfig:
            oauthbearer.sasl.client.callback.handler.class: client.class
            oauthbearer.sasl.server.callback.handler.class: server.class
            oauthbearer.sasl.login.callback.handler.class: login.class
            oauthbearer.connections.max.reauth.ms: 999999999
            sasl.enabled.mechanisms: oauthbearer
            oauthbearer.sasl.jaas.config: |
              org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required ;
          secrets:
            - name: example

生成协议映射,它使用 sasltls 值来确定要映射到监听程序的协议。

  • SASL = True, TLS = True → SASL_SSL
  • SASL = False, TLS = True → SSL
  • SASL = True, TLS = False → SASL_PLAINTEXT
  • SASL = False, TLS = False → PLAINTEXT
12.2.10.1. listenerConfig

使用 监听程序Config 指定的监听程序配置以 listener .name 前缀。<listener_name>-<port>.例如,sasl.enabled.mechanisms 变为 listener.name。<listener_name>-<port&gt; .sasl.enabled.mechanisms.

12.2.10.2. secrets

secret 挂载到 /opt/kafka/custom-authn-secrets/custom-listener- <listener_name>-<port&gt; / <secret_name > 中。

例如,示例配置中的挂载 secret (示例)位于 /opt/kafka/custom-authn-secrets/custom-listener-oauth-bespoke-9093/example

12.2.10.3. 主体构建器

您可以在 Kafka 集群配置中设置自定义主体构建器。但是,主体构建器有以下要求:

  • 镜像上必须存在指定的主体构建器类。在构建您自己的 之前,请检查是否已存在。您需要使用所需类重建 AMQ Streams 镜像。
  • 没有其他监听程序使用 oauth 类型验证。这是因为 OAuth 侦听器将自己的原则构建器附加到 Kafka 配置中。
  • 指定主体构建器与 AMQ Streams 兼容。

自定义主体构建器必须支持对等证书进行身份验证,因为 AMQ Streams 使用它们来管理 Kafka 集群。

注意

Kafka 的默认主体构建器类 支持根据对等证书的名称来构建主体。自定义主体构建器应使用 SSL peer 证书的名称提供类型为 用户的 主体。

以下示例显示了满足 AMQ Streams 的 OAuth 要求的自定义主体构建器。

自定义 OAuth 配置的主要构建器示例

public final class CustomKafkaPrincipalBuilder implements KafkaPrincipalBuilder {

    public KafkaPrincipalBuilder() {}

    @Override
    public KafkaPrincipal build(AuthenticationContext context) {
        if (context instanceof SslAuthenticationContext) {
            SSLSession sslSession = ((SslAuthenticationContext) context).session();
            try {
                return new KafkaPrincipal(
                    KafkaPrincipal.USER_TYPE, sslSession.getPeerPrincipal().getName());
            } catch (SSLPeerUnverifiedException e) {
                throw new IllegalArgumentException("Cannot use an unverified peer for authentication", e);
            }
        }

        // Create your own KafkaPrincipal here
        ...
    }
}

12.2.10.4. KafkaListenerAuthenticationCustom schema 属性

type 属性是一种差异性,用于区分 KafkaListenerAuthenticationCustom 类型来自 KafkaListenerAuthenticationTlsKafkaListenerAuthenticationScramSha512KafkaListenerAuthenticationOAuth。它必须 自定义 类型为 KafkaListenerAuthenticationCustom

属性Description

listenerConfig

用于特定侦听器的配置。所有值的前缀为 listener.name。<listener_name>

map

SASL

在此侦听器上启用或禁用 SASL。

布尔值

secrets

要挂载到 /opt/kafka/custom-authn-secrets/custom-listener- <listener_name>-<port> / <secret_name > 的 secret。

GenericSecretSource 数组

type

必须为 自定义

字符串

12.2.11. GenericKafkaListenerConfiguration 模式参考

使用的: GenericKafkaListener

GenericKafkaListenerConfiguration schema 属性的完整列表

配置 Kafka 侦听程序。

12.2.11.1. brokerCertChainAndKey

brokerCertChainAndKey 属性仅用于启用了 TLS 加密的监听程序。您可以使用 属性来提供自己的 Kafka 侦听器证书。

启用 TLS 加密的 负载均衡器外部监听程序配置示例

listeners:
  #...
  - name: external
    port: 9094
    type: loadbalancer
    tls: true
    authentication:
      type: tls
    configuration:
      brokerCertChainAndKey:
        secretName: my-secret
        certificate: my-listener-certificate.crt
        key: my-listener-key.key
# ...

12.2.11.2. externalTrafficPolicy

externalTrafficPolicy 属性用于 loadbalancernodeport 侦听程序。在 OpenShift 外部公开 Kafka 时,您可以选择 LocalCluster本地 避免了对其他节点的跃点,并保留客户端 IP,而 群集 则不行。默认为 Cluster

12.2.11.3. loadBalancerSourceRanges

loadBalancerSourceRanges 属性只用于负载均衡器 的监听程序。在 OpenShift 之外公开 Kafka 时,除了使用源范围外,除了标签和注解外,还要自定义创建服务的方式。

为负载均衡器监听器配置的源范围示例

listeners:
  #...
  - name: external
    port: 9094
    type: loadbalancer
    tls: false
    configuration:
      externalTrafficPolicy: Local
      loadBalancerSourceRanges:
        - 10.0.0.0/8
        - 88.208.76.87/32
      # ...
# ...

12.2.11.4. 

class 属性仅适用于 入口 监听程序。您可以使用类属性配置 Ingress

使用 Ingressnginx-internal类型为 ingress 的外部监听程序示例

listeners:
  #...
  - name: external
    port: 9094
    type: ingress
    tls: true
    configuration:
      class: nginx-internal
    # ...
# ...

12.2.11.5. preferredNodePortAddressType

preferredNodePortAddressType 属性仅适用于 nodeport 侦听程序。

使用监听器配置中的 preferredNodePortAddressType 属性来指定检查的第一个地址类型作为节点地址。例如,如果部署不支持 DNS,或者您只想通过内部 DNS 或 IP 地址公开代理,则此属性很有用。如果找到此类型的地址,则会使用它。如果没有找到首选地址类型,AMQ Streams 以标准优先级顺序进行操作:

  1. ExternalDNS
  2. ExternalIP
  3. Hostname
  4. InternalDNS
  5. InternalIP

使用首选节点端口地址类型配置的外部监听程序示例

listeners:
  #...
  - name: external
    port: 9094
    type: nodeport
    tls: false
    configuration:
      preferredNodePortAddressType: InternalDNS
      # ...
# ...

12.2.11.6. useServiceDnsDomain

useServiceDnsDomain 属性仅与 内部 监听器一起使用。它定义包括集群服务后缀(通常为 .cluster.local)的完全限定的 DNS 名称。将 useServiceDnsDomain 设置为 false 时,会在没有服务后缀的情况下生成广播地址;例如,my-cluster-kafka-0.my-cluster-kafka-brokers.myproject.svc。使用 useServiceDnsDomain 设置为 true,则公告的地址随服务后缀生成;例如,my-cluster-kafka-0.my-cluster-kafka-brokers.myproject.svc.cluster.local。默认为 false

配置为使用 Service DNS 域的内部监听程序示例

listeners:
  #...
  - name: plain
    port: 9092
    type: internal
    tls: false
    configuration:
      useServiceDnsDomain: true
      # ...
# ...

如果您的 OpenShift 集群使用不同于 .cluster.local 的不同服务后缀,您可以使用 Cluster Operator 配置中的 KUBERNETES_SERVICE_DNS_DOMAIN 环境变量配置后缀。详情请查看 第 6.2.1 节 “Cluster Operator 配置”

12.2.11.7. GenericKafkaListenerConfiguration schema 属性
属性Description

brokerCertChainAndKey

引用存放用于此侦听器的证书和私钥对的 Secret。证书可选择性地包含整个链。此字段只能与启用了 TLS 加密的监听程序一起使用。

CertAndKeySecretSource

externalTrafficPolicy

指定服务是否将外部流量路由到节点本地或集群范围端点。集群 可能会导致第二个跃点进入另一个节点,并导致客户端源 IP。本地 避免对 LoadBalancer 和 Nodeport 类型服务的第二个跃点,并保留客户端源 IP (当基础架构支持时)。如果未指定,OpenShift 将使用 Cluster 作为 default.This 字段,只能用于 loadbalancernodeport 类型监听程序。

字符串([本地、Cluster] 之一)

loadBalancerSourceRanges

CIDR 范围列表(例如 10.0.0.0/8130.211.204.1/32),客户端可以连接到负载均衡器类型监听程序。如果平台支持,则通过 loadbalancer 的流量仅限于指定的 CIDR 范围。此字段仅适用于负载平衡器类型服务,如果云提供商不支持该功能,则忽略。此字段只能用于 loadbalancer 类型监听程序。

字符串数组

bootstrap

Bootstrap 配置。

GenericKafkaListenerConfigurationBootstrap

代理(broker)

按代理配置.

GenericKafkaListenerConfigurationBroker 数组

ipFamilyPolicy

指定服务使用的 IP 系列策略。可用选项包括 SingleStackPreferDualStackRequireDualStackSingleStack 用于单个 IP 系列。PreferDualStack 是双堆栈配置集群或单堆栈集群上的一个 IP 系列的两个 IP 系列。RequireDualStack 会失败,除非在配置双栈的集群中有两个 IP 系列。如果未指定,OpenShift 将根据服务类型选择默认值。包括在 OpenShift 1.20 及更新的版本中。

字符串(一个 [RequireDualStack,SingleStack,PreferDualStack])

ipFamilies

指定服务使用的 IP Families。可用的选项有 IPv4IPv6。若未指定,OpenShift 将基于 'ipFamilyPolicy 设置选择默认值。包括在 OpenShift 1.20 及更新的版本中。

字符串(一个或多个 [IPv6, IPv4])数组

createBootstrapService

是否要创建 bootstrap 服务。默认情况下创建 bootstrap 服务(如果未指定),则默认创建。此字段可用于 loadBalancer 类型监听程序。

布尔值

配置定义将要使用的 Ingress 控制器的 Ingress 类。此字段只能用于 入口 类型监听程序。如果没有指定,将使用默认 Ingress 控制器。

字符串

终结器

为为这个监听器创建的 LoadBalancer 类型服务配置的终结器列表。如果平台支持,finalizer service.kubernetes.io/load-balancer-cleanup,以确保将外部负载均衡器与服务一起删除。如需更多信息,请参阅 https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/#garbage-collecting-load-balancers。此字段只能用于 loadbalancer 类型监听程序。

字符串数组

maxConnectionCreationRate

在任何时候,我们在此侦听器中允许的最大连接创建率。如果达到限制,则会减慢新连接。

整数

maxConnections

您可以随时在代理中允许此监听程序的最大连接数。如果达到限制,新连接会被阻止。

整数

preferredNodePortAddressType

定义应将哪个地址类型用作节点地址。可用类型有: ExternalDNSExternalIPInternalDNSInternalIPHostname。默认情况下,将按以下顺序使用地址(将使用第一个地址):

  • ExternalDNS
  • ExternalIP
  • InternalDNS
  • InternalIP
  • Hostname

此字段用于选择首选地址类型,首先检查该类型。如果没有找到这个地址类型的地址,则按默认顺序检查其他类型。此字段只能与 nodeport 类型监听程序一起使用。

字符串(一个 [ExternalDNS, ExternalIP, Hostname, InternalIP, InternalDNS])

useServiceDnsDomain

配置是否应使用 OpenShift 服务 DNS 域。如果设置为 true,则生成的地址将包含服务 DNS 域后缀(默认为 .cluster.local,可以使用环境变量 KUBERNETES_SERVICE_DNS_DOMAIN)进行配置。默认值为 false。此字段只能用于 内部 类型监听程序。

布尔值

12.2.12. CertAndKeySecretSource 模式参考

使用的: GenericKafkaListenerConfigurationKafkaClientAuthenticationTls

属性Description

certificate

Secret 中文件证书的名称。

字符串

key

Secret 中私钥的名称。

字符串

secretName

包含证书的 Secret 的名称。

字符串

12.2.13. GenericKafkaListenerConfigurationBootstrap 模式参考

使用的: GenericKafkaListenerConfiguration

GenericKafkaListenerConfigurationBootstrap schema 属性的完整列表

nodePort, host, loadBalancerIPannotations 属性相应的代理服务在 GenericKafkaListenerConfigurationBroker schema 中配置。

12.2.13.1. alternativeNames

您可以为 bootstrap 服务指定备选名称。名称添加到代理证书中,并可用于 TLS 主机名验证。alternativeNames 属性适用于所有类型的监听程序。

使用额外 bootstrap 地址配置的 外部路由 监听程序示例

listeners:
  #...
  - name: external
    port: 9094
    type: route
    tls: true
    authentication:
      type: tls
    configuration:
      bootstrap:
        alternativeNames:
          - example.hostname1
          - example.hostname2
# ...

12.2.13.2. 主机

host 属性用于 routeingress 监听程序,以指定 bootstrap 和 per-broker 服务使用的主机名。

主机 属性值对于 入口 监听器配置是必需的,因为 Ingress 控制器不会自动分配任何主机名。确保主机名解析为 Ingress 端点。AMQ Streams 将不会执行请求的主机可用的验证,并正确路由到 Ingress 端点。

入口监听器的主机配置示例

listeners:
  #...
  - name: external
    port: 9094
    type: ingress
    tls: true
    authentication:
      type: tls
    configuration:
      bootstrap:
        host: bootstrap.myingress.com
      brokers:
      - broker: 0
        host: broker-0.myingress.com
      - broker: 1
        host: broker-1.myingress.com
      - broker: 2
        host: broker-2.myingress.com
# ...

默认情况下,路由 监听程序主机由 OpenShift 自动分配。但是,您可以通过指定主机来覆盖分配的路由主机。

AMQ Streams 不执行请求主机可用的验证。您必须保证它们可用,且可以使用。

路由监听程序的主机配置示例

# ...
listeners:
  #...
  - name: external
    port: 9094
    type: route
    tls: true
    authentication:
      type: tls
    configuration:
      bootstrap:
        host: bootstrap.myrouter.com
      brokers:
      - broker: 0
        host: broker-0.myrouter.com
      - broker: 1
        host: broker-1.myrouter.com
      - broker: 2
        host: broker-2.myrouter.com
# ...

12.2.13.3. nodePort

默认情况下,OpenShift 会自动分配用于 bootstrap 和 broker 服务的端口号。您可以通过指定请求的端口号来覆盖为 节点端口 监听的节点端口。

AMQ Streams 在请求的端口上执行任何验证。您必须保证它们可用,且可以使用。

为节点端口配置覆盖的外部监听程序示例

# ...
listeners:
  #...
  - name: external
    port: 9094
    type: nodeport
    tls: true
    authentication:
      type: tls
    configuration:
      bootstrap:
        nodePort: 32100
      brokers:
      - broker: 0
        nodePort: 32000
      - broker: 1
        nodePort: 32001
      - broker: 2
        nodePort: 32002
# ...

12.2.13.4. loadBalancerIP

在创建负载平衡器时,使用 loadBalancerIP 属性来请求特定的 IP 地址。当您需要使用带有特定 IP 地址的负载均衡器时,请使用此属性。如果云供应商不支持该功能,则会忽略 loadBalancerIP 字段。

带有特定负载均衡器 IP 地址请求的 loadbalancer 类型的外部监听程序示例

# ...
listeners:
  #...
  - name: external
    port: 9094
    type: loadbalancer
    tls: true
    authentication:
      type: tls
    configuration:
      bootstrap:
        loadBalancerIP: 172.29.3.10
      brokers:
      - broker: 0
        loadBalancerIP: 172.29.3.1
      - broker: 1
        loadBalancerIP: 172.29.3.2
      - broker: 2
        loadBalancerIP: 172.29.3.3
# ...

12.2.13.5. annotations

使用 annotations 属性向与监听程序相关的 OpenShift 资源添加注解。例如,您可以使用这些注解来检测 DNS 工具,如 外部 DNS,这将自动为负载均衡器服务分配 DNS 名称。

类型为 loadbalancer 的使用 annotations 的一个外部监听程序的示例。

# ...
listeners:
  #...
  - name: external
    port: 9094
    type: loadbalancer
    tls: true
    authentication:
      type: tls
    configuration:
      bootstrap:
        annotations:
          external-dns.alpha.kubernetes.io/hostname: kafka-bootstrap.mydomain.com.
          external-dns.alpha.kubernetes.io/ttl: "60"
      brokers:
      - broker: 0
        annotations:
          external-dns.alpha.kubernetes.io/hostname: kafka-broker-0.mydomain.com.
          external-dns.alpha.kubernetes.io/ttl: "60"
      - broker: 1
        annotations:
          external-dns.alpha.kubernetes.io/hostname: kafka-broker-1.mydomain.com.
          external-dns.alpha.kubernetes.io/ttl: "60"
      - broker: 2
        annotations:
          external-dns.alpha.kubernetes.io/hostname: kafka-broker-2.mydomain.com.
          external-dns.alpha.kubernetes.io/ttl: "60"
# ...

12.2.13.6. GenericKafkaListenerConfigurationBootstrap schema properties
属性Description

alternativeNames

bootstrap 服务的其他替代名称。其他名称将添加到 TLS 证书的主题备用名称列表中。

字符串数组

主机

bootstrap 主机。此字段将在 Ingress 资源或 Route 资源中使用,以指定所需主机名。此字段只能用于 route (可选)或 ingress (必需)类型监听程序。

字符串

nodePort

bootstrap 服务的节点端口。此字段只能与 nodeport 类型监听程序一起使用。

整数

loadBalancerIP

负载均衡器请求使用此字段中指定的 IP 地址。此功能取决于创建负载均衡器时是否支持指定 loadBalancerIP。如果云供应商不支持 功能,则此字段将被忽略。此字段只能用于 loadbalancer 类型监听程序。

字符串

annotations

将添加到 IngressRouteService 资源中的注解。您可以使用此字段配置 DNS 供应商,如外部 DNS。此字段只能用于 loadbalancernodeportRouteingress 类型监听程序。

map

labels

将添加到 IngressRouteService 资源的标签。此字段只能用于 loadbalancernodeportRouteingress 类型监听程序。

map

12.2.14. GenericKafkaListenerConfigurationBroker 模式参考

使用的: GenericKafkaListenerConfiguration

GenericKafkaListenerConfigurationBroker schema 属性的完整列表

您可以在 GenericKafkaListenerConfigurationBootstrap 模式 中看到 nodePorthostloadBalancerIPannotations 属性配置示例,以配置 bootstrap 服务覆盖。

为代理公告的地址

默认情况下,AMQ Streams 会尝试自动决定 Kafka 集群为其客户端公告的主机名和端口。这在所有情况下都不够,因为运行 AMQ Streams 的基础架构可能无法提供可以访问 Kafka 的适当主机名或端口。

您可以指定代理 ID,并在监听程序的配置属性中自定义公告的主机名和端口。AMQ Streams 会在 Kafka 代理中自动配置广播地址,并将其添加到代理证书中,以便它可用于 TLS 主机名验证。覆盖公告的主机和端口可用于所有类型的监听程序。

为公告的地址配置了覆盖的 外部路由 监听程序示例

listeners:
  #...
  - name: external
    port: 9094
    type: route
    tls: true
    authentication:
      type: tls
    configuration:
      brokers:
      - broker: 0
        advertisedHost: example.hostname.0
        advertisedPort: 12340
      - broker: 1
        advertisedHost: example.hostname.1
        advertisedPort: 12341
      - broker: 2
        advertisedHost: example.hostname.2
        advertisedPort: 12342
# ...

12.2.14.1. GenericKafkaListenerConfigurationBroker schema 属性
属性Description

broker

kafka 代理(broker 标识符)的 ID。代理 ID 从 0 开始,对应于代理副本数。

整数

advertisedHost

代理的 advertised.brokers 中使用的主机名。

字符串

advertisedPort

代理的 advertised.brokers 中使用的端口号。

整数

主机

代理主机。此字段将在 Ingress 资源或 Route 资源中使用,以指定所需主机名。此字段只能用于 route (可选)或 ingress (必需)类型监听程序。

字符串

nodePort

每个broker 服务的节点端口。此字段只能与 nodeport 类型监听程序一起使用。

整数

loadBalancerIP

负载均衡器请求使用此字段中指定的 IP 地址。此功能取决于创建负载均衡器时是否支持指定 loadBalancerIP。如果云供应商不支持 功能,则此字段将被忽略。此字段只能用于 loadbalancer 类型监听程序。

字符串

annotations

将添加到 IngressService 资源中的注解。您可以使用此字段配置 DNS 供应商,如外部 DNS。此字段只能用于 loadbalancernodeportingress 类型监听程序。

map

labels

将添加到 IngressRouteService 资源的标签。此字段只能用于 loadbalancernodeportRouteingress 类型监听程序。

map

12.2.15. EphemeralStorage schema 参考

使用的: JbodStorage, KafkaClusterSpec, ZookeeperClusterSpec

type 属性是一种分ator,用于区分使用 PersistentClaimStorageEphemeralStorage 类型。它必须具有类型为 EphemeralStorage 的值 临时 的值。

属性Description

id

存储识别号.这只适用于在存储类型 'jbod' 中定义的存储卷。

整数

sizeLimit

当 type=ephemeral 时,定义这个 EmptyDir 卷所需的本地存储总量(例如 1Gi)。

字符串

type

必须 是临时的

字符串

12.2.16. PersistentClaimStorage schema 参考

使用的: JbodStorage, KafkaClusterSpec, ZookeeperClusterSpec

type 属性是一个差异性,用于区分使用来自 EphemeralStoragePersistentClaimStorage 类型。它必须具有类型为 PersistentClaimStoragepersistent-claim 值。

属性Description

type

必须为 persistent-claim

字符串

size

当 type=persistent-claim 时,定义持久性卷声明的大小(例如 1Gi)。type=persistent-claim 时必需。

字符串

selector

指定要使用的特定持久性卷。它包含代表选择此类卷的标签的 key:value 对。

map

deleteClaim

指定在集群没有部署时是否必须删除持久性卷声明。

布尔值

用于动态卷分配的存储类。

字符串

id

存储识别号.这只适用于在存储类型 'jbod' 中定义的存储卷。

整数

overrides

覆盖单个代理。overrides 字段允许为不同的代理指定不同的配置。

PersistentClaimStorageOverride 数组

12.2.17. PersistentClaimStorageOverride 模式参考

使用的: PersistentClaimStorage

属性Description

用于这个代理的动态卷分配的存储类。

字符串

broker

kafka 代理(broker 标识符)的 ID。

整数

12.2.18. JbodStorage schema 参考

使用的: KafkaClusterSpec

type 属性是一种分ator,用于区分 JbodStorage 类型与 EphemeralStorage ( PersistentClaimStorage )。它必须具有类型 JbodStorage 的值 jbod

属性Description

type

必须为 jbod

字符串

卷列表作为代表 JBOD 存储阵列的 Storage 对象。

EphemeralStorage, PersistentClaimStorage 数组

12.2.19. KafkaAuthorizationSimple 模式参考

使用的: KafkaClusterSpec

KafkaAuthorizationSimple schema 属性的完整列表

AMQ Streams 中的简单授权使用 AclAuthorizer 插件,即 Apache Kafka 提供的默认访问控制列表(ACL)授权插件。通过 ACL,您可以定义哪些用户有权访问在粒度级别上哪些资源。

Kafka 自定义资源配置为使用简单授权。将 authorization 部分中的 type 属性设置为 simple 的值,并配置超级用户列表。

KafkaUser 配置访问规则,如 ACLRule 模式引用 中所述。

12.2.19.1. 超级用户

用户主体列表被视为超级用户,以便在不查询 ACL 规则的情况下始终允许它们。如需更多信息,请参阅 Kafka 授权

简单的授权配置示例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
  namespace: myproject
spec:
  kafka:
    # ...
    authorization:
      type: simple
      superUsers:
        - CN=client_1
        - user_2
        - CN=client_3
    # ...

注意

Kafka.spec.kafka 中的 config 配置属性中的 super.user 配置选项会被忽略。改为指定 授权 属性中的超级用户。如需更多信息,请参阅 Kafka 代理配置

12.2.19.2. KafkaAuthorizationSimple 模式属性

type 属性是一种差异性,用于区分 KafkaAuthorizationSimple type from KafkaAuthorizationOpa, KafkaAuthorizationKeycloak, KafkaAuthorizationCustom。它必须使 type KafkaAuthorizationSimple 的值 很简单

属性Description

type

必须 非常简单

字符串

superUsers

超级用户列表。应包含用户主体列表,其应获得无限访问权限。

字符串数组

12.2.20. KafkaAuthorizationOpa 模式参考

使用的: KafkaClusterSpec

KafkaAuthorizationOpa schema 属性的完整列表

要使用 Open Policy Agent 授权,将 authorization 部分中的 type 属性设置为 opa 的值,并根据需要配置 OPA 属性。AMQ Streams 将 Open Policy Agent 插件作为授权器使用 Open Policy Agent 插件。有关输入数据和策略示例的更多信息,请参阅 适用于 Kafka 授权的 Open Policy Agent 插件

12.2.20.1. url

用于连接到 Open Policy Agent 服务器的 URL。URL 必须包括由授权器查询的策略。必需。

12.2.20.2. allowOnError

定义在授权器无法查询 Open Policy Agent 时是否应允许或拒绝 Kafka 客户端,例如临时不可用时。默认值为 false - 所有操作都将被拒绝。

12.2.20.3. initialCacheCapacity

授权者用来查询开放策略代理的本地缓存的初始容量,以避免为每个请求查询 Open Policy Agent。默认值为 5000

12.2.20.4. maximumCacheSize

授权者使用的本地缓存的最大容量以避免为每个请求查询 Open Policy Agent。默认为 50000

12.2.20.5. expireAfterMs

记录的过期时间保存在本地缓存中,以避免为每个请求查询 Open Policy Agent。定义从 Open Policy Agent 服务器重新加载缓存的授权决策的频率。以毫秒为单位。默认为 3600000 毫秒(1 小时)。

12.2.20.6. 超级用户

用户主体列表被视为超级用户,以便在不查询开放策略代理策略的情况下始终允许它们。如需更多信息,请参阅 Kafka 授权

Open Policy Agent 授权器配置示例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
  namespace: myproject
spec:
  kafka:
    # ...
    authorization:
      type: opa
      url: http://opa:8181/v1/data/kafka/allow
      allowOnError: false
      initialCacheCapacity: 1000
      maximumCacheSize: 10000
      expireAfterMs: 60000
      superUsers:
        - CN=fred
        - sam
        - CN=edward
    # ...

12.2.20.7. KafkaAuthorizationOpa schema 属性

type 属性是一种差异性,用于区分在 KafkaAuthorizationSimple, KafkaAuthorizationKeycloak, KafkaAuthorizationKeycloak、KafkaAuthorizationCustom 中的 KafkaAuthorizationOpa 类型。对于类型 KafkaAuthorizationOpa,它需要是值 opa

属性Description

type

必须为 opa

字符串

url

用于连接到 Open Policy Agent 服务器的 URL。URL 必须包括由授权器查询的策略。这个选项是必需的。

字符串

allowOnError

定义当授权器无法查询 Open Policy Agent 时(例如,临时不可用)应允许或拒绝 Kafka 客户端。默认值为 false - 所有操作都将被拒绝。

布尔值

initialCacheCapacity

授权者使用的本地缓存的初始容量,以避免为每个请求默认查询 Open Policy Agent 变为 5000

整数

maximumCacheSize

授权者使用的本地缓存的最大容量以避免为每个请求查询 Open Policy Agent。默认为 50000

整数

expireAfterMs

记录的过期时间保存在本地缓存中,以避免为每个请求查询 Open Policy Agent。定义从 Open Policy Agent 服务器重新加载缓存的授权决策的频率。以毫秒为单位。默认为 3600000

整数

superUsers

超级用户列表,特别是具有无限访问权限的用户主体列表。

字符串数组

enableMetrics

定义 Open Policy Agent 授权器插件是否应提供指标。默认值为 false

布尔值

12.2.21. KafkaAuthorizationKeycloak 模式参考

使用的: KafkaClusterSpec

type 属性是一种差异性,用于区分在 KafkaAuthorizationKeycloak 类型中的 KafkaAuthorizationSimple, KafkaAuthorizationOpa, KafkaAuthorizationCustom。对于类型 KafkaAuthorizationKeycloak,它需要有值 keycloak

属性Description

type

必须是 keycloak

字符串

clientId

Kafka 客户端可以用来向 OAuth 服务器进行身份验证并使用令牌端点 URI 的 OAuth 客户端 ID。

字符串

tokenEndpointUri

授权服务器令牌端点 URI。

字符串

tlsTrustedCertificates

TLS 与 OAuth 服务器连接的可信证书。

CertSecretSource 数组

disableTlsHostnameVerification

启用或禁用 TLS 主机名验证。默认值为 false

布尔值

delegateToKafkaAcls

如果红帽单点登录授权服务策略 DENIED,是否应该授权决定为 'Simple' 授权程序。默认值为 false

布尔值

grantsRefreshPeriodSeconds

连续两次授权刷新运行的时间(以秒为单位)。默认值为 60。

整数

grantsRefreshPoolSize

用于刷新活跃会话的线程数量。线程数越多,并行,因此作业完成速度越快。但是,使用更多线程可以在授权服务器上放置负载。默认值为 5。

整数

superUsers

超级用户列表。应包含用户主体列表,其应获得无限访问权限。

字符串数组

connectTimeoutSeconds

连接授权服务器时出现连接超时(以秒为单位)。如果没有设置,则有效连接超时为 60 秒。

整数

readTimeoutSeconds

连接到授权服务器时读取超时(以秒为单位)。如果没有设置,则有效读取超时为 60 秒。

整数

12.2.22. KafkaAuthorizationCustom schema 参考

使用的: KafkaClusterSpec

KafkaAuthorizationCustom schema 属性的完整列表

要在 AMQ Streams 中使用自定义授权,您可以配置自己的 Authorizer 插件来定义访问控制列表(ACL)。

通过 ACL,您可以定义哪些用户有权访问在粒度级别上哪些资源。

Kafka 自定义资源配置为使用自定义授权。将 authorization 部分中的 type 属性设置为 custom 的值,再设置以下属性:

重要

自定义授权器必须实施 org.apache.kafka.server.authorizer.Authorizer 接口,并使用 super.users 配置属性支持 super.users 的配置。

12.2.22.1. authorizerClass

(必需)实现 org.apache.kafka.server.authorizer.Authorizer 接口的 Java 类,以支持自定义 ACL。

12.2.22.2. 超级用户

用户主体列表被视为超级用户,以便在不查询 ACL 规则的情况下始终允许它们。如需更多信息,请参阅 Kafka 授权

您可以使用 Kafka.spec.kafka.config 添加初始化自定义授权器的配置。

Kafka.spec下的自定义授权配置示例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
  namespace: myproject
spec:
  kafka:
    # ...
    authorization:
      type: custom
      authorizerClass: io.mycompany.CustomAuthorizer
      superUsers:
        - CN=client_1
        - user_2
        - CN=client_3
    # ...
    config:
      authorization.custom.property1=value1
      authorization.custom.property2=value2
    # ...

除了 Kafka 自定义资源配置外,包含自定义授权器类及其依赖项的 JAR 文件必须在 Kafka 代理的类路径上可用。

AMQ Streams Maven 构建过程提供了将自定义第三方库添加到生成的 Kafka 代理容器镜像的机制,方法是将它们添加为 docker-images/kafka/kafka-thirdparty-libs 目录中的 pom.xml 文件中的依赖项。目录包含不同 Kafka 版本的不同文件夹。选择相应的文件夹。在修改 pom.xml 文件前,第三方库必须在 Maven 存储库中可用,且 Maven 存储库必须可以被 AMQ Streams 构建过程访问。

注意

Kafka.spec.kafka 中的 config 配置属性中的 super.user 配置选项会被忽略。改为指定 授权 属性中的超级用户。如需更多信息,请参阅 Kafka 代理配置

在使用 oauth 身份验证和配置 groupsClaim 配置属性时,自定义授权可以在身份验证期间使用从 JWT 令牌提取的组成员资格信息。组在 authorize ()调用过程中位于 OAuthKafkaPrincipal 对象上,如下所示:

    public List<AuthorizationResult> authorize(AuthorizableRequestContext requestContext, List<Action> actions) {

        KafkaPrincipal principal = requestContext.principal();
        if (principal instanceof OAuthKafkaPrincipal) {
            OAuthKafkaPrincipal p = (OAuthKafkaPrincipal) principal;

            for (String group: p.getGroups()) {
                System.out.println("Group: " + group);
            }
        }
    }
12.2.22.3. KafkaAuthorizationCustom schema 属性

type 属性是一种差异性,用于区分在 KafkaAuthorizationSimpleKafkaAuthorizationOpaKafkaAuthorizationKeycloak 中使用 KafkaAuthorizationKeycloak 的 KafkaAuthorizationCustom 类型。它必须 自定义 类型为 KafkaAuthorizationCustom 的值。

属性Description

type

必须为 自定义

字符串

authorizerClass

授权实施类必须在 classpath 中提供。

字符串

superUsers

超级用户列表,它们是具有无限访问权限的用户主体。

字符串数组

supportsAdminApi

指明自定义授权器是否支持使用 Kafka Admin API 管理 ACL。默认值为 false

布尔值

12.2.23. 机架 架构参考

使用的: KafkaClusterSpec, KafkaConnectSpec, KafkaMirrorMaker2Spec

Rack schema 属性的完整列表

机架 选项配置机架意识。机架 可以代表一个可用性区域、数据中心或数据中心中的实际机架。机架 通过 topologyKey 配置。topologyKey 标识 OpenShift 节点上的标签,其包含其值中的拓扑名称。这种标签的示例是 topology.kubernetes.io/zone (或较旧 OpenShift 版本的 failure-domain.beta.kubernetes.io/zone ),其中包含 OpenShift 节点运行的可用区的名称。您可以将 Kafka 集群配置为了解其运行的 机架,并启用额外的功能,如在不同机架之间进行分散分区或消耗来自最接近的副本的消息。

如需有关 OpenShift 节点标签的更多信息,请参阅 Well -Known Labels、An Annotations 和 Taints。请查阅 OpenShift 管理员,了解代表部署该节点的区域或机架的节点标签。

12.2.23.1. 在机架之间分散分区副本

配置机架感知后,AMQ Streams 会为每个 Kafka 代理设置 broker.rack 配置。broker.rack 配置为每个代理分配一个机架 ID。配置 broker.rack 时,Kafka 代理将尽可能将分区副本分散到不同的机架中。当副本分散到多个机架时,多个副本可以同时出现故障的概率会低于在同一机架中。分散副本提高了弹性,对于可用性和可靠性至关重要。要在 Kafka 中启用机架感知,请将 rack 选项添加到 Kafka 自定义资源的 .spec.kafka 部分,如下例所示。

Kafka 的 机架 配置示例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    rack:
      topologyKey: topology.kubernetes.io/zone
    # ...

注意

在删除或重启 pod 时,运行代理的 机架 在某些情况下可能会改变。因此,在不同机架中运行的副本可能会共享相同的机架。使用 Cruise Control 和 KafkaRebalance 资源与 RackAwareGoal,以确保副本在不同的机架之间保持分布。

当在 Kafka 自定义资源中启用机架感知时,AMQ Streams 会自动添加 OpenShift preferredDuringSchedulingIgnoredDuringExecution 关联性规则,以在不同的机架之间分发 Kafka 代理。但是,首选 规则不能保证代理会被分散。根据您的 OpenShift 和 Kafka 配置,您应该添加额外的 关联性规则,或为 ZooKeeper 和 Kafka 配置 topologySpreadConstraints,以确保节点尽可能正确分布。更多信息请参阅 第 2.9 节 “配置 pod 调度”

12.2.23.2. 消耗来自最接近的副本的消息

机架意识还可用于消费者从最接近的副本中获取数据。当 Kafka 集群跨越多个数据中心时,这可以降低网络中的负载,并可在公共云中运行 Kafka 时降低成本。但是,这可能会增加延迟。

为了能使用最接近的副本,必须在 Kafka 集群中配置机架意识,并且必须启用 RackAwareReplicaSelector。副本选择器插件提供逻辑,使客户端能够从最接近的副本消耗。默认实现使用 LeaderSelector 来始终为客户端选择领导副本。为 replica.selector.class 指定 RackAwareReplicaSelector 来从默认的实现中切换。

带有启用副本感知选择器的 rack 配置示例

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
    # ...

除了 Kafka 代理配置外,您还需要在消费者中指定 client.rack 选项。client.rack 选项应该指定运行使用者的 机架 IDRackAwareReplicaSelector 关联匹配的 broker.rackclient.rack ID,以查找最接近的副本并使用它。如果同一机架中有多个副本,RackAwareReplicaSelector 始终选择最新的副本。如果没有指定机架 ID,或者找不到具有相同机架 ID 的副本,它将回退到领导副本。

图 12.1. 显示在同一可用区中消耗的副本的客户端示例

消耗同一可用区中的副本

您还可以配置 Kafka Connect 和 MirrorMaker 2.0,以便连接器使用最接近的副本的消息。您可在 KafkaConnectKafkaMirrorMaker2 自定义资源中启用机架意识。该配置不设置关联性规则,但您也可以配置 关联性拓扑 规则。更多信息请参阅 第 2.9 节 “配置 pod 调度”

使用 AMQ Streams 部署 Kafka Connect 时,您可以使用 KafkaConnect 自定义资源中的 rack 部分自动配置 client.rack 选项。

Kafka Connect 的 机架 配置示例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnect
# ...
spec:
  # ...
  rack:
    topologyKey: topology.kubernetes.io/zone
  # ...

使用 AMQ Streams 部署 MirrorMaker 2 时,您可以使用 KafkaMirrorMaker2 自定义资源中的 rack 部分自动配置 client.rack 选项。

MirrorMaker 2.0 的 rack 配置示例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaMirrorMaker2
# ...
spec:
  # ...
  rack:
    topologyKey: topology.kubernetes.io/zone
  # ...

12.2.23.3. 机架 架构属性
属性Description

topologyKey

与分配给 OpenShift 集群节点的标签匹配的键。标签的值用于设置代理的 broker.rack 配置,以及 Kafka Connect 或 MirrorMaker 2.0 的 client.rack 配置。

字符串

12.2.24. 探测 模式参考

使用的: CruiseControlSpec, EntityTopicOperatorSpec, EntityUserOperatorSpec, KafkaBridgeSpec, KafkaClusterSpec, KafkaConnectSpec, KafkaExporterSpec, KafkaMirrorMaker2Spec, KafkaMirrorMakerSpec, TlsSidecar, ZookeeperClusterSpec

属性Description

failureThreshold

在成功后,探测的最小连续故障会被视为失败。默认为 3。最小值为 1。

整数

initialDelaySeconds

第一次检查健康检查前的初始延迟。默认为 15 秒。最小值为 0。

整数

periodSeconds

执行探测的频率(以秒为单位)。默认为 10 秒。最小值为 1。

整数

successThreshold

在失败后,探测的最小连续成功才被视为成功。默认为 1。对于存活度,必须为 1。最小值为 1。

整数

timeoutSeconds

每次尝试健康检查的超时时间。默认为 5 秒。最小值为 1。

整数

12.2.25. JvmOptions 模式参考

使用的: CruiseControlSpec, EntityTopicOperatorSpec, EntityUserOperatorSpec, KafkaBridgeSpec, KafkaConnectSpec, KafkaConnectSpec, KafkaMirrorMaker2Spec, KafkaMirrorMakerSpec, ZookeeperClusterSpec

属性Description

-XX

JVM 的 -XX 选项映射。

map

-Xms

JVM 的 -Xms 选项。

字符串

-Xmx

JVM 的 -Xmx 选项。

字符串

gcLoggingEnabled

指定是否启用 Garbage Collection 日志记录。默认值为 false。

布尔值

javaSystemProperties

使用 -D 选项传递给 JVM 的其他系统属性映射。

SystemProperty 数组

12.2.26. SystemProperty 模式参考

used in: JvmOptions

属性Description

name

系统属性名称。

字符串

value

系统属性值。

字符串

12.2.27. KafkaJmxOptions 模式参考

使用的: KafkaClusterSpec, KafkaConnectSpec, KafkaMirrorMaker2Spec, ZookeeperClusterSpec

KafkaJmxOptions schema 属性的完整列表

配置 JMX 连接选项。

通过连接到端口 9999,从 Kafka 代理、ZooKeeper 节点、Kafka Connect 和 MirrorMaker 2.0. 获取 JMX 指标。使用 jmxOptions 属性配置受密码保护或未受保护的 JMX 端口。使用密码保护可防止未授权的 pod 访问端口。

然后,您可以获取有关组件的指标。

例如,对于每个 Kafka 代理,您可以从客户端获取字节/秒使用量数据,或者代理网络的请求率。

若要为 JMX 端口启用安全性,请将 身份验证 字段中的 type 参数设置为 password

Kafka 代理和 ZooKeeper 节点的受密码保护的 JMX 配置示例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    jmxOptions:
      authentication:
        type: "password"
    # ...
  zookeeper:
    # ...
    jmxOptions:
      authentication:
        type: "password"
    #...

然后,您可以通过指定您要寻址的代理,将 pod 部署到集群中,并使用无头服务获取 JMX 指标。

例如,从代理 0 中获取 JMX 指标,您可以指定:

"CLUSTER-NAME-kafka-0.CLUSTER-NAME-kafka-brokers"

CLUSTER-NAME-kafka-0 是代理 pod 的名称,CLUSTER-NAME-kafka-brokers 是无头服务的名称,以返回代理 pod 的 IP。

如果 JMX 端口设有保护,您可以通过从 Pod 部署中的 JMX Secret 中引用它们来获取用户名和密码。

对于未受保护的 JMX 端口,请使用空对象 {} 打开无头服务的 JMX 端口。您部署 pod 并通过与受保护端口相同的方式获取指标,但在这种情况下,任何 pod 可以从 JMX 端口读取。

Kafka 代理和 ZooKeeper 节点的开放端口 JMX 示例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    jmxOptions: {}
    # ...
  zookeeper:
    # ...
    jmxOptions: {}
    # ...

其他资源

  • 有关使用 JMX 公开的 Kafka 组件指标的更多信息,请参阅 Apache Kafka 文档
12.2.27.1. KafkaJmxOptions 模式属性
属性Description

身份验证

用于连接到 JMX 端口的身份验证配置。类型取决于给定对象中的 authentication.type 属性的值,它必须是 [password] 中的一个。

KafkaJmxAuthenticationPassword

12.2.28. KafkaJmxAuthenticationPassword schema 参考

使用的: KafkaJmxOptions

type 属性是一种分ator,用于区分使用其他子类型中的 KafkaJmxAuthenticationPassword 类型,可在以后添加。对于类型 KafkaJmxAuthenticationPassword,它需要是值 password

属性Description

type

必须为 密码

字符串

12.2.29. JmxPrometheusExporterMetrics 模式参考

使用的: CruiseControlSpec, KafkaClusterSpec, KafkaConnectSpec, KafkaMirrorMaker2Spec, KafkaMirrorMakerSpec, ZookeeperClusterSpec

type 属性是一个差异性符,用于区分来自其他子类型的 JmxPrometheusExporterMetrics 类型,可在以后添加它。对于类型 JmxPrometheusExporterMetrics,它需要有值 jmxPrometheusExporter

属性Description

type

必须为 jmxPrometheusExporter

字符串

valueFrom

存储 Prometheus JMX Exporter 配置的 ConfigMap 条目。有关此配置结构的详情,请查看 Prometheus JMX Exporter

ExternalConfigurationReference

12.2.30. ExternalConfigurationReference 模式参考

使用的: ExternalLoggingJmxPrometheusExporterMetrics

属性Description

configMapKeyRef

对包含配置的 ConfigMap 中的键引用。如需更多信息,请参阅 core/v1 configmapkeyselector 的外部文档

ConfigMapKeySelector

12.2.31. InlineLogging 模式参考

使用的: CruiseControlSpec, EntityTopicOperatorSpec, EntityUserOperatorSpec, KafkaBridgeSpec, KafkaConnectSpec, KafkaConnectSpec, KafkaMirrorMaker2Spec, KafkaMirrorMakerSpec, ZookeeperClusterSpec

type 属性是一种分辨符,用于区分来自 ExternalLoggingInlineLogging 类型。它必须具有类型为 InlineLogging 的值 内联 值。

属性Description

type

必须是 inline

字符串

日志记录器

从日志记录器名称到日志记录器级别的映射。

map

12.2.32. ExternalLogging 模式参考

使用的: CruiseControlSpec, EntityTopicOperatorSpec, EntityUserOperatorSpec, KafkaBridgeSpec, KafkaConnectSpec, KafkaConnectSpec, KafkaMirrorMaker2Spec, KafkaMirrorMakerSpec, ZookeeperClusterSpec

type 属性是一种分辨符,用于区分来自 InlineLoggingExternalLogging 类型。对于类型 ExternalLogging,它需要的值是 external

属性Description

type

必须是 外部

字符串

valueFrom

存储日志记录配置的 ConfigMap 条目。

ExternalConfigurationReference

12.2.33. KafkaClusterTemplate 模式参考

使用的: KafkaClusterSpec

属性Description

statefulset

Kafka StatefulSet 的模板。

StatefulSetTemplate

Pod

Kafka Pod 模板。

PodTemplate

bootstrapService

Kafka bootstrap Service 的模板。

InternalServiceTemplate

brokersService

Kafka 代理服务 的模板

InternalServiceTemplate

externalBootstrapService

Kafka 外部 bootstrap Service 模板。

resourcetemplate

perPodService

用于 OpenShift 外部的 Kafka 每个 pod 服务 模板。

resourcetemplate

externalBootstrapRoute

Kafka 外部 bootstrap 路由的模板

resourcetemplate

perPodRoute

用于从 OpenShift 外部访问的 Kafka 每个 pod 路由 模板。

resourcetemplate

externalBootstrapIngress

Kafka 外部 bootstrap Ingress 模板。

resourcetemplate

perPodIngress

用于从 OpenShift 外部访问的 Kafka 每个 pod 入口 模板。

resourcetemplate

persistentVolumeClaim

所有 Kafka PersistentVolumeClaim 的模板

resourcetemplate

podDisruptionBudget

Kafka PodDisruptionBudget 模板。

PodDisruptionBudgetTemplate

kafkaContainer

Kafka 代理容器的模板。

ContainerTemplate

initContainer

Kafka init 容器的模板。

ContainerTemplate

clusterCaCert

带有 Kafka 集群证书公钥的 Secret 模板。

resourcetemplate

serviceAccount

Kafka 服务帐户的模板。

resourcetemplate

jmxSecret

Kafka 集群 JMX 身份验证的 Secret 模板。

resourcetemplate

clusterRoleBinding

Kafka ClusterRoleBinding 的模板。

resourcetemplate

podSet

Kafka StrimziPodSet 资源的模板。

resourcetemplate

12.2.34. StatefulSetTemplate 模式参考

使用的: KafkaClusterTemplate, ZookeeperClusterTemplate

属性Description

metadata

应用到资源的元数据。

MetadataTemplate

podManagementPolicy

PodManagementPolicy,用于此 StatefulSet。有效值为 ParallelOrderedReady。默认为 Parallel

string (one of [OrderedReady, Parallel])

12.2.35. MetadataTemplate 模式参考

使用的: BuildConfigTemplateDeploymentTemplateInternalServiceTemplatePodDisruptionBudgetTemplatePodTemplateResourceTemplate、StatefulTemplate、StatefulTemplate

完整 元数据模板 模式属性列表

LabelsAnnotations 用于识别和组织资源,并在 metadata 属性中配置。

例如:

# ...
template:
  pod:
    metadata:
      labels:
        label1: value1
        label2: value2
      annotations:
        annotation1: value1
        annotation2: value2
# ...

labelsannotations 字段可以包含没有保留字符串 strimzi.io 的任何标签或注解。包含 strimzi.io 的标签和注解由 AMQ Streams 内部使用,且无法配置。

12.2.35.1. 元数据模板 架构属性
属性Description

labels

添加到资源模板的标签。可以应用到不同的资源,如 StatefulSetsDeploymentPodServices

map

annotations

添加到资源模板中的注解。可以应用到不同的资源,如 StatefulSetsDeploymentPodServices

map

12.2.36. PodTemplate 模式参考

用于:CruiseControlTemplate, EntityOperatorTemplate, KafkaBridgeTemplate, KafkaClusterTemplate, KafkaConnectTemplate, KafkaExporterTemplate, KafkaMirrorMakerTemplate, ZookeeperClusterTemplate

PodTemplate 模式属性的完整列表

配置 Kafka pod 模板。

PodTemplate 配置示例

# ...
template:
  pod:
    metadata:
      labels:
        label1: value1
      annotations:
        anno1: value1
    imagePullSecrets:
      - name: my-docker-credentials
    securityContext:
      runAsUser: 1000001
      fsGroup: 0
    terminationGracePeriodSeconds: 120
# ...

12.2.36.1. hostAliases

使用 hostAliases 属性来指定主机和 IP 地址列表,这些地址被注入到 pod 的 /etc/hosts 文件中。

当用户也请求集群外的连接时,这个配置对 Kafka Connect 或 MirrorMaker 特别有用。

hostAliases 配置示例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnect
#...
spec:
  # ...
  template:
    pod:
      hostAliases:
      - ip: "192.168.1.86"
        hostnames:
        - "my-host-1"
        - "my-host-2"
      #...

12.2.36.2. PodTemplate 模式属性
属性Description

metadata

应用到资源的元数据。

MetadataTemplate

imagePullSecrets

对同一命名空间中的 secret 的引用列表,用于拉取此 Pod 使用的任何镜像。当指定 Cluster Operator 中的 STRIMZI_IMAGE_PULL_SECRETS 环境变量和 imagePullSecrets 选项时,只使用 imagePullSecrets 变量,并将忽略 STRIMZI_IMAGE_PULL_SECRETS 变量。如需更多信息,请参阅 core/v1 localobjectreference 的外部文档

LocalObjectReference 数组

securityContext

配置 pod 级别的安全属性和通用容器设置。如需更多信息,请参阅 core/v1 podsecuritycontext 的外部文档

PodSecurityContext

terminationGracePeriodSeconds

宽限期是 Pod 中运行的进程发送终止信号后的持续时间(以秒为单位),以及进程被强制停止的时间(使用 kill 信号)。将这个值设置为比您的进程预期的清理时间长。值必须是非负的整数。零值表示立即删除。您可能需要为非常大的 Kafka 集群增加宽限期,以便 Kafka 代理有足够的时间将其工作传输至另一个代理,然后再被终止。默认为 30 秒。

整数

关联性

pod 的关联性规则。如需更多信息,请参阅 core/v1 关联性的外部文档

关联性

容限(tolerations)

pod 的容限。如需更多信息,请参阅 core/v1 容限的外部文档

容限 数组

priorityClassName

用于为 pod 分配优先级的优先级类的名称。有关优先级类的更多信息,请参阅 Pod 优先级和抢占

字符串

schedulerName

用于分配此 Pod 的调度程序的名称。如果没有指定,将使用默认调度程序。

字符串

hostAliases

pod 的 HostAliases。hostAliases 是主机和 IP 的可选列表,在指定时将注入到 Pod 的主机文件中。如需更多信息,请参阅 core/v1 hostalias 的外部文档

HostAlias 数组

tmpDirSizeLimit

定义临时 EmptyDir 卷(/tmp)所需的本地存储总量(例如 1Gi)。默认值为 5Mi

字符串

enableServiceLinks

指明有关服务的信息是否应该注入到 Pod 的环境变量中。

布尔值

topologySpreadConstraints

pod 的拓扑分布限制。如需更多信息,请参阅 core/v1 topologyspreadconstraint 的外部文档

TopologySpreadConstraint 数组

12.2.37. InternalServiceTemplate 模式参考

使用的: CruiseControlTemplate, KafkaBridgeTemplate, KafkaClusterTemplate, KafkaConnectTemplate, ZookeeperClusterTemplate

属性Description

metadata

应用到资源的元数据。

MetadataTemplate

ipFamilyPolicy

指定服务使用的 IP 系列策略。可用选项包括 SingleStackPreferDualStackRequireDualStackSingleStack 用于单个 IP 系列。PreferDualStack 是双堆栈配置集群或单堆栈集群上的一个 IP 系列的两个 IP 系列。RequireDualStack 会失败,除非在配置双栈的集群中有两个 IP 系列。如果未指定,OpenShift 将根据服务类型选择默认值。包括在 OpenShift 1.20 及更新的版本中。

字符串(一个 [RequireDualStack,SingleStack,PreferDualStack])

ipFamilies

指定服务使用的 IP Families。可用的选项有 IPv4IPv6。若未指定,OpenShift 将基于 'ipFamilyPolicy 设置选择默认值。包括在 OpenShift 1.20 及更新的版本中。

字符串(一个或多个 [IPv6, IPv4])数组

12.2.38. resourcetemplate 模式参考

用于:CruiseControlTemplate, EntityOperatorTemplate, KafkaBridgeTemplate, KafkaClusterTemplate, KafkaConnectTemplate, KafkaExporterTemplate, KafkaMirrorMakerTemplate, KafkaUserTemplate, ZookeeperClusterTemplate

属性Description

metadata

应用到资源的元数据。

MetadataTemplate

12.2.39. PodDisruptionBudgetTemplate 模式参考

使用的: CruiseControlTemplate, KafkaBridgeTemplate, KafkaClusterTemplate, KafkaConnectTemplate, KafkaMirrorMakerTemplate, ZookeeperClusterTemplate

PodDisruptionBudgetTemplate 模式属性的完整列表

AMQ Streams 为每个新的 StatefulSetDeployment 创建一个 PodDisruptionBudget。默认情况下,pod 中断预算只允许一个 pod 在给定时间不可用。您可以通过更改 maxUnavailable 属性的默认值来增加允许的不可用 pod 量。

PodDisruptionBudget 模板示例

# ...
template:
  podDisruptionBudget:
    metadata:
      labels:
        key1: label1
        key2: label2
      annotations:
        key1: label1
        key2: label2
    maxUnavailable: 1
# ...

12.2.39.1. PodDisruptionBudgetTemplate 模式属性
属性Description

metadata

应用到 PodDisruptionBudgetTemplate 资源的元数据。

MetadataTemplate

maxUnavailable

允许自动 pod 驱除的最大不可用 pod 数量。当 maxUnavailable 数量的 pod 或更少的 pod 在驱除后不可用时,允许 pod 驱除。将此值设置为 0 可防止所有自愿驱除,因此必须手动驱除 pod。默认为 1。

整数

12.2.40. ContainerTemplate 模式参考

用于:CruiseControlTemplate, EntityOperatorTemplate, KafkaBridgeTemplate, KafkaClusterTemplate, KafkaConnectTemplate, KafkaExporterTemplate, KafkaMirrorMakerTemplate, ZookeeperClusterTemplate

ContainerTemplate 模式属性的完整列表

您可以为容器设置自定义安全上下文和环境变量。

环境变量在 env 属性下定义为带有 namevalue 字段的对象列表。以下示例显示了为 Kafka 代理容器设置的两个自定义环境变量和自定义安全上下文:

# ...
template:
  kafkaContainer:
    env:
    - name: EXAMPLE_ENV_1
      value: example.env.one
    - name: EXAMPLE_ENV_2
      value: example.env.two
    securityContext:
      runAsUser: 2000
# ...

前缀为 KAFKA_ 的环境变量是 AMQ Streams 的内部,应该避免。如果您设置了AMQ Streams 已使用的自定义环境变量,它会被忽略,并在日志中记录警告信息。

12.2.40.1. ContainerTemplate 模式属性
属性Description

env

应该应用到容器的环境变量。

ContainerEnvVar 数组

securityContext

容器的安全上下文。如需更多信息,请参阅 core/v1 安全上下文的外部文档

securityContext

12.2.41. ContainerEnvVar 模式参考

used in: ContainerTemplate

属性Description

name

环境变量键。

字符串

value

环境变量值。

字符串

12.2.42. ZookeeperClusterSpec 模式参考

使用的: KafkaSpec

ZookeeperClusterSpec schema 属性的完整列表

配置 ZooKeeper 集群。

12.2.42.1. config

使用 config 属性将 ZooKeeper 选项配置为键。

可以提供标准 Apache ZooKeeper 配置,仅限于不直接由 AMQ Streams 管理的属性。

无法配置与以下内容相关的配置选项:

  • 安全(加密、验证和授权)
  • 侦听器配置
  • 配置数据目录
  • zookeeper 集群组成

这些值可以是以下 JSON 类型之一:

  • 字符串
  • Number
  • 布尔值

您可以指定并配置 ZooKeeper 文档 中列出的选项,但那些直接由 AMQ Streams 管理的选项除外。具体来说,所有与以下字符串之一相等或开始的配置选项都会被禁止:

  • 服务器.
  • dataDir
  • dataLogDir
  • clientPort
  • authProvider
  • quorum.auth
  • requireClientAuthScheme

当在 config 属性中存在禁止选项时,它会被忽略,并将警告消息输出到 Cluster Operator 日志文件。所有其他支持选项都传递到 ZooKeeper。

禁止的选项有例外。对于将特定 密码套件 用于 TLS 版本的客户端连接,您可以配置允许的 ssl 属性

ZooKeeper 配置示例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
spec:
  kafka:
    # ...
  zookeeper:
    # ...
    config:
      autopurge.snapRetainCount: 3
      autopurge.purgeInterval: 1
      ssl.cipher.suites: "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384"
      ssl.enabled.protocols: "TLSv1.2"
      ssl.protocol: "TLSv1.2"
    # ...

12.2.42.2. logging

zookeeper 有一个可配置的日志记录器:

  • zookeeper.root.logger

zookeeper 使用 Apache log4j 日志记录器实现。

使用 logging 属性配置日志记录器和日志记录器级别。

您可以通过直接指定日志记录器和级别(在线)或使用自定义(外部) ConfigMap 来设置日志级别。如果使用 ConfigMap,您可以将 logging.valueFrom.configMapKeyRef.name 属性设置为包含外部日志记录配置的 ConfigMap 的名称。在 ConfigMap 中,日志记录配置使用 log4j.properties 来描述。logging.valueFrom.configMapKeyRef.namelogging.valueFrom.configMapKeyRef.key 属性都是必须的。当 Cluster Operator 运行时,会使用指定的日志记录配置创建 ConfigMap,然后在每次协调后重新创建。如果没有指定自定义 ConfigMap,则会使用默认的日志记录设置。如果没有设置特定的日志记录器值,则会继承该日志记录器的上级日志记录器设置。有关日志级别的更多信息,请参阅 Apache 日志记录服务

此处会看到 内联外部日志记录 的示例。

内联日志

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
spec:
  # ...
  zookeeper:
    # ...
    logging:
      type: inline
      loggers:
        zookeeper.root.logger: "INFO"
    # ...

外部日志记录

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
spec:
  # ...
  zookeeper:
    # ...
    logging:
      type: external
      valueFrom:
        configMapKeyRef:
          name: customConfigMap
          key: zookeeper-log4j.properties
  # ...

垃圾收集器(GC)

也可以使用 jvmOptions 属性 来启用(或禁用)垃圾收集器日志记录。

12.2.42.3. ZookeeperClusterSpec schema 属性
属性Description

replicas

集群中的 pod 数量。

整数

image

pod 的 docker 镜像。

字符串

storage

存储配置(磁盘)。无法更新。类型取决于给定对象中的 storage.type 属性的值,它必须是 [ephemeral, persistent-claim] 中的一个。

EphemeralStorage, PersistentClaimStorage

config

ZooKeeper 代理配置。无法设置以下前缀的属性:server.、dataDir、dataLogDir、clientPort、authProvider、quorum.auth、serverCnxnFactoreme、snapshot.trust.empty、standaloneEnabled、reconfigEnabled、seconfigEnabled、4lw.commands.whitelist、secureClientPort、ssl.、serverCnxnFactory、sslQuorum (Iprotocol 除外) SSL.quorum.protocol, ssl.enabledProtocols, ssl.quorum.enabledProtocols, ssl.ciphersuites, ssl.quorum.ciphersuites, ssl.hostnameVerification, ssl.quorum.hostnameVerification)。

map

livenessProbe

Pod 存活度检查。

探测

readinessProbe

Pod 就绪度检查.

探测

jvmOptions

pod 的 JVM 选项。

JvmOptions

jmxOptions

Zookeeper 节点的 JMX 选项.

KafkaJmxOptions

资源

要保留的 CPU 和内存资源。如需更多信息,请参阅 core/v1 资源查询的外部文档

ResourceRequirements

metricsConfig

指标配置。这个类型取决于给定对象中的 metricsConfig.type 属性的值,它必须是 [jmxPrometheusExporter] 之一。

JmxPrometheusExporterMetrics

logging

ZooKeeper 的日志记录配置。类型取决于给定对象中的 logging.type 属性的值,它必须是 [inline, external] 中的一个。

InlineLogging, ExternalLogging

模板

ZooKeeper 集群资源模板。通过该模板,用户可以指定如何生成 StatefulSetPodServices

ZookeeperClusterTemplate

12.2.43. ZookeeperClusterTemplate 模式参考

使用的: ZookeeperClusterSpec

属性Description

statefulset

ZooKeeper StatefulSet 模板。

StatefulSetTemplate

Pod

ZooKeeper Pod 模板.

PodTemplate

clientService

ZooKeeper 客户端服务 模板.

InternalServiceTemplate

nodesService

ZooKeeper 节点服务 模板.

InternalServiceTemplate

persistentVolumeClaim

所有 ZooKeeper PersistentVolumeClaim 的模板

resourcetemplate

podDisruptionBudget

ZooKeeper PodDisruptionBudget 模板。

PodDisruptionBudgetTemplate

zookeeperContainer

ZooKeeper 容器的模板。

ContainerTemplate

serviceAccount

ZooKeeper 服务帐户的模板。

resourcetemplate

jmxSecret

Zookeeper 集群 JMX 身份验证的 Secret 模板。

resourcetemplate

podSet

ZooKeeper StrimziPodSet 资源的模板。

resourcetemplate

12.2.44. EntityOperatorSpec 模式参考

使用的: KafkaSpec

属性Description

topicOperator

配置主题 Operator。

EntityTopicOperatorSpec

userOperator

User Operator 配置。

EntityUserOperatorSpec

tlsSidecar

TLS sidecar 配置。

TlsSidecar

模板

Entity Operator 资源的模板。通过该模板,用户可以指定如何生成 DeploymentPod

EntityOperatorTemplate

12.2.45. EntityTopicOperatorSpec 模式参考

used in: EntityOperatorSpec

EntityTopicOperatorSpec 模式属性的完整列表

配置主题 Operator。

12.2.45.1. logging

主题 Operator 有一个可配置的日志记录器:

  • rootLogger.level

主题 Operator 使用 Apache log4j2 日志记录器实现。

使用 Kafka 资源 Kafka 资源的 entityOperator.topicOperator 字段中的 logging 属性来配置日志记录器和日志记录器级别。

您可以通过直接指定日志记录器和级别(在线)或使用自定义(外部) ConfigMap 来设置日志级别。如果使用 ConfigMap,您可以将 logging.valueFrom.configMapKeyRef.name 属性设置为包含外部日志记录配置的 ConfigMap 的名称。在 ConfigMap 中,日志记录配置使用 log4j2.properties 来描述。logging.valueFrom.configMapKeyRef.namelogging.valueFrom.configMapKeyRef.key 属性都是必须的。当 Cluster Operator 运行时,会使用指定的日志记录配置创建 ConfigMap,然后在每次协调后重新创建。如果没有指定自定义 ConfigMap,则会使用默认的日志记录设置。如果没有设置特定的日志记录器值,则会继承该日志记录器的上级日志记录器设置。有关日志级别的更多信息,请参阅 Apache 日志记录服务

此处会看到 内联外部日志记录 的示例。

内联日志

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
  zookeeper:
    # ...
  entityOperator:
    # ...
    topicOperator:
      watchedNamespace: my-topic-namespace
      reconciliationIntervalSeconds: 60
      logging:
        type: inline
        loggers:
          rootLogger.level: INFO
  # ...

外部日志记录

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
  zookeeper:
    # ...
  entityOperator:
    # ...
    topicOperator:
      watchedNamespace: my-topic-namespace
      reconciliationIntervalSeconds: 60
      logging:
        type: external
        valueFrom:
          configMapKeyRef:
            name: customConfigMap
            key: topic-operator-log4j2.properties
  # ...

垃圾收集器(GC)

也可以使用 jvmOptions 属性 来启用(或禁用)垃圾收集器日志记录。

12.2.45.2. EntityTopicOperatorSpec 模式属性
属性Description

watchedNamespace

应该监视主题 Operator 的命名空间。

字符串

image

用于主题 Operator 的镜像。

字符串

reconciliationIntervalSeconds

定期协调之间的间隔。

整数

zookeeperSessionTimeoutSeconds

ZooKeeper 会话的超时。

整数

startupProbe

Pod 启动检查.

探测

livenessProbe

Pod 存活度检查。

探测

readinessProbe

Pod 就绪度检查.

探测

资源

要保留的 CPU 和内存资源。如需更多信息,请参阅 core/v1 资源查询的外部文档

ResourceRequirements

topicMetadataMaxAttempts

获取主题元数据时的尝试次数。

整数

logging

日志记录配置。类型取决于给定对象中的 logging.type 属性的值,它必须是 [inline, external] 中的一个。

InlineLogging, ExternalLogging

jvmOptions

pod 的 JVM 选项。

JvmOptions

12.2.46. EntityUserOperatorSpec 模式参考

used in: EntityOperatorSpec

EntityUserOperatorSpec schema 属性的完整列表

配置用户 Operator。

12.2.46.1. logging

User Operator 有一个可配置的日志记录器:

  • rootLogger.level

User Operator 使用 Apache log4j2 日志记录器实现。

使用 Kafka 资源的 entityOperator.userOperator 字段中的 logging 属性来配置日志记录器和日志记录器级别。

您可以通过直接指定日志记录器和级别(在线)或使用自定义(外部) ConfigMap 来设置日志级别。如果使用 ConfigMap,您可以将 logging.valueFrom.configMapKeyRef.name 属性设置为包含外部日志记录配置的 ConfigMap 的名称。在 ConfigMap 中,日志记录配置使用 log4j2.properties 来描述。logging.valueFrom.configMapKeyRef.namelogging.valueFrom.configMapKeyRef.key 属性都是必须的。当 Cluster Operator 运行时,会使用指定的日志记录配置创建 ConfigMap,然后在每次协调后重新创建。如果没有指定自定义 ConfigMap,则会使用默认的日志记录设置。如果没有设置特定的日志记录器值,则会继承该日志记录器的上级日志记录器设置。有关日志级别的更多信息,请参阅 Apache 日志记录服务

此处会看到 内联外部日志记录 的示例。

内联日志

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
  zookeeper:
    # ...
  entityOperator:
    # ...
    userOperator:
      watchedNamespace: my-topic-namespace
      reconciliationIntervalSeconds: 60
      logging:
        type: inline
        loggers:
          rootLogger.level: INFO
  # ...

外部日志记录

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
  zookeeper:
    # ...
  entityOperator:
    # ...
    userOperator:
      watchedNamespace: my-topic-namespace
      reconciliationIntervalSeconds: 60
      logging:
        type: external
        valueFrom:
          configMapKeyRef:
            name: customConfigMap
            key: user-operator-log4j2.properties
   # ...

垃圾收集器(GC)

也可以使用 jvmOptions 属性 来启用(或禁用)垃圾收集器日志记录。

12.2.46.2. EntityUserOperatorSpec 模式属性
属性Description

watchedNamespace

User Operator 应该监视的命名空间。

字符串

image

用于 User Operator 的镜像。

字符串

reconciliationIntervalSeconds

定期协调之间的间隔。

整数

zookeeperSessionTimeoutSeconds

zookeeperSessionTimeoutSeconds 属性已弃用。此属性已弃用,因为 User Operator 不再使用 ZooKeeper。ZooKeeper 会话的超时。

整数

secretPrefix

将添加到 KafkaUser 名称的前缀,用作 Secret 名称。

字符串

livenessProbe

Pod 存活度检查。

探测

readinessProbe

Pod 就绪度检查.

探测

资源

要保留的 CPU 和内存资源。如需更多信息,请参阅 core/v1 资源查询的外部文档

ResourceRequirements

logging

日志记录配置。类型取决于给定对象中的 logging.type 属性的值,它必须是 [inline, external] 中的一个。

InlineLogging, ExternalLogging

jvmOptions

pod 的 JVM 选项。

JvmOptions

12.2.47. TlsSidecar 模式参考

使用的: CruiseControlSpec, EntityOperatorSpec

TlsSidecar 模式属性的完整列表

配置 TLS sidecar,这是在 pod 中运行但满足支持目的的容器。在 AMQ Streams 中,TLS sidecar 使用 TLS 来加密和解密组件与 ZooKeeper 之间的通信。

TLS sidecar 在 Entity Operator 中使用。

TLS sidecar 使用 Kafka.spec.entityOperator 中的 tlsSidecar 属性进行配置。

TLS sidecar 支持以下附加选项:

  • image
  • 资源
  • logLevel
  • readinessProbe
  • livenessProbe

resources 属性指定为 TLS sidecar 分配的 内存和 CPU 资源

image 属性配置将使用的容器镜像

readinessProbelivenessProbe 属性为 TLS sidecar 配置 健康检查探测

logLevel 属性指定日志级别。支持以下日志记录级别:

  • emerg
  • alert
  • crit
  • err
  • warning
  • 备注
  • info
  • debug

默认值为 notice

TLS sidecar 配置示例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  # ...
  entityOperator:
    # ...
    tlsSidecar:
      resources:
        requests:
          cpu: 200m
          memory: 64Mi
        limits:
          cpu: 500m
          memory: 128Mi
    # ...

12.2.47.1. TlsSidecar 模式属性
属性Description

image

容器的 Docker 镜像。

字符串

livenessProbe

Pod 存活度检查。

探测

logLevel

TLS sidecar 的日志级别。默认值为 notice

string (one of [emerg, debug, crit, err, alert, warning, notice, info])

readinessProbe

Pod 就绪度检查.

探测

资源

要保留的 CPU 和内存资源。如需更多信息,请参阅 core/v1 资源查询的外部文档

ResourceRequirements

12.2.48. EntityOperatorTemplate 模式参考

used in: EntityOperatorSpec

属性Description

部署

Entity Operator Deployment 的模板。

resourcetemplate

Pod

实体 Operator Pod 的模板

PodTemplate

topicOperatorContainer

Entity Topic Operator 容器的模板。

ContainerTemplate

userOperatorContainer

Entity User Operator 容器的模板。

ContainerTemplate

tlsSidecarContainer

Entity Operator TLS sidecar 容器的模板。

ContainerTemplate

serviceAccount

Entity Operator 服务帐户的模板。

resourcetemplate

12.2.49. certificateAuthority 模式参考

使用的: KafkaSpec

在集群中如何使用 TLS 证书的配置。这适用于用于集群中内部通信的证书,以及通过 Kafka.spec.kafka.listeners.tls 用于访问的证书。

属性Description

generateCertificateAuthority

如果为 true,则会自动生成证书颁发机构证书。否则,用户需要提供 CA 证书的 Secret。默认为 true。

布尔值

generateSecretOwnerReference

如果为 true,Cluster 和客户端 CA Secret 将使用 ownerReference 设置为 Kafka 资源来配置。如果在 true 时删除了 Kafka 资源,则 CA Secret 也会被删除。若为 false,则 ownerReference 被禁用。如果 Kafka 资源在 false 时删除,则 CA Secret 会被保留并可用于重复使用。默认为 true

布尔值

validityDays

生成的证书应有效天数。默认值为 365。

整数

renewalDays

证书续订期间的天数。这是证书过期之前可以执行续订操作的天数。当 generateCertificateAuthority 为 true 时,这将导致新证书的生成。当 generateCertificateAuthority 为 true 时,这会导致额外的日志记录级别在 WARN 级别有关待处理证书过期的情况。默认值为 30。

整数

certificateExpirationPolicy

在生成 CertificateAuthority=true 时,如何处理 CA 证书过期。默认值用于重复使用现有私钥的新 CA 证书。

string (one of [replace-key, renew-certificate])

12.2.50. CruiseControlSpec 模式参考

使用的: KafkaSpec

CruiseControlSpec schema 属性的完整列表

配置一个 Cruise Control 集群。

配置选项与:

  • 目标配置
  • 资源分布目标的容量限制
12.2.50.1. config

使用 配置属性 将控制选项配置为密钥。

可以提供标准 Cruise Control 配置,仅限于不直接由 AMQ Streams 管理的属性。

无法配置与以下内容相关的配置选项:

  • 安全(加密、验证和授权)
  • 连接到 Kafka 集群
  • 客户端 ID 配置
  • zookeeper 连接性
  • Web 服务器配置
  • 自我修复

这些值可以是以下 JSON 类型之一:

  • 字符串
  • Number
  • 布尔值

您可以指定并配置 Cruise Control 文档 中列出的选项,但那些直接由 AMQ Streams 管理的选项除外。如需禁止前缀列表,请参阅 config 属性的描述。

当在 config 属性中存在禁止选项时,它会被忽略,并将警告消息输出到 Cluster Operator 日志文件。所有其他支持选项都传递到 Cruise Control。

禁止的选项有例外。对于将特定 密码套件 用于 TLS 版本的客户端连接,您可以配置允许的 ssl 属性。您还可以配置 webserver 属性,以启用跨资源共享(CORS)。

Cruise Control 配置示例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  # ...
  cruiseControl:
    # ...
    config:
      default.goals: >
        com.linkedin.kafka.cruisecontrol.analyzer.goals.RackAwareGoal,
        com.linkedin.kafka.cruisecontrol.analyzer.goals.ReplicaCapacityGoal
      cpu.balance.threshold: 1.1
      metadata.max.age.ms: 300000
      send.buffer.bytes: 131072
      webserver.http.cors.enabled: true
      webserver.http.cors.origin: "*"
      webserver.http.cors.exposeheaders: "User-Task-ID,Content-Type"
    # ...

12.2.50.2. 跨资源共享(CORS)

跨资源共享(CORS)是控制对 REST API 的访问的 HTTP 机制。限制是指客户端应用的访问方法或原始 URL。您可以使用 config 中的 webserver.http.cors.enabled 属性启用 CORS。启用后,CORS 允许从不同于 AMQ Streams 的应用程序读取对 Cruise Control REST API 的访问。这允许来自指定源中的应用程序通过 Cruise Control API 来使用 GET 请求获取 Kafka 集群的信息。例如,应用程序可以获取当前集群负载或最新优化方案的信息。不允许 POST 请求。

注意

有关使用带有 Cruise Control 的 CORS 的更多信息,请参阅 Cruise Control Wiki 中的 REST API

为 Cruise Control 启用 CORS

您可以在 Kafka.spec.cruiseControl.config 中启用和配置 CORS。

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  # ...
  cruiseControl:
    # ...
    config:
      webserver.http.cors.enabled: true 1
      webserver.http.cors.origin: "*" 2
      webserver.http.cors.exposeheaders: "User-Task-ID,Content-Type" 3

    # ...
1
启用 CORS。
2
Access-Control-Allow-Origin HTTP 响应标头指定允许的来源。您可以使用通配符或指定一个源作为 URL。如果使用通配符,则从任何原始请求返回响应。
3
Access-Control-Expose-Headers HTTP 响应标头公开指定的标头名称。允许的源中的应用程序可以通过指定标头读取响应。
12.2.50.3. Cruise Control REST API 安全性

Cruise Control REST API 使用 HTTP 基本身份验证和 SSL 保护集群,以防止集群出现潜在的 Cruise Control 操作,如弃用 Kafka 代理。我们推荐在 AMQ Streams 中 Cruise Control 用来启用这些设置

但是,可以通过指定以下 Cruise Control 配置来禁用这些设置:

  • 要禁用内置 HTTP 基本身份验证,请将 webserver.security.enable 设置为 false
  • 要禁用内置 SSL,请将 webserver.ssl.enable 设置为 false

Cruise Control 配置来禁用 API 授权、身份验证和 SSL

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  # ...
  cruiseControl:
    config:
      webserver.security.enable: false
      webserver.ssl.enable: false
# ...

12.2.50.4. brokerCapacity

Cruise Control 使用容量限制来确定资源分布的优化目标是否被破坏。这个类型有 4 个目标:

  • DiskUsageDistributionGoal - 磁盘使用分布
  • CpuUsageDistributionGoal - CPU utilization distribution
  • NetworkInboundUsageDistributionGoal - 网络入站利用率分发
  • NetworkOutboundUsageDistributionGoal - 网络出站利用率分发

您可以在 Kafka.spec.cruiseControl 中的 brokerCapacity 属性中指定 Kafka 代理资源的容量限制。它们会被默认启用,您可以更改其默认值。可以为以下代理资源设置容量限制:

  • inboundNetwork - 每秒以字节单位的入站网络吞吐量(默认值:10000KiB/s)
  • outboundNetwork - 出站网络吞吐量,以每秒字节数为单位(默认值:10000KiB/s)

对于网络吞吐量,请使用带有标准 OpenShift 字节单元(K、M、G)或其 bibyte (双字节(Ki, Mi, Gi)的整数值。

注意

磁盘和 CPU 容量限制由 AMQ Streams 自动生成,因此您不需要设置它们。

注意

为了保证使用 CPU 目标时准确重新平衡提议,您可以在 Kafka.spec.kafka.resources 中设置与 CPU 限值相等的 CPU 请求。这样,所有 CPU 资源都会保留前期,并且始终可用。此配置允许 Cruise Control 在准备基于 CPU 目标的重新平衡建议时,正确评估 CPU 利用率。

使用 bibyte 单位的 Cruise Control 代理容量配置示例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  # ...
  cruiseControl:
    # ...
    brokerCapacity:
      inboundNetwork: 10000KiB/s
      outboundNetwork: 10000KiB/s
    # ...

12.2.50.5. 日志记录配置

Cruise Control 有自己的可配置的日志记录器:

  • rootLogger.level

Cruise Control 使用 Apache log4j2 日志记录器实施。

使用 logging 属性配置日志记录器和日志记录器级别。

您可以通过直接指定日志记录器和级别(在线)或使用自定义(外部) ConfigMap 来设置日志级别。如果使用 ConfigMap,您可以将 logging.valueFrom.configMapKeyRef.name 属性设置为包含外部日志记录配置的 ConfigMap 的名称。在 ConfigMap 中,日志记录配置使用 log4j.properties 来描述。logging.valueFrom.configMapKeyRef.namelogging.valueFrom.configMapKeyRef.key 属性都是必须的。当 Cluster Operator 运行时,会使用指定的日志记录配置创建 ConfigMap,然后在每次协调后重新创建。如果没有指定自定义 ConfigMap,则会使用默认的日志记录设置。如果没有设置特定的日志记录器值,则会继承该日志记录器的上级日志记录器设置。此处会看到 内联外部日志记录 的示例。

内联日志

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
# ...
spec:
  cruiseControl:
    # ...
    logging:
      type: inline
      loggers:
        rootLogger.level: "INFO"
    # ...

外部日志记录

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
# ...
spec:
  cruiseControl:
    # ...
    logging:
      type: external
      valueFrom:
        configMapKeyRef:
          name: customConfigMap
          key: cruise-control-log4j.properties
    # ...

垃圾收集器(GC)

也可以使用 jvmOptions 属性 来启用(或禁用)垃圾收集器日志记录。

12.2.50.6. CruiseControlSpec schema 属性
属性Description

image

pod 的 docker 镜像。

字符串

tlsSidecar

tlsSidecar 属性已弃用。TLS sidecar 配置。

TlsSidecar

资源

为 Cruise Control 容器保留的 CPU 和内存资源。如需更多信息,请参阅 core/v1 资源查询的外部文档

ResourceRequirements

livenessProbe

对 Cruise Control 容器进行 Pod 存活度检查。

探测

readinessProbe

Pod 就绪度检查是否有 Cruise Control 容器。

探测

jvmOptions

断路器控制容器的 JVM 选项。

JvmOptions

logging

用于 Cruise Control 的日志记录配置(Log4j 2)类型取决于给定对象中的 logging.type 属性的值,它必须是 [inline, external] 中的一个。

InlineLogging, ExternalLogging

模板

模板以指定如何生成控制资源 、部署和 Pod

CruiseControlTemplate

brokerCapacity

崩溃控制 代理容量 配置。

BrokerCapacity

config

断路器控制配置。有关配置选项的完整列表请参考 https://github.com/linkedin/cruise-control/wiki/Configurations。请注意,无法设置以下前缀的属性:bootstrap.servers、client.id、zookeeper.、network.、security., failed.brokers.zk.path,webserver.http.http., webserver.api.urlprefix, webserver.session.path, webserver.accesslog., two.step., request.reason.required, metric.reporter.sampler.bootstrap.servers, capacity.config.file, self.healing., ssl., kafka.broker.failure.detection.enable, topic.config.provider.class (例外: ssl.cipher.suites, ssl.protocol, ssl.enabled.protocols, webserver.http.cors.enabled, webserver.http.cors.enabled, webserver.http.cors.origin, webserver.http.cors.exposeheaders, webserver.security.enable, webserver.ssl.enable)。

map

metricsConfig

指标配置。这个类型取决于给定对象中的 metricsConfig.type 属性的值,它必须是 [jmxPrometheusExporter] 之一。

JmxPrometheusExporterMetrics

12.2.51. CruiseControlTemplate 模式参考

使用的: CruiseControlSpec

属性Description

部署

用于控制部署的模板 .

resourcetemplate

Pod

用于控制 Pod 的模板。

PodTemplate

apiService

用于控制 API 服务 的模板

InternalServiceTemplate

podDisruptionBudget

用于控制 PodDisruptionBudget 的模板。

PodDisruptionBudgetTemplate

cruiseControlContainer

Cruise Control 容器的模板。

ContainerTemplate

tlsSidecarContainer

tlsSidecarContainer 属性已弃用。Cruise Control TLS sidecar 容器的模板。

ContainerTemplate

serviceAccount

Cruise Control 服务帐户的模板。

resourcetemplate

12.2.52. BrokerCapacity schema 参考

使用的: CruiseControlSpec

属性Description

disk

disk 属性已弃用。Cruise Control disk capacity 设置已弃用,它会被忽略,并将在以后的代理容量中删除用于磁盘,以字节为单位。使用带有标准 OpenShift 字节单元(K、M、G 或 T)、其 bibyte (双字节(Ki、Mi、Gi 或 Ti)或 Ti 的字节值,或使用 E 表示法的字节值。例如: 100000M、100000Mi、104857600000 或 1e+11。

字符串

cpuUtilization

cpuUtilization 属性已弃用。Cruise Control CPU 容量设置已弃用,被忽略,并将在以后的代理容量中删除,作为百分比(0 - 100)。

整数

inboundNetwork

用于入站网络吞吐量的代理容量(以字节/秒为单位)。使用标准 OpenShift 字节单元(K、M、G)或其 bibyte (双字节(Ki, Mi, Gi)的整数值。例如,10000KiB/s。

字符串

outboundNetwork

代理容量,用于出站网络吞吐量(以字节/秒为单位)。使用标准 OpenShift 字节单元(K、M、G)或其 bibyte (双字节(Ki, Mi, Gi)的整数值。例如,10000KiB/s。

字符串

12.2.53. KafkaExporterSpec schema reference

使用的: KafkaSpec

属性Description

image

pod 的 docker 镜像。

字符串

groupRegex

正则表达式,以指定要收集哪些消费者组。默认值为 .*

字符串

topicRegex

正则表达式,以指定要收集哪些主题。默认值为 .*

字符串

资源

要保留的 CPU 和内存资源。如需更多信息,请参阅 core/v1 资源查询的外部文档

ResourceRequirements

logging

仅记录给定严重性或更高严重性的日志消息。有效级别: [info,debug,trace]。默认日志级别为 info

字符串

enableSaramaLogging

启用 Sarama 日志记录,这是 Kafka Exporter 使用的 Go 客户端库。

布尔值

模板

自定义部署模板和 pod。

KafkaExporterTemplate

livenessProbe

Pod 存活度检查。

探测

readinessProbe

Pod 就绪度检查。

探测

12.2.54. KafkaExporterTemplate 模式参考

使用的: KafkaExporterSpec

属性Description

部署

Kafka 导出器 部署模板.

resourcetemplate

Pod

Kafka 导出器 Pod 的模板

PodTemplate

service

service 属性已弃用。Kafka Exporter 服务已被删除。Kafka Exporter Service 模板。

resourcetemplate

container

Kafka Exporter 容器的模板。

ContainerTemplate

serviceAccount

Kafka Exporter 服务帐户的模板。

resourcetemplate

12.2.55. KafkaStatus 模式参考

使用的: Kafka

属性Description

conditions

状态条件列表。

状况 数组

observedGeneration

Operator 最后协调的 CRD 的生成。

整数

监听器

内部和外部监听程序的地址。

ListenerStatus 数组

clusterId

Kafka 集群 Id。

字符串

12.2.56. 条件 模式参考

used in: KafkaBridgeStatus, KafkaConnectorStatus, KafkaConnectStatus, KafkaMirrorMaker2Status, KafkaMirrorMakerStatus, KafkaRebalanceStatus, KafkaTopicStatus, KafkaTopicStatus, KafkaUserStatus

属性Description

type

条件的唯一标识符,用于区分资源中的其他条件。

字符串

status

条件的状态,可以是 True、False 或 Unknown。

字符串

lastTransitionTime

最后一次类型的条件从一个状态更改为另一个状态。所需格式为 UTC 时区中的 'yyyy-MM-ddTHH:mm:ssZ'。

字符串

reason

条件最后一次转换的原因(CamelCase 中的一个词)。

字符串

message

人类可读的消息,表示有关条件最后一次转换的详细信息。

字符串

12.2.57. ListenerStatus 模式参考

使用的: KafkaStatus

属性Description

type

type 属性已弃用,现在应 使用名称 进行配置。侦听器的名称。

字符串

name

侦听器的名称。

字符串

addresses

此侦听器的地址列表。

ListenerAddress 数组

bootstrapServers

用于使用此侦听器连接到 Kafka 集群的 host:port 对的逗号分隔列表。

字符串

证书

用于在连接到给定侦听器时验证服务器身份的 TLS 证书列表。仅为 tls外部 监听程序设置。

字符串数组

12.2.58. ListenerAddress 模式参考

used in: ListenerStatus

属性Description

主机

Kafka bootstrap 服务的 DNS 名称或 IP 地址。

字符串

port

Kafka bootstrap 服务的端口。

整数

12.2.59. KafkaConnect 模式参考

属性Description

spec

Kafka Connect 集群的规格。

KafkaConnectSpec

status

Kafka Connect 集群的状态。

KafkaConnectStatus

12.2.60. KafkaConnectSpec 模式参考

使用的: KafkaConnect

KafkaConnectSpec schema 属性的完整列表

配置 Kafka Connect 集群。

12.2.60.1. config

使用 config 属性将 Kafka 选项配置为密钥。

可以提供标准 Apache Kafka Connect 配置,仅限于不直接由 AMQ Streams 管理的属性。

无法配置与以下内容相关的配置选项:

  • Kafka 集群 bootstrap 地址
  • 安全(加密、验证和授权)
  • 侦听器/ REST 接口配置
  • 插件路径配置

这些值可以是以下 JSON 类型之一:

  • 字符串
  • Number
  • 布尔值

除了直接由 AMQ Streams 管理的选项外,您可以指定并配置 Apache Kafka 文档 中列出的选项。特别是,禁止使用与以下字符串之一相等或开始的配置选项:

  • SSL.
  • SASL:
  • 安全性.
  • 监听器
  • plugin.path
  • REST.
  • bootstrap.servers

当在 config 属性中存在禁止选项时,它会被忽略,并将警告消息输出到 Cluster Operator 日志文件。所有其他选项都传递到 Kafka Connect。

重要

Cluster Operator 不验证提供的配置对象中的 密钥或 值。当提供无效的配置时,Kafka Connect 集群可能无法启动,也可能不稳定。在这种情形中,修正 KafkaConnect.spec.config 对象中的配置,然后 Cluster Operator 可以向所有 Kafka Connect 节点推出新配置。

某些选项有默认值:

  • 带有默认值 connect-clustergroup.id
  • 使用默认值 connect-cluster-offsetsoffset.storage.topic
  • config.storage.topic with default value connect-cluster-configs
  • status.storage.topic with default value connect-cluster-status
  • key.converter with default value org.apache.kafka.connect.json.JsonConverter
  • value.converter with default value org.apache.kafka.connect.json.JsonConverter

如果 KafkaConnect.spec.config 属性中没有它们,则会自动配置这些选项。

禁止的选项有例外。您可以使用特定 密码套件 作为 TLS 版本,为客户端连接使用三个允许的 ssl 配置选项。密码套件结合了用于安全连接和数据传输的算法。您还可以配置 ssl.endpoint.identification.algorithm 属性来启用或禁用主机名验证。

Kafka Connect 配置示例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnect
metadata:
  name: my-connect
spec:
  # ...
  config:
    group.id: my-connect-cluster
    offset.storage.topic: my-connect-cluster-offsets
    config.storage.topic: my-connect-cluster-configs
    status.storage.topic: my-connect-cluster-status
    key.converter: org.apache.kafka.connect.json.JsonConverter
    value.converter: org.apache.kafka.connect.json.JsonConverter
    key.converter.schemas.enable: true
    value.converter.schemas.enable: true
    config.storage.replication.factor: 3
    offset.storage.replication.factor: 3
    status.storage.replication.factor: 3
    ssl.cipher.suites: "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384"
    ssl.enabled.protocols: "TLSv1.2"
    ssl.protocol: "TLSv1.2"
    ssl.endpoint.identification.algorithm: HTTPS
  # ...

对于将特定 密码套件 用于 TLS 版本的客户端连接,您可以配置允许的 ssl 属性您还可以配置 ssl.endpoint.identification.algorithm 属性 来启用或禁用主机名验证。

12.2.60.2. logging

Kafka Connect 都有自己的可配置的日志记录器:

  • connect.root.logger.level
  • log4j.logger.org.reflections

根据运行的 Kafka Connect 插件,添加了进一步的日志记录器。

使用 curl 请求获取在任何 Kafka 代理 pod 上运行的 Kafka Connect 日志记录器的完整列表:

curl -s http://<connect-cluster-name>-connect-api:8083/admin/loggers/

Kafka Connect 使用 Apache log4j 日志记录器实现。

使用 logging 属性配置日志记录器和日志记录器级别。

您可以通过直接指定日志记录器和级别(在线)或使用自定义(外部) ConfigMap 来设置日志级别。如果使用 ConfigMap,您可以将 logging.valueFrom.configMapKeyRef.name 属性设置为包含外部日志记录配置的 ConfigMap 的名称。在 ConfigMap 中,日志记录配置使用 log4j.properties 来描述。logging.valueFrom.configMapKeyRef.namelogging.valueFrom.configMapKeyRef.key 属性都是必须的。当 Cluster Operator 运行时,会使用指定的日志记录配置创建 ConfigMap,然后在每次协调后重新创建。如果没有指定自定义 ConfigMap,则会使用默认的日志记录设置。如果没有设置特定的日志记录器值,则会继承该日志记录器的上级日志记录器设置。有关日志级别的更多信息,请参阅 Apache 日志记录服务

此处会看到 内联外部日志记录 的示例。

内联日志

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnect
spec:
  # ...
  logging:
    type: inline
    loggers:
      connect.root.logger.level: "INFO"
  # ...

外部日志记录

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnect
spec:
  # ...
  logging:
    type: external
    valueFrom:
      configMapKeyRef:
        name: customConfigMap
        key: connect-logging.log4j
  # ...

任何尚未配置级别的可用日志记录器都设置为 OFF

如果使用 Cluster Operator 部署 Kafka Connect,则会动态应用对 Kafka Connect 日志记录级别的更改。

如果使用外部日志记录,则在日志附加器更改时触发滚动更新。

垃圾收集器(GC)

也可以使用 jvmOptions 属性 来启用(或禁用)垃圾收集器日志记录。

12.2.60.3. KafkaConnectSpec 模式属性
属性Description

version

Kafka Connect 版本。默认为 3.2.3。参阅用户文档来了解升级或降级版本所需的流程。

字符串

replicas

Kafka Connect 组中的 pod 数量。

整数

image

pod 的 docker 镜像。

字符串

bootstrapServers

要连接的 bootstrap 服务器。这应该被指定为以逗号分开的 < hostname> :_&lt;port>_ 对列表。

字符串

tls

TLS 配置。

ClientTls

身份验证

Kafka Connect 的身份验证配置。这个类型取决于给定对象中的 authentication.type 属性的值,它必须是 [tls, scram-sha-256, scram-sha-256, scram-sha-512, plain, oauth]。

KafkaClientAuthenticationTls, KafkaClientAuthenticationScramSha256, KafkaClientAuthenticationScramSha512, KafkaClientAuthenticationPlain, KafkaClientAuthenticationOAuth

config

Kafka Connect 配置。无法设置以下前缀的属性: ssl., sasl., security.,监听程序, plugin.path, rest., bootstrap.servers, consumer.interceptor.classes, producer.interceptor.classes (权限为 ssl.endpoint.identification.algorithm、ssl.cipher.suites、ssl.protocol.enabled ssl.protocols)。

map

资源

CPU 和内存资源和请求的初始资源的最大限制。如需更多信息,请参阅 core/v1 资源查询的外部文档

ResourceRequirements

livenessProbe

Pod 存活度检查。

探测

readinessProbe

Pod 就绪度检查.

探测

jvmOptions

pod 的 JVM 选项。

JvmOptions

jmxOptions

JMX 选项.

KafkaJmxOptions

logging

Kafka Connect 的日志记录配置。类型取决于给定对象中的 logging.type 属性的值,它必须是 [inline, external] 中的一个。

InlineLogging, ExternalLogging

clientRackInitImage

用于初始化 客户端的 init 容器的镜像。

字符串

rack

配置用作 客户端的节点标签。rack consumer 配置。

rack

tracing

在 Kafka Connect 中配置追踪。类型取决于给定对象中的 tracing.type 属性的值,它必须是 [jaeger] 中的一个。

Jaegertracing

模板

Kafka Connect 和 Kafka Mirror Maker 2 资源的模板。这个模板允许用户指定如何生成 Deployment, PodsService

KafkaConnectTemplate

externalConfiguration

将 Secret 或 ConfigMap 中的数据传递给 Kafka Connect pod,并使用它们配置连接器。

ExternalConfiguration

build

配置应如何构建 Connect 容器镜像。可选。

Build

metricsConfig

指标配置。这个类型取决于给定对象中的 metricsConfig.type 属性的值,它必须是 [jmxPrometheusExporter] 之一。

JmxPrometheusExporterMetrics

12.2.61. ClientTls 模式参考

used in: KafkaBridgeSpec, KafkaConnectSpec, KafkaMirrorMaker2ClusterSpec, KafkaMirrorMakerConsumerSpec, KafkaMirrorMakerProducerSpec

ClientTls 模式属性的完整列表

配置用于连接 KafkaConnect、KafkaBridge、KafkaMirror、KafkaMirrorMaker2 到集群的 TLS 可信证书。

12.2.61.1. trustedCertificates

使用 trustedCertificates 属性 提供一个 secret 列表。

12.2.61.2. ClientTls 模式属性
属性Description

trustedCertificates

TLS 连接的可信证书。

CertSecretSource 数组

12.2.62. KafkaClientAuthenticationTls 模式参考

used in: KafkaBridgeSpec, KafkaConnectSpec, KafkaMirrorMaker2ClusterSpec, KafkaMirrorMakerConsumerSpec, KafkaMirrorMakerProducerSpec

KafkaClientAuthenticationTls schema 属性的完整列表

要配置 TLS 客户端身份验证,请将 type 属性设置为 tls 的值。TLS 客户端身份验证使用 TLS 证书进行身份验证。

12.2.62.1. certificateAndKey

证书在 certificateAndKey 属性中指定,始终从 OpenShift secret 加载。在 secret 中,证书必须以 X509 格式存储在两个不同的密钥下:public 和 private。

您可以使用 User Operator 创建的 secret,或者您可以使用用于身份验证的密钥创建自己的 TLS 证书文件,然后从文件创建 Secret

oc create secret generic MY-SECRET \
--from-file=MY-PUBLIC-TLS-CERTIFICATE-FILE.crt \
--from-file=MY-PRIVATE.key
注意

TLS 客户端身份验证只能与 TLS 连接一起使用。

TLS 客户端身份验证配置示例

authentication:
  type: tls
  certificateAndKey:
    secretName: my-secret
    certificate: my-public-tls-certificate-file.crt
    key: private.key

12.2.62.2. KafkaClientAuthenticationTls 模式属性

type 属性是一种差异性,用于区分 KafkaClientAuthenticationTls 类型来自 KafkaClientAuthenticationScramSha256KafkaClientAuthenticationScramSha512KafkaClientAuthenticationPlainKafkaClientAuthentication Plain。它必须具有类型为 KafkaClientAuthenticationTls 的值 tls

属性Description

certificateAndKey

对包含证书和私钥对的 Secret 的引用。

CertAndKeySecretSource

type

必须为 tls

字符串

12.2.63. KafkaClientAuthenticationScramSha256 schema reference

used in: KafkaBridgeSpec, KafkaConnectSpec, KafkaMirrorMaker2ClusterSpec, KafkaMirrorMakerConsumerSpec, KafkaMirrorMakerProducerSpec

KafkaClientAuthenticationScramSha256 模式属性的完整列表

要配置基于 SASL 的 SCRAM-SHA-256 身份验证,请将 type 属性设置为 scram-sha-256。SCRAM-SHA-256 身份验证机制需要用户名和密码。

12.2.63.1. username

username 属性中指定用户名。

12.2.63.2. passwordSecret

passwordSecret 属性中,指定指向包含密码的 Secret 的链接。

您可以使用 User Operator 创建的 secret。

如果需要,您可以在明文中创建一个包含密码的文本文件,以用于身份验证:

echo -n PASSWORD > MY-PASSWORD.txt

然后,您可以从文本文件中创建 Secret,为密码设置您自己的字段名称(密钥):

oc create secret generic MY-CONNECT-SECRET-NAME --from-file=MY-PASSWORD-FIELD-NAME=./MY-PASSWORD.txt

Kafka Connect 的 SCRAM-SHA-256 客户端身份验证的 Secret 示例

apiVersion: v1
kind: Secret
metadata:
  name: my-connect-secret-name
type: Opaque
data:
  my-connect-password-field: LFTIyFRFlMmU2N2Tm

secretName 属性包含 Secret 的名称,password 属性包含密码存储在 Secret 中的键的名称。

重要

不要在 password 属性中指定 实际密码

Kafka Connect 基于 SASL 的 SCRAM-SHA-256 客户端验证配置示例

authentication:
  type: scram-sha-256
  username: my-connect-username
  passwordSecret:
    secretName: my-connect-secret-name
    password: my-connect-password-field

12.2.63.3. KafkaClientAuthenticationScramSha256 schema properties
属性Description

passwordSecret

对包含密码的 Secret 的引用。

PasswordSecretSource

type

必须是 scram-sha-256

字符串

username

用于身份验证的用户名。

字符串

12.2.64. PasswordSecretSource 架构参考

使用的: KafkaClientAuthenticationPlain, KafkaClientAuthenticationScramSha256, KafkaClientAuthenticationScramSha512

属性Description

password

存储密码的 Secret 中的密钥名称。

字符串

secretName

包含密码的 Secret 名称。

字符串

12.2.65. KafkaClientAuthenticationScramSha512 模式参考

used in: KafkaBridgeSpec, KafkaConnectSpec, KafkaMirrorMaker2ClusterSpec, KafkaMirrorMakerConsumerSpec, KafkaMirrorMakerProducerSpec

KafkaClientAuthenticationScramSha512 架构属性的完整列表

要配置基于 SASL 的 SCRAM-SHA-512 身份验证,请将 type 属性设置为 scram-sha-512。SCRAM-SHA-512 身份验证机制需要用户名和密码。

12.2.65.1. username

username 属性中指定用户名。

12.2.65.2. passwordSecret

passwordSecret 属性中,指定指向包含密码的 Secret 的链接。

您可以使用 User Operator 创建的 secret。

如果需要,您可以在明文中创建一个包含密码的文本文件,以用于身份验证:

echo -n PASSWORD > MY-PASSWORD.txt

然后,您可以从文本文件中创建 Secret,为密码设置您自己的字段名称(密钥):

oc create secret generic MY-CONNECT-SECRET-NAME --from-file=MY-PASSWORD-FIELD-NAME=./MY-PASSWORD.txt

Kafka Connect 的 SCRAM-SHA-512 客户端身份验证的 Secret 示例

apiVersion: v1
kind: Secret
metadata:
  name: my-connect-secret-name
type: Opaque
data:
  my-connect-password-field: LFTIyFRFlMmU2N2Tm

secretName 属性包含 Secret 的名称,password 属性包含密码存储在 Secret 中的键的名称。

重要

不要在 password 属性中指定 实际密码

Kafka Connect 基于 SASL 的 SCRAM-SHA-512 客户端身份验证配置示例

authentication:
  type: scram-sha-512
  username: my-connect-username
  passwordSecret:
    secretName: my-connect-secret-name
    password: my-connect-password-field

12.2.65.3. KafkaClientAuthenticationScramSha512 schema properties
属性Description

passwordSecret

对包含密码的 Secret 的引用。

PasswordSecretSource

type

必须为 scram-sha-512

字符串

username

用于身份验证的用户名。

字符串

12.2.66. KafkaClientAuthenticationPlain 模式参考

used in: KafkaBridgeSpec, KafkaConnectSpec, KafkaMirrorMaker2ClusterSpec, KafkaMirrorMakerConsumerSpec, KafkaMirrorMakerProducerSpec

KafkaClientAuthenticationPlain schema 属性的完整列表

要配置基于 SASL 的 PLAIN 身份验证,请将 type 属性设置为 。SASL PLAIN 身份验证机制需要一个用户名和密码。

警告

SASL PLAIN 机制将在网络以明文形式传输用户名和密码。如果启用了 TLS 加密,只有使用 SASL PLAIN 身份验证。

12.2.66.1. username

username 属性中指定用户名。

12.2.66.2. passwordSecret

passwordSecret 属性中,指定指向包含密码的 Secret 的链接。

您可以使用 User Operator 创建的 secret。

如果需要,创建一个包含密码的文本文件(以明文形式用于身份验证):

echo -n PASSWORD > MY-PASSWORD.txt

然后,您可以从文本文件中创建 Secret,为密码设置您自己的字段名称(密钥):

oc create secret generic MY-CONNECT-SECRET-NAME --from-file=MY-PASSWORD-FIELD-NAME=./MY-PASSWORD.txt

Kafka Connect 的 PLAIN 客户端身份验证的 Secret 示例

apiVersion: v1
kind: Secret
metadata:
  name: my-connect-secret-name
type: Opaque
data:
  my-password-field-name: LFTIyFRFlMmU2N2Tm

secretName 属性包含 Secret 的名称,password 属性包含密码存储在 Secret 中的键的名称。

重要

不要在 password 属性中指定 实际密码

基于 SASL 的 PLAIN 客户端验证配置示例

authentication:
  type: plain
  username: my-connect-username
  passwordSecret:
    secretName: my-connect-secret-name
    password: my-password-field-name

12.2.66.3. KafkaClientAuthenticationPlain schema 属性

type 属性是一种差异性,用于区分来自 KafkaClientAuthenticationTls, KafkaClientAuthenticationScramSha256, KafkaClientAuthenticationScramSha512, KafkaClientAuthenticationOAuthKafkaClientAuthenticationPlain 类型。对于类型 KafkaClientAuthenticationPlain,它需要是值 plain

属性Description

passwordSecret

对包含密码的 Secret 的引用。

PasswordSecretSource

type

必须为

字符串

username

用于身份验证的用户名。

字符串

12.2.67. KafkaClientAuthenticationOAuth 模式参考

used in: KafkaBridgeSpec, KafkaConnectSpec, KafkaMirrorMaker2ClusterSpec, KafkaMirrorMakerConsumerSpec, KafkaMirrorMakerProducerSpec

KafkaClientAuthenticationOAuth 模式属性的完整列表

要配置 OAuth 客户端身份验证,请将 type 属性设置为 oauth

可以使用以下选项之一配置 OAuth 身份验证:

  • 客户端 ID 和 secret
  • 客户端 ID 和刷新令牌
  • 访问令牌
  • TLS

客户端 ID 和 secret

您可以在 tokenEndpointUri 属性中配置授权服务器的地址和身份验证中使用的客户端 ID 和客户端 secret。OAuth 客户端将连接到 OAuth 服务器,使用客户端 ID 和 secret 进行身份验证,并获取它用来与 Kafka 代理进行身份验证的访问令牌。在 clientSecret 属性中,指定指向包含客户端 secret 的 Secret 的链接。

使用客户端 ID 和客户端 secret 的 OAuth 客户端身份验证示例

authentication:
  type: oauth
  tokenEndpointUri: https://sso.myproject.svc:8443/auth/realms/internal/protocol/openid-connect/token
  clientId: my-client-id
  clientSecret:
    secretName: my-client-oauth-secret
    key: client-secret

如果需要,可以指定 范围受众

客户端 ID 和刷新令牌

您可以在 tokenEndpointUri 属性中配置 OAuth 服务器的地址和 OAuth 客户端 ID 和刷新令牌。OAuth 客户端将连接到 OAuth 服务器,使用客户端 ID 和刷新令牌进行身份验证,并获取一个用于与 Kafka 代理进行身份验证的访问令牌。在 refreshToken 属性中,指定指向包含刷新令牌的 Secret 的链接。

+ 使用客户端 ID 和刷新令牌的 OAuth 客户端身份验证示例

authentication:
  type: oauth
  tokenEndpointUri: https://sso.myproject.svc:8443/auth/realms/internal/protocol/openid-connect/token
  clientId: my-client-id
  refreshToken:
    secretName: my-refresh-token-secret
    key: refresh-token

访问令牌

您可以配置用于直接与 Kafka 代理身份验证的访问令牌。在这种情况下,您不指定 tokenEndpointUri。在 accessToken 属性中,指定指向包含访问令牌的 Secret 的链接。

仅使用访问令牌的 OAuth 客户端身份验证示例

authentication:
  type: oauth
  accessToken:
    secretName: my-access-token-secret
    key: access-token

TLS

使用 HTTPS 协议访问 OAuth 服务器不需要任何其他配置,只要其使用的 TLS 证书由可信证书颁发机构签名,并且其主机名在证书中列出。

如果您的 OAuth 服务器使用自签名证书,或者由不受可信的证书颁发机构签名,您可以在自定义资源中配置可信证书列表。tlsTrustedCertificates 属性包含一个 secret 列表,其中存储了证书的密钥名称。证书必须以 X509 格式存储。

提供的 TLS 证书示例

authentication:
  type: oauth
  tokenEndpointUri: https://sso.myproject.svc:8443/auth/realms/internal/protocol/openid-connect/token
  clientId: my-client-id
  refreshToken:
    secretName: my-refresh-token-secret
    key: refresh-token
  tlsTrustedCertificates:
    - secretName: oauth-server-ca
      certificate: tls.crt

OAuth 客户端默认将验证您的 OAuth 服务器的主机名是否与证书主体或其中一个替代 DNS 名称匹配。如果不需要,您可以禁用主机名验证。

禁用 TLS 主机名验证示例

authentication:
  type: oauth
  tokenEndpointUri: https://sso.myproject.svc:8443/auth/realms/internal/protocol/openid-connect/token
  clientId: my-client-id
  refreshToken:
    secretName: my-refresh-token-secret
    key: refresh-token
  disableTlsHostnameVerification: true

12.2.67.1. KafkaClientAuthenticationOAuth 模式属性

type 属性是一个差异性程序,它区分来自 KafkaClientAuthenticationTls, KafkaClientAuthenticationScramSha256, KafkaClientAuthenticationScramSha512, KafkaClientAuthenticationPlainKafkaClientAuthenticationOAuth 类型。对于类型 KafkaClientAuthenticationOAuth,它需要是值 oauth

属性Description

accessToken

链接到包含从授权服务器获取的访问令牌的 OpenShift Secret。

GenericSecretSource

accessTokenIsJwt

配置访问令牌是否应被视为 JWT。如果授权服务器返回不透明令牌,则此项应设为 false。默认值为 true

布尔值

受众

对授权服务器进行身份验证时使用的 OAuth 使用者。某些授权服务器需要明确设置使用者。可能的值取决于配置授权服务器的方式。默认情况下,在执行令牌端点请求时,不会指定 使用者

字符串

clientId

Kafka 客户端可以用来向 OAuth 服务器进行身份验证并使用令牌端点 URI 的 OAuth 客户端 ID。

字符串

clientSecret

链接到包含 Kafka 客户端 secret 的 OpenShift Secret,这些 secret 可以用来与 OAuth 服务器进行身份验证,并使用令牌端点 URI。

GenericSecretSource

connectTimeoutSeconds

连接授权服务器时出现连接超时(以秒为单位)。如果没有设置,则有效连接超时为 60 秒。

整数

disableTlsHostnameVerification

启用或禁用 TLS 主机名验证。默认值为 false

布尔值

maxTokenExpirySeconds

设置或限制访问令牌的生存时间到指定的秒数。如果授权服务器返回不透明令牌,则应设置此项。

整数

readTimeoutSeconds

连接到授权服务器时读取超时(以秒为单位)。如果没有设置,则有效读取超时为 60 秒。

整数

refreshToken

链接到包含刷新令牌的 OpenShift Secret,该令牌可用于从授权服务器获取访问令牌。

GenericSecretSource

scope

对授权服务器进行身份验证时使用的 OAuth 范围。些授权服务器需要设置此项。可能的值取决于配置授权服务器的方式。默认情况下,在执行令牌端点请求时不指定 范围

字符串

tlsTrustedCertificates

TLS 与 OAuth 服务器连接的可信证书。

CertSecretSource 数组

tokenEndpointUri

授权服务器令牌端点 URI。

字符串

type

必须是 oauth

字符串

12.2.68. Jaegertracing 模式 参考

used in: KafkaBridgeSpec, KafkaConnectSpec, KafkaMirrorMaker2Spec, KafkaMirrorMakerSpec

type 属性是一种分ator,用于区分使用与其它子类型中添加的 JaegerTracing 类型。它必须具有 jaeger 值才能类型 JaegerTracing

属性Description

type

必须为 jaeger

字符串

12.2.69. KafkaConnectTemplate 模式参考

使用的: KafkaConnectSpec, KafkaMirrorMaker2Spec

属性Description

部署

Kafka Connect Deployment 的模板。

DeploymentTemplate

Pod

Kafka Connect Pod 模板。

PodTemplate

apiService

Kafka Connect API Service 的模板。

InternalServiceTemplate

connectContainer

Kafka Connect 容器的模板。

ContainerTemplate

initContainer

Kafka init 容器的模板。

ContainerTemplate

podDisruptionBudget

Kafka Connect PodDisruptionBudget 模板。

PodDisruptionBudgetTemplate

serviceAccount

Kafka Connect 服务帐户的模板。

resourcetemplate

clusterRoleBinding

Kafka Connect ClusterRoleBinding 的模板。

resourcetemplate

buildPod

Kafka Connect Build Pod 的模板。构建 Pod 仅适用于 OpenShift。

PodTemplate

buildContainer

Kafka Connect Build 容器的模板。构建容器仅用于 OpenShift。

ContainerTemplate

buildConfig

用于构建新容器镜像的 Kafka Connect BuildConfig 模板。BuildConfig 仅适用于 OpenShift。

BuildConfigTemplate

buildServiceAccount

Kafka Connect Build 服务帐户的模板。

resourcetemplate

jmxSecret

Kafka Connect Cluster JMX 身份验证的 Secret 模板。

resourcetemplate

12.2.70. DeploymentTemplate 模式参考

used in: KafkaBridgeTemplate, KafkaConnectTemplate, KafkaMirrorMakerTemplate

属性Description

metadata

应用到资源的元数据。

MetadataTemplate

deploymentStrategy

用于此 Deployment 的 DeploymentStrategy。有效值为 RollingUpdateRecreate。默认为 RollingUpdate

字符串(一个 [RollingUpdate, Recreate])

12.2.71. BuildConfigTemplate 模式参考

使用的: KafkaConnectTemplate

属性Description

metadata

应用到 PodDisruptionBudgetTemplate 资源的元数据。

MetadataTemplate

pullSecret

带有用于拉取基础镜像的凭证的 Container Registry Secret。

字符串

12.2.72. ExternalConfiguration 模式参考

使用的: KafkaConnectSpec, KafkaMirrorMaker2Spec

ExternalConfiguration 模式属性的完整列表

配置外部存储属性,以定义 Kafka 连接连接器的配置选项。

您可以将 ConfigMap 或 Secret 挂载到 Kafka Connect pod 中,作为环境变量或卷。卷和环境变量在 KafkaConnect.specexternalConfiguration 属性中配置。

应用时,环境变量和卷可在开发您的连接器时使用。

12.2.72.1. env

使用 env 属性指定一个或多个环境变量。这些变量可以包含 ConfigMap 或 Secret 中的值。

包含环境变量值的 Secret 示例

apiVersion: v1
kind: Secret
metadata:
  name: aws-creds
type: Opaque
data:
  awsAccessKey: QUtJQVhYWFhYWFhYWFhYWFg=
  awsSecretAccessKey: Ylhsd1lYTnpkMjl5WkE=

注意

用户定义的环境变量的名称不能以 KAFKA_STRIMZI_ 开头。

要将 Secret 的值挂载到环境变量,请使用 valueFrom 属性和 secretKeyRef

将环境变量设置为来自 Secret 的值的环境变量示例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnect
metadata:
  name: my-connect
spec:
  # ...
  externalConfiguration:
    env:
      - name: AWS_ACCESS_KEY_ID
        valueFrom:
          secretKeyRef:
            name: aws-creds
            key: awsAccessKey
      - name: AWS_SECRET_ACCESS_KEY
        valueFrom:
          secretKeyRef:
            name: aws-creds
            key: awsSecretAccessKey

挂载 Secret 的常见用例是用于与 Amazon AWS 通信的连接器。连接器需要能够读取 AWS_ACCESS_KEY_IDAWS_SECRET_ACCESS_KEY

要将 ConfigMap 中的值挂载到环境变量,请在 valueFrom 属性中使用 configMapKeyRef,如下例所示。

从 ConfigMap 中设置为值的环境变量示例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnect
metadata:
  name: my-connect
spec:
  # ...
  externalConfiguration:
    env:
      - name: MY_ENVIRONMENT_VARIABLE
        valueFrom:
          configMapKeyRef:
            name: my-config-map
            key: my-key

12.2.72.2. 

使用卷将 ConfigMap 或 Secret 挂载到 Kafka Connect pod。

在以下场景中使用卷而不是环境变量非常有用:

  • 挂载用于配置 Kafka 连接连接器的属性文件
  • 使用 TLS 证书挂载信任存储或密钥存储

卷挂载到路径 /opt/kafka/external-configuration/ <volume-name> 上的 Kafka Connect 容器中。例如,名为 connector-config 的卷中的文件将出现在目录 /opt/kafka/external-configuration/connector-config

配置 提供程序 从配置外部加载值。使用提供程序机制避免在 Kafka Connect REST 接口上传递受限信息。

  • FileConfigProvider 从文件中的属性加载配置值。
  • DirectoryConfigProvider 从目录结构中分离文件加载配置值。

如果要添加多个供应商,包括自定义供应商,请使用逗号分隔的列表。您可以使用自定义供应商从其他文件位置加载值。

使用 FileConfigProvider 加载属性值

在本例中,名为 mysecret 的 Secret 包含 connector 属性,用于指定数据库名称和密码:

带有数据库属性的 Secret 示例

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
stringData:
  connector.properties: |- 1
    dbUsername: my-username 2
    dbPassword: my-password

1
属性文件格式的连接器配置。
2
配置中使用的数据库用户名和密码属性。

Secret 和 FileConfigProvider 配置供应商在 Kafka Connect 配置中指定。

  • Secret 挂载到名为 connector-config 的卷。
  • FileConfigProvider 是提供别名 文件

来自 Secret 的外部卷设置为值示例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnect
metadata:
  name: my-connect
spec:
  # ...
  config:
    config.providers: file 1
    config.providers.file.class: org.apache.kafka.common.config.provider.FileConfigProvider 2
  #...
  externalConfiguration:
    volumes:
      - name: connector-config 3
        secret:
          secretName: mysecret 4

1
配置提供程序的别名用于定义其他配置参数。
2
FileConfigProvider 从属性文件提供值。参数使用 config.providers 中的别名,格式为 config.providers.${alias}.class
3
包含 Secret 的卷名称。每个卷都必须在 name 属性中指定 名称,并引用 ConfigMap 或 Secret。
4
Secret 的名称。

Secret 中属性值的占位符在连接器配置中被引用。占位符结构为 file:PATH-AND-FILE-NAME :PROPERTYFileConfigProvider 从连接程序配置中挂载的 Secret 读取并提取数据库的 usernamepassword 属性值。

显示外部值的占位符示例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnector
metadata:
  name: my-source-connector
  labels:
    strimzi.io/cluster: my-connect-cluster
spec:
  class: io.debezium.connector.mysql.MySqlConnector
  tasksMax: 2
  config:
    database.hostname: 192.168.99.1
    database.port: "3306"
    database.user: "${file:/opt/kafka/external-configuration/connector-config/mysecret:dbUsername}"
    database.password: "${file:/opt/kafka/external-configuration/connector-config/mysecret:dbPassword}"
    database.server.id: "184054"
    #...

使用 DirectoryConfigProvider 从独立文件加载属性值

在本例中,Secret 在单独的文件中包含 TLS 信任存储和密钥存储用户凭证。

带有用户凭证的 Secret 示例

apiVersion: v1
kind: Secret
metadata:
  name: my-user
  labels:
    strimzi.io/kind: KafkaUser
    strimzi.io/cluster: my-cluster
type: Opaque
data: 1
  ca.crt: # Public key of the client CA
  user.crt: # User certificate that contains the public key of the user
  user.key: # Private key of the user
  user.p12: # PKCS #12 archive file for storing certificates and keys
  user.password: # Password for protecting the PKCS #12 archive file

Secret 和 DirectoryConfigProvider 配置供应商在 Kafka Connect 配置中指定。

  • Secret 挂载到名为 connector-config 的卷。
  • DirectoryConfigProvider 是提供别名 目录

为用户凭证文件设置的外部卷示例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnect
metadata:
  name: my-connect
spec:
  # ...
  config:
    config.providers: directory
    config.providers.directory.class: org.apache.kafka.common.config.provider.DirectoryConfigProvider 1
  #...
  externalConfiguration:
    volumes:
      - name: cluster-ca
        secret:
          secretName: my-cluster-cluster-ca-cert
      - name: my-user
        secret:
          secretName: my-user

1 1
DirectoryConfigProvider 提供来自目录中的文件的值。参数使用 config.providers 中的别名,格式为 config.providers.${alias}.class

凭据的占位符在连接器配置中引用。占位符结构 是目录:PATH:FILE-NAMEDirectoryConfigProvider 在连接器配置中从挂载的 Secret 中读取并提取凭证。

显示外部值的占位符示例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnector
metadata:
  name: my-source-connector
  labels:
    strimzi.io/cluster: my-connect-cluster
spec:
  class: io.debezium.connector.mysql.MySqlConnector
  tasksMax: 2
  config:
    # ...
    database.history.producer.security.protocol: SSL
    database.history.producer.ssl.truststore.type: PEM
    database.history.producer.ssl.truststore.certificates: "${directory:/opt/kafka/external-configuration/cluster-ca:ca.crt}"
    database.history.producer.ssl.keystore.type: PEM
    database.history.producer.ssl.keystore.certificate.chain: "${directory:/opt/kafka/external-configuration/my-user:user.crt}"
    database.history.producer.ssl.keystore.key: "${directory:/opt/kafka/external-configuration/my-user:user.key}"
    #...

12.2.72.3. ExternalConfiguration schema 属性
属性Description

env

使 Kafka Connect pod 中的 Secret 或 ConfigMap 的数据作为环境变量提供。

ExternalConfigurationEnv 数组

使 Kafka Connect pod 中的 Secret 或 ConfigMap 的数据作为卷可用。

ExternalConfigurationVolumeSource 数组

12.2.73. ExternalConfigurationEnv 模式参考

used in: ExternalConfiguration

属性Description

name

传递给 Kafka Connect pod 的环境变量的名称。环境变量的名称不能以 KAFKA_STRIMZI_ 开头。

字符串

valueFrom

将传递给 Kafka Connect pod 的环境变量值。它可以作为 Secret 或 ConfigMap 字段的引用传递。该字段必须正好指定一个 Secret 或 ConfigMap。

ExternalConfigurationEnvVarSource

12.2.74. ExternalConfigurationEnvVarSource 模式参考

used in: ExternalConfigurationEnv

属性Description

configMapKeyRef

引用 ConfigMap 中的键。如需更多信息,请参阅 core/v1 configmapkeyselector 的外部文档

ConfigMapKeySelector

secretKeyRef

引用 Secret 中的密钥。如需更多信息,请参阅 core/v1 secretkeyselector 的外部文档

SecretKeySelector

12.2.75. ExternalConfigurationVolumeSource schema 引用

used in: ExternalConfiguration

属性Description

configMap

引用 ConfigMap 中的键。必须指定一个 Secret 或 ConfigMap。如需更多信息,请参阅 core/v1 configmapvolumesource 的外部文档

ConfigMapVolumeSource

name

添加至 Kafka Connect pod 的卷名称。

字符串

secret

引用 Secret 中的密钥。必须指定一个 Secret 或 ConfigMap。如需更多信息,请参阅 core/v1 secretvolume 源的外部文档

SecretVolumeSource

12.2.76. 构建 架构参考

使用的: KafkaConnectSpec

Build 架构属性的完整列表

为 Kafka Connect 部署配置额外的连接器。

12.2.76.1. output

要使用额外的连接器插件构建新容器镜像,AMQ Streams 需要一个容器 registry,其中可将镜像推送到、存储和拉取(pull)镜像。AMQ Streams 没有运行自己的容器 registry,因此必须提供 registry。AMQ Streams 支持私有容器 registry 和公共 registry,如 QuayDocker Hub。容器 registry 在 KafkaConnect 自定义资源的 .spec.build.output 部分中配置。输出 配置(需要它)支持两种类型: dockerimagestream

使用 Docker registry

要使用 Docker 注册表,您必须将 类型指定为 docker,而 image 字段则具有新容器镜像的完整名称。全名必须包含:

  • registry 的地址
  • 端口号(如果监听非标准端口)
  • 新容器镜像的标签

有效容器镜像名称示例:

  • docker.io/my-org/my-image/my-tag
  • quay.io/my-org/my-image/my-tag
  • image-registry.image-registry.svc:5000/myproject/kafka-connect-build:latest

每个 Kafka Connect 部署都必须使用单独的镜像,这可能代表在最基本的级别的不同标签。

如果 registry 需要身份验证,请使用 pushSecret 使用 registry 凭证设置 Secret 名称。对于 Secret,使用 kubernetes.io/dockerconfigjson 类型和一个 .dockerconfigjson 文件来包含 Docker 凭证。有关从私有 registry 中拉取镜像的更多信息,请参阅 基于现有 Docker 凭证创建 Secret

输出 配置示例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnect
metadata:
  name: my-connect-cluster
spec:
  #...
  build:
    output:
      type: docker 1
      image: my-registry.io/my-org/my-connect-cluster:latest 2
      pushSecret: my-registry-credentials 3
  #...

1
(必需)AMQ Streams 使用的输出类型。
2
(必需)使用的镜像名称,包括存储库和标签。
3
(可选)带有容器 registry 凭证的 secret 名称。

Using OpenShift ImageStream

您可以使用 OpenShift ImageStream 来存储新的容器镜像,而不是 Docker。在部署 Kafka 连接前,必须手动创建 ImageStream。要使用 ImageStream,将类型设置为 imagestream,并使用 image 属性指定 ImageStream 和所用的标签的名称。例如,my-connect-image-stream:latest

输出 配置示例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnect
metadata:
  name: my-connect-cluster
spec:
  #...
  build:
    output:
      type: imagestream 1
      image: my-connect-build:latest 2
  #...

1
(必需)AMQ Streams 使用的输出类型。
2
(必需)ImageStream 和标签的名称。
12.2.76.2. plugins

连接器插件是一组文件,用于定义连接到特定类型的外部系统所需的实施。容器镜像所需的连接器插件必须使用 KafkaConnect 自定义资源的 .spec.build.plugins 属性进行配置。每个连接器插件都必须有一个名称,该名称在 Kafka Connect 部署中是唯一的。另外,必须列出插件工件。这些工件由 AMQ Streams 下载,添加到新容器镜像中,并在 Kafka Connect 部署中使用。连接器插件工件还可以包括其他组件,如(de) serializers。每个连接器插件都会下载到单独的目录中,以便不同的连接器及其依赖关系被正确 沙盒。每个插件必须至少配置一个 工件

带有两个连接器 插件 插件配置示例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnect
metadata:
  name: my-connect-cluster
spec:
  #...
  build:
    output:
      #...
    plugins: 1
      - name: debezium-postgres-connector
        artifacts:
          - type: tgz
            url: https://repo1.maven.org/maven2/io/debezium/debezium-connector-postgres/1.3.1.Final/debezium-connector-postgres-1.3.1.Final-plugin.tar.gz
            sha512sum: 962a12151bdf9a5a30627eebac739955a4fd95a08d373b86bdcea2b4d0c27dd6e1edd5cb548045e115e33a9e69b1b2a352bee24df035a0447cb820077af00c03
      - name: camel-telegram
        artifacts:
          - type: tgz
            url: https://repo.maven.apache.org/maven2/org/apache/camel/kafkaconnector/camel-telegram-kafka-connector/0.7.0/camel-telegram-kafka-connector-0.7.0-package.tar.gz
            sha512sum: a9b1ac63e3284bea7836d7d24d84208c49cdf5600070e6bd1535de654f6920b74ad950d51733e8020bf4187870699819f54ef5859c7846ee4081507f48873479
  #...

1
(必需)连接器插件列表及其工件。

AMQ Streams 支持以下工件类型:

  • JAR 文件,用于下载并直接使用
  • TGZ 归档,下载和解包
  • ZIP 归档,下载和解包
  • Maven 工件,使用 Maven 协调
  • 其他工件(即下载并直接使用)
重要

AMQ Streams 不执行下载工件的任何安全扫描。为安全起见,您应该首先手动验证工件,并配置 checksum 验证以确保在自动构建和 Kafka Connect 部署中使用相同的工件。

使用 JAR 工件

JAR 工件表示已下载并添加到容器镜像的 JAR 文件。要使用 JAR 工件,将 type 属性设置为 jar,并使用 url 属性指定下载位置。

另外,您可以指定工件的 SHA-512 校验和。如果指定,AMQ Streams 会在构建新容器镜像时验证工件的 checksum。

JAR 工件示例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnect
metadata:
  name: my-connect-cluster
spec:
  #...
  build:
    output:
      #...
    plugins:
      - name: my-plugin
        artifacts:
          - type: jar 1
            url: https://my-domain.tld/my-jar.jar 2
            sha512sum: 589...ab4 3
          - type: jar
            url: https://my-domain.tld/my-jar2.jar
  #...

1
(必需)工件类型。
2
(必需)从中下载工件的 URL。
3
(可选)SHA-512 校验和以验证构件。

使用 TGZ 工件

TGZ 工件用于下载使用 Gzip 压缩方式压缩的 TAR 归档。TGZ 构件可以包含整个 Kafka Connect 连接器,即使组成了多个不同的文件。在构建新容器镜像时,AMQ Streams 会自动下载并解压缩 TGZ 工件。要使用 TGZ 工件,将 type 属性设置为 tgz,并使用 url 属性指定下载位置。

另外,您可以指定工件的 SHA-512 校验和。如果指定,AMQ Streams 会在解包和构建新容器镜像前验证 checksum。

TGZ 工件示例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnect
metadata:
  name: my-connect-cluster
spec:
  #...
  build:
    output:
      #...
    plugins:
      - name: my-plugin
        artifacts:
          - type: tgz 1
            url: https://my-domain.tld/my-connector-archive.tgz 2
            sha512sum: 158...jg10 3
  #...

1
(必需)工件类型。
2
(必需)下载存档的 URL。
3
(可选)SHA-512 校验和以验证构件。

使用 ZIP 工件

ZIP 工件用于下载 ZIP 压缩存档。使用与上一节中描述的 TGZ 工件相同的方式使用 ZIP 工件。唯一的区别是您指定 type: zip 而不是 type: tgz

使用 Maven 工件

Maven 工件用于将连接器插件工件指定为 Maven 协调。Maven 会协调识别插件工件和依赖项,以便它们可以定位并从 Maven 存储库获取。

注意

连接器构建过程必须可以访问 Maven 存储库,才能将工件添加到容器镜像中。

Maven 工件示例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnect
metadata:
  name: my-connect-cluster
spec:
  #...
  build:
    output:
      #...
    plugins:
      - name: my-plugin
        artifacts:
          - type: maven 1
            repository: https://mvnrepository.com 2
            group: org.apache.camel.kafkaconnector 3
            artifact: camel-kafka-connector 4
            version: 0.11.0 5
  #...

1
(必需)工件类型。
2
(可选)用于从中下载工件的 Maven 存储库。如果没有指定存储库,则默认使用 Maven Central 存储库
3
(必需)Maven 组 ID。
4
(必需)Maven 构件类型。
5
(必需)Maven 版本号。

使用其他 工件

其他 工件(artifact)代表下载并添加到容器镜像的任何文件。如果要在生成的容器镜像中使用特定名称作为工件,请使用 fileName 字段。如果没有指定文件名,则根据 URL 哈希来命名该文件。

另外,您可以指定工件的 SHA-512 校验和。如果指定,AMQ Streams 会在构建新容器镜像时验证工件的 checksum。

其他 工件示例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnect
metadata:
  name: my-connect-cluster
spec:
  #...
  build:
    output:
      #...
    plugins:
      - name: my-plugin
        artifacts:
          - type: other  1
            url: https://my-domain.tld/my-other-file.ext  2
            sha512sum: 589...ab4  3
            fileName: name-the-file.ext  4
  #...

1
(必需)工件类型。
2
(必需)从中下载工件的 URL。
3
(可选)SHA-512 校验和以验证构件。
4
(可选)文件存储在生成的容器镜像中的名称。
12.2.76.3. 构建 架构属性
属性Description

output

配置应存储新构建的镜像的位置。必需。类型取决于给定对象中的 output.type 属性的值,它必须是 [docker, imagestream] 中的一个。

Docker 输出, ImageStreamOutput

资源

为构建保留的 CPU 和内存资源。如需更多信息,请参阅 core/v1 资源查询的外部文档

ResourceRequirements

plugins

应该添加到 Kafka 连接中的连接器插件列表。必需。

plugin 数组

12.2.77. DockerOutput 模式参考

使用的: 构建

type 属性是一种分ator,用于区分 DockerOutput 类型与 ImageStreamOutput 类型。它必须具有 docker 的值才能类型为 DockerOutput

属性Description

image

用于标记和推送新构建的镜像的完整名称。例如,quay.io/my-organization/my-custom-connect:latest。必需。

字符串

pushSecret

带有用于推送新构建的镜像的凭证的 Container Registry Secret。

字符串

additionalKanikoOptions

配置构建新连接镜像时将传递给 Kaniko executor 的额外选项。允许的选项有:--customPlatform, --insecure-pull, --insecure-registry, --log-format, --log-timestamp, --registry-mirror, --reproducible, --single-snapshot, --skip-tls-verify, --skip-tls-verify-pull, --skip-tls-verify-pull, --skip-tls-verify-registry, --verbosity, --snapshotMode-new-run.这些选项仅适用于使用 Kaniko executor 的 OpenShift。OpenShift 中会忽略它们。这些选项在 Kaniko GitHub 存储库中 描述。更改此字段不会触发 Kafka Connect 镜像的新构建。

字符串数组

type

必须是 docker

字符串

12.2.78. ImageStreamOutput 模式参考

使用的: 构建

type 属性是一种分ator,用于区分 ImageStreamOutput 类型与 DockerOutput 类型。它必须具有类型 ImageStreamOutput 的值 镜像流

属性Description

image

将新构建镜像的 ImageStream 的名称和标签。例如,my-custom-connect:latest。必需。

字符串

type

必须是 镜像流

字符串

12.2.79. 插件 架构参考

使用的: 构建

属性Description

name

连接器插件的唯一名称。将用于生成将存储连接器工件的路径。名称必须在 KafkaConnect 资源中唯一。名称必须遵循以下模式: ^[a-z][-_a-z0-9]*[a-z]$.必需。

字符串

工件

属于此连接器插件的工件列表。必需。

JarArtifact, TgzArtifact, ZipArtifact, MavenArtifact, OtherArtifact 数组

12.2.80. JarArtifact 模式参考

使用的: 插件

属性Description

url

要下载的构件的 URL。AMQ Streams 不执行下载工件的任何安全扫描。为安全起见,您应该首先手动验证工件并配置 checksum 验证,以确保自动构建中使用相同的工件。jarziptgz 和其他 工件是必需的。不适用于 maven 工件类型。

字符串

sha512sum

工件的 SHA512 校验和。可选。如果指定,则在构建新容器时将验证校验和。如果没有指定,则不会验证下载的工件。不适用于 maven 工件类型。

字符串

insecure

默认情况下,验证使用 TLS 的连接来检查它们是否安全。使用的服务器证书必须是有效、可信,并且包含服务器名称。通过将此选项设置为 true,禁用所有 TLS 验证,即使服务器被视为不安全,也会下载工件。

布尔值

type

必须是 jar

字符串

12.2.81. TgzArtifact 模式参考

使用的: 插件

属性Description

url

要下载的构件的 URL。AMQ Streams 不执行下载工件的任何安全扫描。为安全起见,您应该首先手动验证工件并配置 checksum 验证,以确保自动构建中使用相同的工件。jarziptgz 和其他 工件是必需的。不适用于 maven 工件类型。

字符串

sha512sum

工件的 SHA512 校验和。可选。如果指定,则在构建新容器时将验证校验和。如果没有指定,则不会验证下载的工件。不适用于 maven 工件类型。

字符串

insecure

默认情况下,验证使用 TLS 的连接来检查它们是否安全。使用的服务器证书必须是有效、可信,并且包含服务器名称。通过将此选项设置为 true,禁用所有 TLS 验证,即使服务器被视为不安全,也会下载工件。

布尔值

type

必须为 tgz

字符串

12.2.82. ZipArtifact 模式参考

使用的: 插件

属性Description

url

要下载的构件的 URL。AMQ Streams 不执行下载工件的任何安全扫描。为安全起见,您应该首先手动验证工件并配置 checksum 验证,以确保自动构建中使用相同的工件。jarziptgz 和其他 工件是必需的。不适用于 maven 工件类型。

字符串

sha512sum

工件的 SHA512 校验和。可选。如果指定,则在构建新容器时将验证校验和。如果没有指定,则不会验证下载的工件。不适用于 maven 工件类型。

字符串

insecure

默认情况下,验证使用 TLS 的连接来检查它们是否安全。使用的服务器证书必须是有效、可信,并且包含服务器名称。通过将此选项设置为 true,禁用所有 TLS 验证,即使服务器被视为不安全,也会下载工件。

布尔值

type

必须为 zip.

字符串

12.2.83. MavenArtifact 模式参考

使用的: 插件

type 属性是一个标尺,用于区分 MavenArtifact 类型与 JarArtifactTgzArtifactZipArtifact OtherArtifact.它必须具有 MavenArtifact 类型的值 maven

属性Description

软件仓库

用于从中下载工件的 Maven 存储库。仅适用于 maven 工件类型。

字符串

group

Maven 组 ID.仅适用于 maven 工件类型。

字符串

工件

Maven 工件 ID。仅适用于 maven 工件类型。

字符串

version

Maven 版本号。仅适用于 maven 工件类型。

字符串

type

必须为 maven

字符串

12.2.84. OtherArtifact 模式参考

使用的: 插件

属性Description

url

要下载的构件的 URL。AMQ Streams 不执行下载工件的任何安全扫描。为安全起见,您应该首先手动验证工件并配置 checksum 验证,以确保自动构建中使用相同的工件。jarziptgz 和其他 工件是必需的。不适用于 maven 工件类型。

字符串

sha512sum

工件的 SHA512 校验和。可选。如果指定,则在构建新容器时将验证校验和。如果没有指定,则不会验证下载的工件。不适用于 maven 工件类型。

字符串

fileName

将在其中存储工件的名称。

字符串

insecure

默认情况下,验证使用 TLS 的连接来检查它们是否安全。使用的服务器证书必须是有效、可信,并且包含服务器名称。通过将此选项设置为 true,禁用所有 TLS 验证,即使服务器被视为不安全,也会下载工件。

布尔值

type

必须是 其他

字符串

12.2.85. KafkaConnectStatus schema 参考

使用的: KafkaConnect

属性Description

conditions

状态条件列表。

状况 数组

observedGeneration

Operator 最后协调的 CRD 的生成。

整数

url

用于管理和监控 Kafka 连接连接器的 REST API 端点的 URL。

字符串

connectorPlugins

此 Kafka Connect 部署中的连接器插件列表。

ConnectorPlugin 数组

labelSelector

提供此资源的 pod 的标签选择器。

字符串

replicas

提供此资源的当前 pod 数量。

整数

12.2.86. ConnectorPlugin schema 参考

使用的: KafkaConnectStatus, KafkaMirrorMaker2Status

属性Description

type

连接器插件的类型。可用的类型是 sink

字符串

version

连接器插件的版本。

字符串

连接器插件的类。

字符串

12.2.87. KafkaTopic 模式参考

属性Description

spec

主题的规格。

KafkaTopicSpec

status

主题的状态。

KafkaTopicStatus

12.2.88. KafkaTopicSpec 模式参考

使用的: KafkaTopic

属性Description

分区

主题应具有的分区数量。这无法在创建主题后减少。可在创建主题后增加它,但务必要了解具有的后果,特别是与语义分区相关的主题。如果不存在,则默认使用 num.partitions 的代理配置。

整数

replicas

主题应具有的副本数。如果不存在,则这个代理配置将默认为 default.replication.factor

整数

config

主题配置。

map

topicName

主题的名称。如果不存在,则默认为主题的 metadata.name。建议不要设置此项,除非主题名称不是有效的 OpenShift 资源名称。

字符串

12.2.89. KafkaTopicStatus 模式参考

使用的: KafkaTopic

属性Description

conditions

状态条件列表。

状况 数组

observedGeneration

Operator 最后协调的 CRD 的生成。

整数

topicName

主题名称。

字符串

12.2.90. KafkaUser 模式参考

属性Description

spec

用户的规格。

KafkaUserSpec

status

Kafka 用户的状态。

KafkaUserStatus

12.2.91. KafkaUserSpec 模式参考

使用的: KafkaUser

属性Description

身份验证

此 Kafka 用户启用了验证机制。支持的验证机制有 scram-sha-512tlstls-external

  • SCRAM -sha-512 生成带有 SASL SCRAM-SHA-512 凭据的 secret。
  • TLS 为 mutual TLS 身份验证生成包含用户证书的 secret。
  • TLS-external 不会生成用户证书。但使用 User Operator 之外生成的用户证书准备使用 mutual TLS 身份验证的用户准备。为此用户设置的 ACL 和配额采用 CN=<username&gt; 格式进行配置。

身份验证是可选的。如果没有配置身份验证,则不会生成任何凭证。为用户设置的 ACL 和配额以 < username> 格式配置用于 SASL 身份验证。类型取决于给定对象中的 authentication.type 属性的值,它必须是 [tls、tls-external、scram-sha-512] 之一。

KafkaUserTlsClientAuthentication, KafkaUserTlsExternalClientAuthentication, KafkaUserScramSha512ClientAuthentication

授权

此 Kafka 用户的授权规则。类型取决于给定对象中的 authorization.type 属性的值,它必须是 [simple] 中的一个。

KafkaUserAuthorizationSimple

配额

用于控制客户端使用的代理资源的请求的配额。可以强制使用网络带宽和请求率配额。Kafka 用户配额的Kafka 文档可在 http://kafka.apache.org/documentation/#design_quotas 中找到。

KafkaUserQuotas

模板

模板来指定 Kafka 用户 Secret 的 生成方式。

KafkaUserTemplate

12.2.92. KafkaUserTlsClientAuthentication 模式参考

使用的: KafkaUserSpec

type 属性是一种差异性,用于区分 KafkaUserTlsClientAuthentication 类型来自于 KafkaUserTlsExternalClientAuthentication, KafkaUserScramSha512ClientAuthentication。对于类型 KafkaUserTlsClientAuthentication,它需要是值 tls

属性Description

type

必须为 tls

字符串

12.2.93. KafkaUserTlsExternalClientAuthentication 模式参考

使用的: KafkaUserSpec

type 属性是一个差异性,用于区分 KafkaUserTlsExternalClientAuthentication 类型来自 KafkaUserTlsClientAuthentication, KafkaUserScramSha512ClientAuthentication。它必须拥有类型为 KafkaUserTlsExternalClientAuthentication 的值 tls-external

属性Description

type

必须是 tls-external

字符串

12.2.94. KafkaUserScramSha512ClientAuthentication 架构参考

使用的: KafkaUserSpec

type 属性是一种差异性,用于区分来自 KafkaUserTlsClientAuthenticationKafkaUserScramSha512ClientAuthentication 类型,即 KafkaUserTlsExternalClientAuthentication。它必须值为 scram-sha-512 类型,类型为 KafkaUserScramSha512ClientAuthentication

属性Description

password

指定用户的密码。如果没有设置,则 User Operator 会生成一个新密码。

密码

type

必须为 scram-sha-512

字符串

12.2.95. 密码 架构参考

使用的: KafkaUserScramSha512ClientAuthentication

属性Description

valueFrom

应该从中读取密码的机密。

PasswordSource

12.2.96. PasswordSource 模式参考

使用的: 密码

属性Description

secretKeyRef

在资源命名空间中选择 Secret 的键。如需更多信息,请参阅 core/v1 secretkeyselector 的外部文档

SecretKeySelector

12.2.97. KafkaUserAuthorizationSimple 模式参考

使用的: KafkaUserSpec

type 属性是一种分ator,用于区分使用 KafkaUserAuthorizationSimple 的子类型,它可能会在以后添加。它必须使类型 KafkaUserAuthorizationSimple 的值 很简单

属性Description

type

必须 非常简单

字符串

ACL

应用于此用户的 ACL 规则列表。

AclRule 数组

12.2.98. AclRule 模式参考

使用的: KafkaUserAuthorizationSimple

AclRule 模式属性的完整列表

在使用 AclAuthorizer 时,为 KafkaUser 配置访问控制规则。

使用授权的 KafkaUser 配置示例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaUser
metadata:
  name: my-user
  labels:
    strimzi.io/cluster: my-cluster
spec:
  # ...
  authorization:
    type: simple
    acls:
      - resource:
          type: topic
          name: my-topic
          patternType: literal
        operation: Read
      - resource:
          type: topic
          name: my-topic
          patternType: literal
        operation: Describe
      - resource:
          type: group
          name: my-group
          patternType: prefix
        operation: Read

12.2.98.1. resource

使用 resource 属性指定规则应用到的资源。

简单授权支持四种资源类型,这些资源类型在 type 属性中指定:

  • 主题(主题)
  • 消费者组()
  • 集群(集群)
  • 事务 ID (事务 ID)

对于主题、组和事务 ID 资源,您可以在 name 属性中指定规则应用到的 资源的名称

集群类型资源没有名称。

名称使用 patternType 属性指定为 字面前缀

  • 字面上的名称与在 name 字段中指定的名称完全相同。
  • 前缀名称使用 name 值作为前缀,然后将该规则应用到名称以该值开头的所有资源。

patternType 设置为 字面值 时,您可以将 name 设置为 * 以表示规则适用于所有资源。

允许用户读取所有主题的消息的 ACL 规则示例

    acls:
      - resource:
          type: topic
          name: "*"
          patternType: literal
        operation: Read

12.2.98.2. type

规则类型,用于 允许拒绝 (当前不支持)操作。

type 字段是可选的。如果未指定 类型,则 ACL 规则将被视为 允许规则

12.2.98.3. operation

为规则指定 operation 来允许或拒绝操作。

支持以下操作:

  • 删除
  • 改变
  • describe
  • All
  • IdempotentWrite
  • ClusterAction
  • 创建
  • AlterConfigs
  • DescribeConfigs

只有某些操作都用于每个资源。

有关 AclAuthorizer、ACL 和支持的资源和操作组合的更多信息,请参阅 授权和 ACL

12.2.98.4. 主机

使用 host 属性指定允许或拒绝规则的远程主机。

使用星号(*)来允许或拒绝来自所有主机的操作。host 字段是可选的。如果未指定 主机,则默认使用 * 值。

12.2.98.5. AclRule 模式属性
属性Description

主机

允许或拒绝 ACL 规则中描述的操作的主机。

字符串

operation

允许或拒绝的操作.支持的操作包括:读取、写入、创建、删除、Alt、描述、ClusterAction、AlterConfigs、DescribeConfigs、IdempotentWrite 和 All。

字符串(一个 [Read, Write, Delete, Alter, Describe, All, IdempotentWrite, ClusterAction, Create, AlterConfigs, DescribeConfigs])

resource

指明应用给定 ACL 规则的资源。这个类型取决于给定对象中的 resource.type 属性的值,它必须是 [topic、group、cluster, transactionalId] 中的一个。

AclRuleTopicResource, AclRuleGroupResource, AclRuleClusterResource, AclRuleTransactionalIdResource

type

规则的类型。目前唯一支持的类型是 允许。带有类型 allow 的 ACL 规则允许用户执行指定的操作。默认值为 允许

字符串([allow、deny] 之一)

12.2.99. AclRuleTopicResource 模式参考

使用的: AclRule

type 属性是一种差异性,用于区分来自 AclRuleTopicResourceAclRuleTopicResource 类型、AclRuleClusterResourceAclRuleTransactionalIdResource。它必须具有类型 AclRuleTopicResource 的值 主题

属性Description

type

必须为 主题

字符串

name

应用给定 ACL 规则的资源名称。可以和 patternType 字段组合使用前缀模式。

字符串

patternType

描述 resource 字段中使用的模式。支持的类型是 字面值前缀。通过 字面 模式类型,资源字段将用作完整主题名称的定义。使用 前缀 模式类型时,资源名称将仅用作前缀。默认值为 literal

字符串([前缀、字面] 之一)

12.2.100. AclRuleGroupResource 模式参考

使用的: AclRule

type 属性是一种差异性,用于区分来自 AclRuleTopicResourceAclRuleGroupResource 类型、AclRuleClusterResourceAclRuleTransactionalIdResource。它必须具有类型 AclRuleGroupResource 的值

属性Description

type

必须为

字符串

name

应用给定 ACL 规则的资源名称。可以和 patternType 字段组合使用前缀模式。

字符串

patternType

描述 resource 字段中使用的模式。支持的类型是 字面值前缀。通过 字面 模式类型,资源字段将用作完整主题名称的定义。使用 前缀 模式类型时,资源名称将仅用作前缀。默认值为 literal

字符串([前缀、字面] 之一)

12.2.101. AclRuleClusterResource 模式参考

使用的: AclRule

type 属性是一个差异性符,用于区分来自 AclRuleTopicResourceAclRuleClusterResource 类型、AclRuleGroupResourceAclRuleTransactionalIdResource。对于类型 AclRuleClusterResource,它需要值 cluster

属性Description

type

必须是 集群

字符串

12.2.102. AclRuleTransactionalIdResource schema 参考

使用的: AclRule

type 属性是一种差异性,用于区分来自 AclRuleTransactionalIdResourceAclRuleTransactionalIdResourceAclRuleGroupResourceAclRuleClusterResource。对于类型 AclRuleTransactionalIdResource,它必须是值 transactionalId

属性Description

type

必须是 transactionalId

字符串

name

应用给定 ACL 规则的资源名称。可以和 patternType 字段组合使用前缀模式。

字符串

patternType

描述 resource 字段中使用的模式。支持的类型是 字面值前缀。通过 字面 模式类型,资源字段将用作全名的定义。使用 前缀 模式类型时,资源名称将仅用作前缀。默认值为 literal

字符串([前缀、字面] 之一)

12.2.103. KafkaUserQuotas 模式参考

使用的: KafkaUserSpec

KafkaUserQuotas 模式属性的完整列表

Kafka 允许用户 设置配额 来控制客户端的资源使用。

12.2.103.1. quotas

您可以将客户端配置为使用以下类型的配额:

  • 网络使用 配额为每个共享配额的客户端组指定字节速率阈值。
  • CPU 使用率配额为来自客户端的代理请求指定一个窗口。该窗口是客户端发出请求的时间百分比。客户端对代理的 I/O 线程和网络线程发出请求。
  • 分区数 可限制允许哪些客户端每秒制作的分区数。

分区数配额可防止 Kafka 集群由并发主题操作不堪。根据以下用户请求类型,进行分区修改:

  • 为新主题创建分区
  • 在现有主题中添加分区
  • 从主题中删除分区

您可以配置分区变异配额来控制用户请求接受修改率。

在很多情况下,对 Kafka 客户端使用配额可能很有用。例如,一个错误地配置了 Kafka producer,请求以太高速率发送。这种错误配置可能会导致其他客户端拒绝服务,因此无法阻止有问题的客户端。通过使用网络限制配额,可以防止这种情况对其他客户端产生显著影响。

AMQ Streams 支持用户级配额,但不支持客户端级配额。

Kafka 用户配额配置示例

spec:
  quotas:
    producerByteRate: 1048576
    consumerByteRate: 2097152
    requestPercentage: 55
    controllerMutationRate: 10

有关 Kafka 用户配额的更多信息,请参阅 Apache Kafka 文档

12.2.103.2. KafkaUserQuotas 模式属性
属性Description

consumerByteRate

每个客户端组都可以从代理获取的最大字节配额,然后再对组中的客户端进行限速。以每个代理为基础进行定义。

整数

controllerMutationRate

创建主题请求、创建分区请求和删除主题请求的速率的配额。速率由创建或删除的分区数量计算。

number

producerByteRate

每个客户端组可以发布到代理,每个客户端组群在组内的客户端被限速前可以发布到代理的配额。以每个代理为基础进行定义。

整数

requestPercentage

每个客户端组的最大 CPU 使用率配额,作为网络和 I/O 线程百分比。

整数

12.2.104. KafkaUserTemplate 模式参考

使用的: KafkaUserSpec

KafkaUserTemplate 模式属性的完整列表

为 User Operator 创建的 secret 指定额外标签和注解。

显示 KafkaUserTemplate的示例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaUser
metadata:
  name: my-user
  labels:
    strimzi.io/cluster: my-cluster
spec:
  authentication:
    type: tls
  template:
    secret:
      metadata:
        labels:
          label1: value1
        annotations:
          anno1: value1
  # ...

12.2.104.1. KafkaUserTemplate 模式属性
属性Description

secret

KafkaUser 资源的模板。通过该模板,用户可以指定如何生成带有密码或 TLS 证书的 Secret

resourcetemplate

12.2.105. KafkaUserStatus schema 参考

使用的: KafkaUser

属性Description

conditions

状态条件列表。

状况 数组

observedGeneration

Operator 最后协调的 CRD 的生成。

整数

username

用户名。

字符串

secret

存储凭证的 Secret 的名称。

字符串

12.2.106. KafkaMirrorMaker 模式参考

KafkaMirrorMaker 类型已弃用。请使用 KafkaMirrorMaker2 替代。

属性Description

spec

Kafka MirrorMaker 的规格。

KafkaMirrorMakerSpec

status

Kafka MirrorMaker 的状态。

KafkaMirrorMakerStatus

12.2.107. KafkaMirrorMakerSpec 模式参考

使用的: KafkaMirrorMaker

KafkaMirrorMakerSpec schema 属性的完整列表

配置 Kafka MirrorMaker。

12.2.107.1. Include

使用 include 属性配置 Kafka MirrorMaker 镜像从源到目标 Kafka 集群的主题列表。

属性允许最简单的情况下,具有单一主题名称到复杂的模式的任何正则表达式。例如,您可以使用 A|B 或所有主题使用 * 镜像主题 A 和 B。您还可以将用逗号分开的多个正则表达式传递给 Kafka MirrorMaker。

12.2.107.2. KafkaMirrorMakerConsumerSpecKafkaMirrorMakerProducerSpec

使用 KafkaMirrorMakerConsumerSpecKafkaMirrorMakerProducerSpec 配置源(consumer)和目标(producer)集群。

Kafka MirrorMaker 始终与两个 Kafka 集群(源和目标集群)一起工作。要建立连接,源的 bootstrap 服务器和目标 Kafka 集群以逗号分隔的 HOSTNAME:PORT 对列表来指定。每个以逗号分隔的列表包含一个或多个 Kafka 代理,或一个 Kafka 代理指定的 Service 分区作为 HOSTNAME:PORT 对。

12.2.107.3. logging

Kafka MirrorMaker 都有自己的可配置的日志记录器:

  • mirrormaker.root.logger

MirrorMaker 使用 Apache log4j 日志记录器实现。

使用 logging 属性配置日志记录器和日志记录器级别。

您可以通过直接指定日志记录器和级别(在线)或使用自定义(外部) ConfigMap 来设置日志级别。如果使用 ConfigMap,您可以将 logging.valueFrom.configMapKeyRef.name 属性设置为包含外部日志记录配置的 ConfigMap 的名称。在 ConfigMap 中,日志记录配置使用 log4j.properties 来描述。logging.valueFrom.configMapKeyRef.namelogging.valueFrom.configMapKeyRef.key 属性都是必须的。当 Cluster Operator 运行时,会使用指定的日志记录配置创建 ConfigMap,然后在每次协调后重新创建。如果没有指定自定义 ConfigMap,则会使用默认的日志记录设置。如果没有设置特定的日志记录器值,则会继承该日志记录器的上级日志记录器设置。有关日志级别的更多信息,请参阅 Apache 日志记录服务

此处会看到 内联外部日志记录 的示例:

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaMirrorMaker
spec:
  # ...
  logging:
    type: inline
    loggers:
      mirrormaker.root.logger: "INFO"
  # ...
apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaMirrorMaker
spec:
  # ...
  logging:
    type: external
    valueFrom:
      configMapKeyRef:
        name: customConfigMap
        key: mirror-maker-log4j.properties
  # ...

垃圾收集器(GC)

也可以使用 jvmOptions 属性 来启用(或禁用)垃圾收集器日志记录。

12.2.107.4. KafkaMirrorMakerSpec 模式属性
属性Description

version

Kafka MirrorMaker 版本。默认为 3.2.3。请参阅相关文档来了解升级或降级版本所需的流程。

字符串

replicas

部署中的 pod 数量

整数

image

pod 的 docker 镜像。

字符串

消费者

源集群的配置。

KafkaMirrorMakerConsumerSpec

制作者

目标集群的配置。

KafkaMirrorMakerProducerSpec

资源

要保留的 CPU 和内存资源。如需更多信息,请参阅 core/v1 资源查询的外部文档

ResourceRequirements

白名单

whitelist 属性已弃用,现在应该使用 spec.include 进行配置。镜像中包含的主题列表。此选项允许使用 Java 风格的正则表达式。使用表达式 A|B 来实现名为 A 和 B 的两个主题。或者,您可以使用正则表达式 * 来镜像所有主题。您还可以指定多个正则表达式用逗号分隔。

字符串

Include

镜像中包含的主题列表。此选项允许使用 Java 风格的正则表达式。使用表达式 A|B 来实现名为 A 和 B 的两个主题。或者,您可以使用正则表达式 * 来镜像所有主题。您还可以指定多个正则表达式用逗号分隔。

字符串

jvmOptions

pod 的 JVM 选项。

JvmOptions

logging

MirrorMaker 的日志记录配置。类型取决于给定对象中的 logging.type 属性的值,它必须是 [inline, external] 中的一个。

InlineLogging, ExternalLogging

metricsConfig

指标配置。这个类型取决于给定对象中的 metricsConfig.type 属性的值,它必须是 [jmxPrometheusExporter] 之一。

JmxPrometheusExporterMetrics

tracing

Kafka MirrorMaker 中的追踪配置。类型取决于给定对象中的 tracing.type 属性的值,它必须是 [jaeger] 中的一个。

Jaegertracing

模板

模板来指定 Kafka MirrorMaker 资源、DeploymentPod 如何生成。

KafkaMirrorMakerTemplate

livenessProbe

Pod 存活度检查。

探测

readinessProbe

Pod 就绪度检查.

探测

12.2.108. KafkaMirrorMakerConsumerSpec 模式参考

使用的: KafkaMirrorMakerSpec

KafkaMirrorMakerConsumerSpec schema 属性的完整列表

配置 MirrorMaker consumer。

12.2.108.1. numStreams

使用 consumer.numStreams 属性配置消费者的流数。

您可以通过增加消费者线程数量来增加镜像主题的吞吐量。使用者线程属于为 Kafka MirrorMaker 指定的使用者组。在消费者线程中分配主题分区,这些分区会并行使用信息。

12.2.108.2. offsetCommitInterval

使用 consumer.offsetCommitInterval 属性为使用者配置偏移自动提交间隔。

您可以指定在 Kafka MirrorMaker 消耗源 Kafka 集群的数据后提交偏移的时间间隔。时间间隔以毫秒为单位设置,默认值为 60,000。

12.2.108.3. config

使用 consumer.config 属性为使用者配置 Kafka 选项。

config 属性包含 Kafka MirrorMaker consumer 配置选项作为键,其值为以下 JSON 类型之一:

  • 字符串
  • Number
  • 布尔值

对于将特定 密码套件 用于 TLS 版本的客户端连接,您可以配置允许的 ssl 属性您还可以配置 ssl.endpoint.identification.algorithm 属性 来启用或禁用主机名验证。

例外

您可以为使用者指定并配置 Apache Kafka 配置文档 中列出的选项。

但是,选项的例外会直接由 AMQ Streams (与以下相关的 AMQ Streams)进行配置和管理:

  • Kafka 集群 bootstrap 地址
  • 安全(加密、验证和授权)
  • 消费者组标识符
  • 拦截器

具体来说,所有与以下字符串之一相等或开始的配置选项都会被禁止:

当在 config 属性中存在禁止选项时,它会被忽略,并将警告消息输出到 Cluster Operator 日志文件。所有其他选项都传递给 Kafka MirrorMaker。

重要

Cluster Operator 不会验证提供的 config 对象中的键或值。当提供无效的配置时,Kafka MirrorMaker 可能无法启动,也可能不稳定。在这种情况下,KafkaMirrorMaker.spec.consumer.config 对象中的配置应该被修复,Cluster Operator 将推出 Kafka MirrorMaker 的新配置。

12.2.108.4. groupId

使用 consumer.groupId 属性为使用者配置使用者组标识符。

Kafka MirrorMaker 使用 Kafka 使用者来消耗信息,这与任何其他 Kafka 消费者客户端相同。源 Kafka 集群消耗的消息被镜像到目标 Kafka 集群。需要组标识符,因为使用者需要是分配分区的使用者组的一部分。

12.2.108.5. KafkaMirrorMakerConsumerSpec schema 属性
属性Description

numStreams

指定要创建的消费者流线程数量。

整数

offsetCommitInterval

指定 ms 中的偏移 auto-commit 间隔。默认值为 60000。

整数

bootstrapServers

用于建立到 Kafka 集群的初始连接的 host:port 对列表。

字符串

groupId

标识此使用者所属的消费者组的唯一字符串。

字符串

身份验证

用于连接到集群的身份验证配置。这个类型取决于给定对象中的 authentication.type 属性的值,它必须是 [tls, scram-sha-256, scram-sha-256, scram-sha-512, plain, oauth]。

KafkaClientAuthenticationTls, KafkaClientAuthenticationScramSha256, KafkaClientAuthenticationScramSha512, KafkaClientAuthenticationPlain, KafkaClientAuthenticationOAuth

config

MirrorMaker 使用者配置。无法设置以下前缀的属性: ssl., bootstrap.servers, group.id, sasl., security., interceptor.classes (有: ssl.endpoint.identification.algorithm、ssl.cipher.suites、ssl.protocol、ssl.enabled.protocols)。

map

tls

用于将 MirrorMaker 连接到集群的 TLS 配置。

ClientTls

12.2.109. KafkaMirrorMakerProducerSpec 模式参考

使用的: KafkaMirrorMakerSpec

KafkaMirrorMakerProducerSpec 模式属性的完整列表

配置 MirrorMaker producer。

12.2.109.1. abortOnSendFailure

使用 producer.abortOnSendFailure 属性配置如何处理来自制作者的消息发送失败。

默认情况下,如果将消息从 Kafka MirrorMaker 发送到 Kafka 集群时出现错误:

  • Kafka MirrorMaker 容器在 OpenShift 中终止。
  • 然后,重新创建容器。

如果将 abortOnSendFailure 选项设为 false,则忽略消息发送错误。

12.2.109.2. config

使用 producer.config 属性为制作者配置 Kafka 选项。

config 属性包含 Kafka MirrorMaker producer 配置选项作为键,值在以下 JSON 类型中设置的值:

  • 字符串
  • Number
  • 布尔值

对于将特定 密码套件 用于 TLS 版本的客户端连接,您可以配置允许的 ssl 属性您还可以配置 ssl.endpoint.identification.algorithm 属性 来启用或禁用主机名验证。

例外

您可以为制作者指定并配置 Apache Kafka 配置文档中列出的选项

但是,选项的例外会直接由 AMQ Streams (与以下相关的 AMQ Streams)进行配置和管理:

  • Kafka 集群 bootstrap 地址
  • 安全(加密、验证和授权)
  • 拦截器

具体来说,所有与以下字符串之一相等或开始的配置选项都会被禁止:

当在 config 属性中存在禁止选项时,它会被忽略,并将警告消息输出到 Cluster Operator 日志文件。所有其他选项都传递给 Kafka MirrorMaker。

重要

Cluster Operator 不会验证提供的 config 对象中的键或值。当提供无效的配置时,Kafka MirrorMaker 可能无法启动,也可能不稳定。在这种情况下,KafkaMirrorMaker.spec.producer.config 对象中的配置应该被修复,Cluster Operator 将推出 Kafka MirrorMaker 的新配置。

12.2.109.3. KafkaMirrorMakerProducerSpec schema 属性
属性Description

bootstrapServers

用于建立到 Kafka 集群的初始连接的 host:port 对列表。

字符串

abortOnSendFailure

将 MirrorMaker 设置为在失败的发送中退出的标志。默认值为 true

布尔值

身份验证

用于连接到集群的身份验证配置。这个类型取决于给定对象中的 authentication.type 属性的值,它必须是 [tls, scram-sha-256, scram-sha-256, scram-sha-512, plain, oauth]。

KafkaClientAuthenticationTls, KafkaClientAuthenticationScramSha256, KafkaClientAuthenticationScramSha512, KafkaClientAuthenticationPlain, KafkaClientAuthenticationOAuth

config

MirrorMaker producer 配置。无法设置以下前缀的属性: ssl., bootstrap.servers, sasl., security., interceptor.classes (例外: ssl.endpoint.identification.algorithm, ssl.cipher.suites, ssl.protocol, ssl.enabled.protocols)。

map

tls

用于将 MirrorMaker 连接到集群的 TLS 配置。

ClientTls

12.2.110. KafkaMirrorMakerTemplate 模式参考

使用的: KafkaMirrorMakerSpec

属性Description

部署

Kafka MirrorMaker Deployment 模板。

DeploymentTemplate

Pod

Kafka MirrorMaker Pod 模板。

PodTemplate

podDisruptionBudget

Kafka MirrorMaker PodDisruptionBudget 模板。

PodDisruptionBudgetTemplate

mirrorMakerContainer

Kafka MirrorMaker 容器的模板。

ContainerTemplate

serviceAccount

Kafka MirrorMaker 服务帐户的模板。

resourcetemplate

12.2.111. KafkaMirrorMakerStatus 模式参考

使用的: KafkaMirrorMaker

属性Description

conditions

状态条件列表。

状况 数组

observedGeneration

Operator 最后协调的 CRD 的生成。

整数

labelSelector

提供此资源的 pod 的标签选择器。

字符串

replicas

提供此资源的当前 pod 数量。

整数

12.2.112. KafkaBridge 模式参考

属性Description

spec

Kafka Bridge 的规格。

KafkaBridgeSpec

status

Kafka Bridge 的状态。

KafkaBridgeStatus

12.2.113. KafkaBridgeSpec 模式参考

使用的: KafkaBridge

KafkaBridgeSpec schema 属性的完整列表

配置 Kafka Bridge 集群。

配置选项与:

  • Kafka 集群 bootstrap 地址
  • 安全(加密、验证和授权)
  • 消费者配置
  • 制作者配置
  • HTTP 配置
12.2.113.1. logging

Kafka Bridge 具有自己的可配置的日志记录器:

  • logger.bridge
  • logger.<operation-id>

您可以替换 logger.<operation-id> logger 中的 <operation-id> 来为特定操作设置日志级别:

  • createConsumer
  • deleteConsumer
  • subscribe
  • unsubscribe
  • poll
  • 分配
  • commit
  • send
  • sendToPartition
  • seekToBeginning
  • seekToEnd
  • seek
  • healthy
  • ready
  • openapi

每个操作都根据 OpenAPI 规格定义,具有桥接从 HTTP 客户端接收请求对应的 API 端点。您可以更改每个端点上的日志级别,以创建有关传入和传出的 HTTP 请求的精细日志信息。

每个日志记录器都必须配置为为它分配一个 name 作为 http.openapi.operation.<operation-id>。例如,为 发送 操作日志记录器配置日志级别意味着定义以下内容:

logger.send.name = http.openapi.operation.send
logger.send.level = DEBUG

Kafka Bridge 使用 Apache log4j2 日志记录器实现。日志记录器在 log4j2.properties 文件中定义,该文件对 healthyready 端点有以下默认配置:

logger.healthy.name = http.openapi.operation.healthy
logger.healthy.level = WARN
logger.ready.name = http.openapi.operation.ready
logger.ready.level = WARN

所有其他操作的日志级别默认设置为 INFO

使用 logging 属性配置日志记录器和日志记录器级别。

您可以通过直接指定日志记录器和级别(在线)或使用自定义(外部) ConfigMap 来设置日志级别。如果使用 ConfigMap,您可以将 logging.valueFrom.configMapKeyRef.name 属性设置为包含外部日志记录配置的 ConfigMap 的名称。logging.valueFrom.configMapKeyRef.namelogging.valueFrom.configMapKeyRef.key 属性是必需的。如果没有设置 namekey,则会使用默认日志记录。在 ConfigMap 中,日志记录配置使用 log4j.properties 来描述。有关日志级别的更多信息,请参阅 Apache 日志记录服务

此处会看到 内联外部日志记录 的示例。

内联日志

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaBridge
spec:
  # ...
  logging:
    type: inline
    loggers:
      logger.bridge.level: "INFO"
      # enabling DEBUG just for send operation
      logger.send.name: "http.openapi.operation.send"
      logger.send.level: "DEBUG"
  # ...

外部日志记录

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaBridge
spec:
  # ...
  logging:
    type: external
    valueFrom:
      configMapKeyRef:
        name: customConfigMap
        key: bridge-logj42.properties
  # ...

任何尚未配置级别的可用日志记录器都设置为 OFF

如果使用 Cluster Operator 部署 Kafka Bridge,则会动态应用对 Kafka Bridge 日志记录级别的更改。

如果使用外部日志记录,则在日志附加器更改时触发滚动更新。

垃圾收集器(GC)

也可以使用 jvmOptions 属性 来启用(或禁用)垃圾收集器日志记录。

12.2.113.2. KafkaBridgeSpec 模式属性
属性Description

replicas

部署中的 pod 数量

整数

image

pod 的 docker 镜像。

字符串

bootstrapServers

用于建立到 Kafka 集群的初始连接的 host:port 对列表。

字符串

tls

用于将 Kafka Bridge 连接到集群的 TLS 配置。

ClientTls

身份验证

用于连接到集群的身份验证配置。这个类型取决于给定对象中的 authentication.type 属性的值,它必须是 [tls, scram-sha-256, scram-sha-256, scram-sha-512, plain, oauth]。

KafkaClientAuthenticationTls, KafkaClientAuthenticationScramSha256, KafkaClientAuthenticationScramSha512, KafkaClientAuthenticationPlain, KafkaClientAuthenticationOAuth

http

HTTP 相关配置。

KafkaBridgeHttpConfig

adminClient

Kafka 管理与客户端相关的配置。

KafkaBridgeAdminClientSpec

消费者

Kafka 消费者相关的配置。

KafkaBridgeConsumerSpec

制作者

Kafka producer 相关配置。

KafkaBridgeProducerSpec

资源

要保留的 CPU 和内存资源。如需更多信息,请参阅 core/v1 资源查询的外部文档

ResourceRequirements

jvmOptions

目前,pod 支持 JVM 选项。

JvmOptions

logging

Kafka Bridge 的日志记录配置。类型取决于给定对象中的 logging.type 属性的值,它必须是 [inline, external] 中的一个。

InlineLogging, ExternalLogging

enableMetrics

为 Kafka Bridge 启用指标。默认为 false。

布尔值

livenessProbe

Pod 存活度检查。

探测

readinessProbe

Pod 就绪度检查.

探测

模板

Kafka Bridge 资源的模板。通过该模板,用户可以指定如何生成 DeploymentPod

KafkaBridgeTemplate

tracing

Kafka Bridge 中的追踪配置。类型取决于给定对象中的 tracing.type 属性的值,它必须是 [jaeger] 中的一个。

Jaegertracing

12.2.114. KafkaBridgeHttpConfig schema reference

使用的: KafkaBridgeSpec

KafkaBridgeHttpConfig 模式属性的完整列表

为 Kafka Bridge 配置对 Kafka 集群的 HTTP 访问。

默认 HTTP 配置是 Kafka Bridge 侦听端口 8080。

12.2.114.1. CORS

除了启用 HTTP 访问 Kafka 集群外,HTTP 属性提供通过 Cross-Origin Resource Sharing (CORS)为 Kafka 网桥启用和定义访问控制的功能。CORS 是一种 HTTP 机制,它允许浏览器从多个来源访问所选资源。要配置 CORS,您可以定义允许的资源来源和 HTTP 访问方法的列表。对于原始卷,您可以使用 URL 或 Java 正则表达式。

Kafka Bridge HTTP 配置示例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaBridge
metadata:
  name: my-bridge
spec:
  # ...
  http:
    port: 8080
    cors:
      allowedOrigins: "https://strimzi.io"
      allowedMethods: "GET,POST,PUT,DELETE,OPTIONS,PATCH"
  # ...

12.2.114.2. KafkaBridgeHttpConfig schema properties
属性Description

port

服务器侦听的端口。

整数

CORS

HTTP 网桥的 CORS 配置。

KafkaBridgeHttpCors

12.2.115. KafkaBridgeHttpCors 模式参考

使用的: KafkaBridgeHttpConfig

属性Description

allowedOrigins

允许的源列表。可以使用 Java 正则表达式。

字符串数组

allowedMethods

允许的 HTTP 方法列表。

字符串数组

12.2.116. KafkaBridgeAdminClientSpec schema reference

使用的: KafkaBridgeSpec

属性Description

config

用于该网桥创建的 AdminClient 实例的 Kafka AdminClient 配置。

map

12.2.117. KafkaBridgeConsumerSpec 模式参考

使用的: KafkaBridgeSpec

KafkaBridgeConsumerSpec 模式属性的完整列表

将 Kafka Bridge 的使用者选项配置为密钥。

这些值可以是以下 JSON 类型之一:

  • 字符串
  • Number
  • 布尔值

您可以为消费者指定并配置 Apache Kafka 配置文档中的 选项,但那些直接由 AMQ Streams 管理的选项除外。具体来说,所有与以下字符串之一相等或开始的配置选项都会被禁止:

  • SSL.
  • SASL:
  • 安全性.
  • bootstrap.servers
  • group.id

当在 config 属性中存在禁止选项时,它将忽略,并显示 Cluster Operator 日志文件的警告信息。所有其他选项将传递给 Kafka

重要

Cluster Operator 不验证 config 对象中的密钥或值。如果提供了无效的配置,则 Kafka Bridge 集群可能无法启动,也可能不稳定。修复配置,以便 Cluster Operator 可以向所有 Kafka Bridge 节点推出新配置。

禁止的选项有例外。对于将特定 密码套件 用于 TLS 版本的客户端连接,您可以配置允许的 ssl 属性

Kafka Bridge consumer 配置示例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaBridge
metadata:
  name: my-bridge
spec:
  # ...
  consumer:
    config:
      auto.offset.reset: earliest
      enable.auto.commit: true
      ssl.cipher.suites: "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384"
      ssl.enabled.protocols: "TLSv1.2"
      ssl.protocol: "TLSv1.2"
      ssl.endpoint.identification.algorithm: HTTPS
    # ...

12.2.117.1. KafkaBridgeConsumerSpec 模式属性
属性Description

config

用于该网桥创建的使用者实例的 Kafka 使用者配置。无法设置以下前缀的属性: ssl., bootstrap.servers, group.id, sasl., security. (例外: ssl.endpoint.identification.algorithm, ssl.cipher.suites, ssl.protocol, ssl.enabled.protocols)。

map

12.2.118. KafkaBridgeProducerSpec 模式参考

使用的: KafkaBridgeSpec

KafkaBridgeProducerSpec schema 属性的完整列表

将 Kafka Bridge 的制作者选项配置为密钥。

这些值可以是以下 JSON 类型之一:

  • 字符串
  • Number
  • 布尔值

您可以为制作者指定并配置 Apache Kafka 配置文档 中列出的选项,但那些直接由 AMQ Streams 管理的选项除外。具体来说,所有与以下字符串之一相等或开始的配置选项都会被禁止:

  • SSL.
  • SASL:
  • 安全性.
  • bootstrap.servers

当在 config 属性中存在禁止选项时,它将忽略,并显示 Cluster Operator 日志文件的警告信息。所有其他选项将传递给 Kafka

重要

Cluster Operator 不验证 config 对象中的密钥或值。如果提供了无效的配置,则 Kafka Bridge 集群可能无法启动,也可能不稳定。修复配置,以便 Cluster Operator 可以向所有 Kafka Bridge 节点推出新配置。

禁止的选项有例外。对于将特定 密码套件 用于 TLS 版本的客户端连接,您可以配置允许的 ssl 属性

Kafka Bridge producer 配置示例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaBridge
metadata:
  name: my-bridge
spec:
  # ...
  producer:
    config:
      acks: 1
      delivery.timeout.ms: 300000
      ssl.cipher.suites: "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384"
      ssl.enabled.protocols: "TLSv1.2"
      ssl.protocol: "TLSv1.2"
      ssl.endpoint.identification.algorithm: HTTPS
    # ...

12.2.118.1. KafkaBridgeProducerSpec 模式属性
属性Description

config

供网桥创建的制作者实例的 Kafka producer 配置。无法设置以下前缀的属性: ssl.、bootstrap.servers、sasl.、security. (但 ssl.endpoint.identification.algorithm、ssl.cipher.suites、ssl.protocol、ssl.enabled.protocols)。

map

12.2.119. KafkaBridgeTemplate 模式参考

使用的: KafkaBridgeSpec

属性Description

部署

Kafka Bridge Deployment 的模板。

DeploymentTemplate

Pod

Kafka Bridge Pod 模板。

PodTemplate

apiService

Kafka Bridge API Service 的模板。

InternalServiceTemplate

podDisruptionBudget

Kafka Bridge PodDisruptionBudget 模板。

PodDisruptionBudgetTemplate

bridgeContainer

Kafka Bridge 容器的模板。

ContainerTemplate

serviceAccount

Kafka Bridge 服务帐户的模板。

resourcetemplate

12.2.120. KafkaBridgeStatus schema reference

使用的: KafkaBridge

属性Description

conditions

状态条件列表。

状况 数组

observedGeneration

Operator 最后协调的 CRD 的生成。

整数

url

外部客户端应用程序可以访问 Kafka Bridge 的 URL。

字符串

labelSelector

提供此资源的 pod 的标签选择器。

字符串

replicas

提供此资源的当前 pod 数量。

整数

12.2.121. KafkaConnector 模式参考

属性Description

spec

Kafka Connector 的规格。

KafkaConnectorSpec

status

Kafka Connector 的状态。

KafkaConnectorStatus

12.2.122. KafkaConnectorSpec 模式参考

使用的: KafkaConnector

属性Description

Kafka Connector 的类。

字符串

tasksMax

Kafka Connector 的最大任务数量。

整数

config

Kafka Connector 配置。无法设置以下属性:connector.class, tasks.max。

map

pause

连接器是否应暂停。默认为false。

布尔值

12.2.123. KafkaConnectorStatus schema 参考

使用的: KafkaConnector

属性Description

conditions

状态条件列表。

状况 数组

observedGeneration

Operator 最后协调的 CRD 的生成。

整数

connectorStatus

连接器状态,如 Kafka Connect REST API 报告。

map

tasksMax

Kafka Connector 的最大任务数量。

整数

主题

Kafka Connector 使用的主题列表。

字符串数组

12.2.124. KafkaMirrorMaker2 模式参考

属性Description

spec

Kafka MirrorMaker 2.0 集群的规格。

KafkaMirrorMaker2Spec

status

Kafka MirrorMaker 2.0 集群的状态。

KafkaMirrorMaker2Status

12.2.125. KafkaMirrorMaker2Spec 模式参考

使用的: KafkaMirrorMaker2

属性Description

version

Kafka Connect 版本。默认为 3.2.3。参阅用户文档来了解升级或降级版本所需的流程。

字符串

replicas

Kafka Connect 组中的 pod 数量。

整数

image

pod 的 docker 镜像。

字符串

connectCluster

用于 Kafka Connect 的集群别名。别名必须与位于 spec.clusters 的列表中有一个集群匹配。

字符串

clusters

用于镜像的 Kafka 集群。

KafkaMirrorMaker2ClusterSpec 数组

mirrors

配置 MirrorMaker 2.0 连接器。

KafkaMirrorMaker2MirrorSpec 数组

资源

CPU 和内存资源和请求的初始资源的最大限制。如需更多信息,请参阅 core/v1 资源查询的外部文档

ResourceRequirements

livenessProbe

Pod 存活度检查。

探测

readinessProbe

Pod 就绪度检查.

探测

jvmOptions

pod 的 JVM 选项。

JvmOptions

jmxOptions

JMX 选项.

KafkaJmxOptions

logging

Kafka Connect 的日志记录配置。类型取决于给定对象中的 logging.type 属性的值,它必须是 [inline, external] 中的一个。

InlineLogging, ExternalLogging

clientRackInitImage

用于初始化 客户端的 init 容器的镜像。

字符串

rack

配置用作 客户端的节点标签。rack consumer 配置。

rack

tracing

在 Kafka Connect 中配置追踪。类型取决于给定对象中的 tracing.type 属性的值,它必须是 [jaeger] 中的一个。

Jaegertracing

模板

Kafka Connect 和 Kafka Mirror Maker 2 资源的模板。这个模板允许用户指定如何生成 Deployment, PodsService

KafkaConnectTemplate

externalConfiguration

将 Secret 或 ConfigMap 中的数据传递给 Kafka Connect pod,并使用它们配置连接器。

ExternalConfiguration

metricsConfig

指标配置。这个类型取决于给定对象中的 metricsConfig.type 属性的值,它必须是 [jmxPrometheusExporter] 之一。

JmxPrometheusExporterMetrics

12.2.126. KafkaMirrorMaker2ClusterSpec 模式参考

使用的: KafkaMirrorMaker2Spec

KafkaMirrorMaker2ClusterSpec schema 属性的完整列表

为镜像配置 Kafka 集群。

12.2.126.1. config

使用 config 属性来配置 Kafka 选项。

可以提供标准 Apache Kafka 配置,仅限于不直接由 AMQ Streams 管理的属性。

对于将特定 密码套件 用于 TLS 版本的客户端连接,您可以配置允许的 ssl 属性您还可以配置 ssl.endpoint.identification.algorithm 属性 来启用或禁用主机名验证。

12.2.126.2. KafkaMirrorMaker2ClusterSpec schema 属性
属性Description

alias

用于引用 Kafka 集群的别名。

字符串

bootstrapServers

用于建立到 Kafka 集群连接的 host:port 对的逗号分隔列表。

字符串

tls

用于将 MirrorMaker 2.0 连接器连接到集群的 TLS 配置。

ClientTls

身份验证

用于连接到集群的身份验证配置。这个类型取决于给定对象中的 authentication.type 属性的值,它必须是 [tls, scram-sha-256, scram-sha-256, scram-sha-512, plain, oauth]。

KafkaClientAuthenticationTls, KafkaClientAuthenticationScramSha256, KafkaClientAuthenticationScramSha512, KafkaClientAuthenticationPlain, KafkaClientAuthenticationOAuth

config

MirrorMaker 2.0 集群配置。无法设置以下前缀的属性: ssl., sasl., security.,监听程序, plugin.path, rest., bootstrap.servers, consumer.interceptor.classes, producer.interceptor.classes (权限为 ssl.endpoint.identification.algorithm、ssl.cipher.suites、ssl.protocol.enabled ssl.protocols)。

map

12.2.127. KafkaMirrorMaker2MirrorSpec 模式参考

使用的: KafkaMirrorMaker2Spec

属性Description

sourceCluster

Kafka MirrorMaker 2.0 连接器使用的源集群的别名。别名必须与位于 spec.clusters 的列表中有一个集群匹配。

字符串

targetCluster

Kafka MirrorMaker 2.0 连接器使用的目标集群的别名。别名必须与位于 spec.clusters 的列表中有一个集群匹配。

字符串

sourceConnector

Kafka MirrorMaker 2.0 源连接器的规格。

KafkaMirrorMaker2ConnectorSpec

heartbeatConnector

Kafka MirrorMaker 2.0 heartbeat 连接器的规格。

KafkaMirrorMaker2ConnectorSpec

checkpointConnector

Kafka MirrorMaker 2.0 检查点连接器的规格。

KafkaMirrorMaker2ConnectorSpec

topicsPattern

与要镜像的主题匹配的正则表达式,如 "topic1|topic2|topic3"。也支持以逗号分隔的列表。

字符串

topicsBlacklistPattern

topicsBlacklistPattern 属性已弃用,现在应该使用 .spec.mirrors.topicsExcludePattern 配置。与要从镜像中排除的主题匹配的正则表达式。也支持以逗号分隔的列表。

字符串

topicsExcludePattern

与要从镜像中排除的主题匹配的正则表达式。也支持以逗号分隔的列表。

字符串

groupsPattern

与要镜像的消费者组匹配的正则表达式。也支持以逗号分隔的列表。

字符串

groupsBlacklistPattern

groupsBlacklistPattern 属性已弃用,现在应该使用 .spec.mirrors.groupsExcludePattern 配置。与要从镜像中排除的消费者组匹配的正则表达式。也支持以逗号分隔的列表。

字符串

groupsExcludePattern

与要从镜像中排除的消费者组匹配的正则表达式。也支持以逗号分隔的列表。

字符串

12.2.128. KafkaMirrorMaker2ConnectorSpec 模式参考

使用的: KafkaMirrorMaker2MirrorSpec

属性Description

tasksMax

Kafka Connector 的最大任务数量。

整数

config

Kafka Connector 配置。无法设置以下属性:connector.class, tasks.max。

map

pause

连接器是否应暂停。默认为false。

布尔值

12.2.129. KafkaMirrorMaker2Status 模式参考

使用的: KafkaMirrorMaker2

属性Description

conditions

状态条件列表。

状况 数组

observedGeneration

Operator 最后协调的 CRD 的生成。

整数

url

用于管理和监控 Kafka 连接连接器的 REST API 端点的 URL。

字符串

connectorPlugins

此 Kafka Connect 部署中的连接器插件列表。

ConnectorPlugin 数组

connectors

MirrorMaker 2.0 连接器状态列表,如 Kafka Connect REST API 报告。

映射数组

labelSelector

提供此资源的 pod 的标签选择器。

字符串

replicas

提供此资源的当前 pod 数量。

整数

12.2.130. KafkaRebalance 模式参考

属性Description

spec

Kafka 重新平衡的规格。

KafkaRebalanceSpec

status

Kafka 重新平衡的状态。

KafkaRebalanceStatus

12.2.131. KafkaRebalanceSpec 模式参考

使用的: KafkaRebalance

属性Description

模式

模式以运行重新平衡。支持的模式是 full, add-brokers, remove-brokers。如果没有指定,则默认使用 full 模式。

  • 完整 模式在集群中的所有代理中运行重新平衡。
  • 在扩展集群后,可以使用 add-brokers 模式,将一些副本移到新添加的代理中。
  • 在缩减集群以移出要被删除的代理(broker)前,可以使用 remove-brokers 模式。

字符串(一个 [remove-brokers、full、add-brokers])

代理(broker)

当扩展或要删除的代理时,新添加的代理列表(如果缩减)用于重新平衡。此列表只能用于重新平衡模式 add-brokersremoved-brokers。它被忽略为 full 模式。

整数数组

目标

目标列表,按降序排列,用于生成和执行重新平衡提议。支持的目标可在 https://github.com/linkedin/cruise-control#goals 获得。如果提供了空目标列表,则使用 default.goals Cruise Control 配置参数中声明的目标。

字符串数组

skipHardGoalCheck

是否允许 Kafka CR 中指定的硬目标以优化提议生成过程中跳过。当出现这些硬目标时,这很有用。默认为 false。

布尔值

rebalanceDisk

启用 in-broker 磁盘平衡,用于平衡同一代理上磁盘之间的磁盘空间利用率。只适用于使用多个磁盘的 JBOD 存储的 Kafka 部署。启用后,禁用 In-broker 平衡。默认为 false。

布尔值

excludedTopics

一个正则表达式,任何匹配主题不包括在计算优化提议中。此表达式将由 java.util.regex.Pattern 类解析。有关支持的格式的更多信息,请参阅相关文档。

字符串

concurrentPartitionMovementsPerBroker

持续分区副本的上限将移到每个代理的/外。默认值为 5。

整数

concurrentIntraBrokerPartitionMovements

在每个代理中的磁盘间移动持续分区副本的上限。默认值为 2。

整数

concurrentLeaderMovements

持续分区领导移动的上限。默认值为 1000。

整数

replicationThrottle

位于用于移动副本的带宽的上限(以字节/秒为单位)。默认没有限制。

整数

replicaMovementStrategies

用于决定在生成的优化过程中对副本移动执行顺序的策略类名称列表。默认情况下,使用 BaseReplicaMovementStrategy,这将按照生成的顺序执行副本移动。

字符串数组

12.2.132. KafkaRebalanceStatus 模式参考

使用的: KafkaRebalance

属性Description

conditions

状态条件列表。

状况 数组

observedGeneration

Operator 最后协调的 CRD 的生成。

整数

sessionId

与这个 KafkaRebalance 资源相关的请求的会话标识符。Kafka Rebalance Operator 用来跟踪持续重新平衡操作的状态。

字符串

optimizationResult

描述优化结果的 JSON 对象。

map

附录 A. 使用您的订阅

AMQ Streams 通过软件订阅提供。要管理您的订阅,请访问红帽客户门户中的帐户。

访问您的帐户

  1. 转至 access.redhat.com
  2. 如果您还没有帐户,请创建一个帐户。
  3. 登录到您的帐户。

激活订阅

  1. 转至 access.redhat.com
  2. 导航到 My Subscriptions
  3. 导航到 激活订阅 并输入您的 16 位激活号。

下载 Zip 和 Tar 文件

要访问 zip 或 tar 文件,请使用客户门户网站查找下载的相关文件。如果您使用 RPM 软件包,则不需要这一步。

  1. 打开浏览器并登录红帽客户门户网站 产品下载页面,网址为 access.redhat.com/downloads
  2. INTEGRATION AND AUTOMATION 目录中找到 AMQ Streams for Apache Kafka 项。
  3. 选择所需的 AMQ Streams 产品。此时会打开 Software Downloads 页面。
  4. 单击组件的 Download 链接。

使用 DNF 安装软件包

要安装软件包以及所有软件包的依赖软件包,请使用:

dnf install <package_name>

要从本地目录中安装之前下载的软件包,请使用:

dnf install <path_to_download_package>

更新于 2023-10-30

法律通告

Copyright © 2023 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

© 2024 Red Hat, Inc.