在 OpenShift 中配置 AMQ Streams
在 OpenShift Container Platform 中配置和管理 AMQ Streams 2.2 的部署
摘要
使开源包含更多
红帽致力于替换我们的代码、文档和 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 config
的 inter.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 指南:
流程
编辑
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
键下。对于 Kafkakafka.root.logger.level
logger,您可以将日志级别设置为 INFO、ERROR、WARN、WARN、TRACE、DEBAL 或 OFF。 - 4
- 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
,nodeport
或ingress
。 - 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
- 21
- 可能会增加 持久性卷的存储大小,也可以将 额外的 卷添加到 JBOD 存储中。
- 22
- 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
- 实体 Operator 配置,指定主题 Operator 和用户 Operator 的配置。
- 30
- 实体 Operator TLS sidecar 配置。实体 Operator 使用 TLS sidecar 进行与 ZooKeeper 的安全通信。
- 31
- 指定 topics Operator 日志记录器和日志级别。这个示例使用
内联
日志记录。 - 32
- 33
- Kafka 导出器配置.Kafka Exporter 是一个可选组件,用于从 Kafka 代理中提取指标数据。
- 34
- Cruise Control 的可选配置,用于 重新平衡 Kafka 集群。
创建或更新资源:
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: {}
如果将空对象({}
)用于 topicOperator
和 userOperator
,则所有属性都使用它们的默认值。
当缺少 topicOperator
和 userOperator
属性时,实体 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。
从块存储的以下选项之一中选择:
- 基于云的块存储解决方案,如 Amazon Elastic Block Store (EBS)
- 本地持久性卷
- 由 光纤通道或 iSCSI等协议访问的存储区域网络(SAN)卷
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 集群。
流程
在
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: # ...
-
要增加分配给 Kafka 集群的卷大小,请编辑
创建或更新资源:
oc apply -f <kafka_configuration_file>
OpenShift 增加所选持久性卷的容量,以响应 Cluster Operator 的请求。调整大小完成后,Cluster Operator 会重启所有使用调整大小的持久性卷的 pod。这会自动发生。
其他资源
- 有关 OpenShift 中重新定义持久性卷的更多信息,请参阅使用 Kubernetes 重新定义持久性卷。
2.2.3.5. JBOD 存储概述
您可以将 AMQ Streams 配置为使用 JBOD,这是多个磁盘或卷的数据存储配置。JBOD 是为 Kafka 代理提供增加数据存储的方法。它还可以提高性能。
JBOD 配置由一个或多个卷描述,每个卷可以是 临时或 持久的。JBOD 卷声明的规则和约束与用于临时存储的规则和限制相同。例如,在置备后无法缩小持久性存储卷的大小,或者当 type=ephemeral 时无法更改 sizeLimit
的值。
2.2.3.5.1. JBOD 配置
要将 JBOD 与 AMQ Streams 搭配使用,存储类型
必须设置为 jbod
。volumes
属性允许您描述组成 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 代理 podidx
的数据的卷 ID。
2.2.3.5.3. 日志目录
Kafka 代理将使用 JBOD 卷作为挂载到以下路径的日志目录:
/var/lib/kafka/data-id/kafka-log_idx_
-
其中
id
是用于存储 Kafka 代理 podidx
的数据的卷 ID。例如/var/lib/kafka/data-0/kafka-log0
。
2.2.3.6. 添加卷到 JBOD 存储
此流程描述了如何将卷添加到配置为使用 JBOD 存储的 Kafka 集群。它不适用于配置为使用任何其他存储类型的 Kafka 集群。
当在过去和移除的 id
下添加新卷时,您必须确保之前使用的 PersistentVolumeClaim
已被删除。
先决条件
- OpenShift 集群
- 正在运行的 Cluster Operator
- 带有 JBOD 存储的 Kafka 集群
流程
编辑
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: # ...
创建或更新资源:
oc apply -f <kafka_configuration_file>
- 创建新主题或将现有分区重新分配给新磁盘。
其他资源
有关重新分配主题的更多信息,请参阅 第 2.2.4.2 节 “分区重新分配工具”。
2.2.3.7. 从 JBOD 存储中删除卷
此流程描述了如何从配置为使用 JBOD 存储的 Kafka 集群中删除卷。它不适用于配置为使用任何其他存储类型的 Kafka 集群。JBOD 存储总必须至少包含一个卷。
为了避免数据丢失,您必须在删除卷前移动所有分区。
先决条件
- OpenShift 集群
- 正在运行的 Cluster Operator
- 带有两个或多个卷的 JBOD 存储的 Kafka 集群
流程
- 从您要删除的磁盘中分配所有分区。分区中的任何数据仍会分配给要删除的磁盘中的数据可能会丢失。
编辑
Kafka
资源中的spec.kafka.storage.volumes
属性。从volumes
阵列中删除一个或多个卷。例如,删除 ID 为1
和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 # ... zookeeper: # ...
创建或更新资源:
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
, 4
和 7
;主题 topic-b
的分区 2
分配给代理 1
, 5
和 7
:
分区重新分配文件示例
{ "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 # ...
正在运行的 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-topic
和my-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: "*" # ... # ...
注意需要
描述操作的权限
,作为对主题的 TLS 访问的最低权限。
流程
从 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 集群的名称。当您使用 Kafka 资源部署 Kafka 时,会使用
Kafka
集群名称( <cluster_name> -cluster-ca-cert )创建带有集群
CA 证书的 Secret。例如,my-cluster-cluster-ca-cert
。使用 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 的名称。
将集群 CA 证书复制到互动 pod 容器中。
oc cp ca.p12 <interactive_pod_name>:/tmp
从可访问 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
。将用户 CA 证书复制到交互式 pod 容器。
oc cp user.p12 <interactive_pod_name>:/tmp
CA 证书允许交互式 pod 容器使用 TLS 连接到 Kafka 代理。
创建
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
将
config.properties
文件复制到交互式 pod 容器中。oc cp config.properties <interactive_pod_name>:/tmp/config.properties
准备名为
topics.json
的 JSON 文件,以指定要移动的主题。将主题名称指定为用逗号分开的列表。
用于重新分配
topic-a
和topic-b
的所有分区的 JSON 文件示例{ "version": 1, "topics": [ { "topic": "topic-a"}, { "topic": "topic-b"} ] }
将
topics.json
文件复制到交互式 pod 容器中。oc cp topics.json <interactive_pod_name>:/tmp/topics.json
在互动 pod 容器中启动 shell 进程。
oc exec -n <namespace> -ti <interactive_pod_name> /bin/bash
将 <namespace > 替换为运行 pod 的 OpenShift 命名空间。
使用
kafka-reassign-partitions.sh
命令生成重新分配 JSON。示例以将
topic-a
和topic-b
的所有分区移动到代理0
、1
和2
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 集群及其主题的权限。
流程
-
通过增加
Kafka.spec.kafka.replicas
配置选项,根据需要添加多个新代理。 - 验证新代理 pod 是否已启动。
-
如果没有这样做,请运行交互式 pod 容器来生成一个重新分配 JSON 文件,名为
reassignment.json
。 将
reassignment.json
文件复制到交互式 pod 容器中。oc cp reassignment.json <interactive_pod_name>:/tmp/reassignment.json
将 <interactive_pod_name > 替换为 pod 的名称。
在互动 pod 容器中启动 shell 进程。
oc exec -n <namespace> -ti <interactive_pod_name> /bin/bash
将 <namespace > 替换为运行 pod 的 OpenShift 命名空间。
使用交互式 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
验证重新分配已使用来自任何代理 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
还会导致删除任何重新分配节流的效果。- 现在,如果保存了 JSON 以将分配恢复到其原始代理,您可以删除恢复的文件。
2.2.4.5. 缩减 Kafka 集群
使用重新分配文件来减少 Kafka 集群中的代理数。
重新分配文件必须描述如何将分区重新分配给 Kafka 集群中的剩余代理。首先删除最高数量最高的 pod 中的代理。
这个步骤描述了使用 TLS 的安全扩展过程。您需要一个使用 TLS 加密和身份验证的 Kafka 集群。
先决条件
-
您有一个正在运行的 Kafka 集群,它基于配置了内部 TLS 身份验证和加密的
Kafka
资源。 -
您已生成了一个名为 rement
.json 的重新分配
JSON 文件。 - 您要运行一个连接到正在运行的 Kafka 代理的交互式 pod 容器。
-
您使用 ACL 规则配置的
KafkaUser
连接,指定管理 Kafka 集群及其主题的权限。
流程
-
如果没有这样做,请运行交互式 pod 容器来生成一个重新分配 JSON 文件,名为
reassignment.json
。 将
reassignment.json
文件复制到交互式 pod 容器中。oc cp reassignment.json <interactive_pod_name>:/tmp/reassignment.json
将 <interactive_pod_name > 替换为 pod 的名称。
在互动 pod 容器中启动 shell 进程。
oc exec -n <namespace> -ti <interactive_pod_name> /bin/bash
将 <namespace > 替换为运行 pod 的 OpenShift 命名空间。
使用交互式 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
验证重新分配已使用来自任何代理 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
还会导致删除任何重新分配节流的效果。- 现在,如果保存了 JSON 以将分配恢复到其原始代理,您可以删除恢复的文件。
当所有分区重新分配完成后,被删除的代理不应该负责集群中的任何分区。您可以通过检查代理的数据日志目录是否包含任何实时分区日志来验证这一点。如果代理上的日志目录包含一个与扩展的正则表达式
\.[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 文件不正确。
-
当您确认代理没有实时分区时,您可以编辑
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.renewalDays
和 Kafka.spec.clientsCa.renewalDays
属性一起设置,以确保在配置的维护时间窗口中完成必要的 CA 证书续订。
AMQ Streams 不会根据给定窗口精确调度维护操作。相反,对于每个协调,它会检查维护窗口当前是否"open"。这意味着,在一个给定时间窗内开始维护操作会延迟到 Cluster Operator 协调间隔。因此,维护时间窗口必须至少如此长。
其他资源
- 如需有关 Cluster Operator 配置的更多信息,请参阅 第 6.2.1 节 “Cluster Operator 配置”。
2.2.5.3. 配置维护时间窗
您可以为支持的进程触发的滚动更新配置维护时间窗。
先决条件
- OpenShift 集群。
- Cluster Operator 正在运行。
流程
在
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 * * ?"
创建或更新资源:
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 正在运行。
流程
使用 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 指南:
流程
查找您要删除的
Pod
的名称。Kafka 代理 pod 的名称为 & lt;cluster-name> -kafka-<index & gt;,其中 <index> 从零开始,结尾是 replicas减一总数。例如,
my-cluster-kafka-0
。注解 OpenShift 中的
Pod
资源。使用
oc annotate
:oc annotate pod cluster-name-kafka-index strimzi.io/delete-pod-and-pvc=true
- 当注解的具有底层持久性卷声明的 pod 被删除后再重新创建时,等待下一次协调。
2.2.8. 手动删除 ZooKeeper 节点
此流程描述了如何使用 OpenShift 注解删除现有 ZooKeeper 节点。删除 ZooKeeper 节点包括删除运行 ZooKeeper 的 Pod
以及相关的 PersistentVolumeClaim
(如果集群已部署了持久性存储)。删除后,Pod
及其相关的 PersistentVolumeClaim
会自动重新创建。
删除 PersistentVolumeClaim
可能会导致持久性数据丢失。只有在遇到存储问题时才会执行以下步骤。
先决条件
有关运行的信息 ,请参阅 OpenShift 中的部署和升级 AMQ Streams 指南:
流程
查找您要删除的
Pod
的名称。zookeeper pod 的名称为 < cluster-name>-zookeeper-<index > ;,其中 <index > 从零开始,结尾是 replicas minus 总数。例如,
my-cluster-zookeeper-0
。注解 OpenShift 中的
Pod
资源。使用
oc annotate
:oc annotate pod cluster-name-zookeeper-index strimzi.io/delete-pod-and-pvc=true
- 当注解的具有底层持久性卷声明的 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 代理 podidx
的数据。只有在置备持久性卷以存储数据时为 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 指南:
流程
编辑
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-512 或 PLAIN 机制。默认情况下,Kafka Connect 使用纯文本连接连接到 Kafka 代理。
- 5
- 连接到 Kafka Connect 集群的 bootstrap 服务器。
- 6
- TLS 加密,使用密钥名称,其中 TLS 证书存储为集群的 X.509 格式。如果证书存储在同一 secret 中,可以多次列出它。
- 7
- worker 的 Kafka 连接配置 (而非连接器)。可以提供标准 Apache Kafka 配置,仅限于不直接由 AMQ Streams 管理的属性。
- 8
- 构建配置属性,以使用连接器插件构建容器镜像。
- 9
- (必需)推送新镜像的容器注册表的配置。
- 10
- (必需)连接器插件列表及其要添加到新容器镜像的工件。每个插件必须至少配置一个
工件
。 - 11
- 12
- 13
- 指定的 Kafka Connect 日志记录器和日志级别 直接(
内联
)或通过 ConfigMap 间接添加(外部
)。自定义 ConfigMap 必须放在log4j.properties
或log4j2.properties
键下。对于 Kafka Connectlog4j.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 为分布式追踪 设置环境变量。
创建或更新资源:
oc apply -f KAFKA-CONNECT-CONFIG-FILE
- 如果为 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 # ... # ...
这三个主题的值对于具有相同 组.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 # ... # ...
此流程演示了如何在 使用简单
授权时提供访问权限。
简单授权使用由 Kafka AclAuthorizer
插件处理的 ACL 规则来提供正确的访问权限级别。有关配置 KafkaUser
资源以使用简单授权的更多信息,请参阅 AclRule
模式参考。
先决条件
- OpenShift 集群
- 正在运行的 Cluster Operator
流程
编辑
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: "*"
创建或更新资源。
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 指南:
- 源和目标集群必须可用
流程
编辑
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-512 或 PLAIN 机制。
- 8
- 9
- 使用 TLS 版本的特定 密码套件 运行外部监听程序的 SSL 属性。
- 10
- 通过设置为
HTTPS
来启用主机名验证。空字符串禁用验证。 - 11
- 如果
abortOnSendFailure
属性设为true
,则 Kafka MirrorMaker 将退出,并且容器将因消息的发送失败而重启。 - 12
- 使用 TLS 版本的特定 密码套件 运行外部监听程序的 SSL 属性。
- 13
- 通过设置为
HTTPS
来启用主机名验证。空字符串禁用验证。 - 14
- 15
- 16
- 通过 ConfigMap 直接添加(
内联
)或间接(外部
)的指定 日志记录器和日志级别。自定义 ConfigMap 必须放在log4j.properties
或log4j2.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
时,生产者会尝试在主题中发送下一消息。原始消息可能会丢失,因为没有尝试重新发送失败的信息。创建或更新资源:
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. 在两个集群间复制

默认情况下,每隔 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. 主题重命名

通过标记原始集群,主题不会重新复制到该集群。
在配置需要数据聚合的构架时,通过远程 主题复制的概念非常有用。消费者可以订阅同一集群中的源和远程主题,而无需单独聚合集群。
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.seconds
和 emit.checkpoints.interval.seconds
来更改频率。属性指定消费者组偏移的频率,以及针对偏移跟踪发出的检查点的频率。两个属性的默认值都是 60 秒。您还可以使用 refresh.groups.interval.seconds
属性更改新消费者组的检查频率,该属性默认为每 10 分钟执行一次。
因为同步是基于时间的,所以消费者到被动集群的任何交换机都可能会导致消息重复。
2.5.2.7. 连接检查
MirrorHeartbeatConnector
发出 heartbeats 来检查集群间的连接。
从源集群复制内部 心跳
主题。目标集群使用 heartbeat
主题来检查以下内容:
- 管理集群间连接的连接器正在运行
- 源集群可用
2.5.3. 连接器配置
将 Mirrormaker 2.0 连接器配置用于内部连接器,以编配 Kafka 集群之间的数据同步。
下表描述了连接器属性和您配置的连接器。
属性 | sourceConnector | checkpointConnector | heartbeatConnector |
---|---|---|---|
| ✓ | ✓ | ✓ |
| ✓ | ✓ | ✓ |
| ✓ | ✓ | ✓ |
| ✓ | ✓ | |
| ✓ | ✓ | |
| ✓ | ✓ | |
| ✓ | ||
| ✓ | ||
| ✓ | ||
| ✓ | ||
| ✓ | ||
| ✓ | ||
| ✓ | ||
| ✓ | ||
| ✓ | ||
| ✓ | ||
| ✓ | ||
| ✓ | ||
| ✓ | ||
| ✓ | ||
| ✓ | ||
| ✓ | ||
| ✓ | ||
| ✓ | ||
| ✓ | ||
| ✓ | ||
| ✓ | ||
| ✓ |
2.5.4. 连接器制作者和消费者配置
MirrorMaker 2.0 连接器使用内部制作者和消费者。如果需要,您可以配置这些制作者和消费者来覆盖默认设置。
例如,您可以提高源制作者的 batch.size
,该制作者会向目标 Kafka 集群发送主题以更好地容纳大量消息。
生产者和使用者配置选项取决于 MirrorMaker 2.0 实施,可能会有所变化。
下表描述了每个连接器以及您可在其中添加配置的制作者和消费者。
类型 | Description | 配置 |
---|---|---|
制作者 | 将主题信息发送到目标 Kafka 集群。在处理大量数据时,请考虑调优此制作者的配置。 |
|
制作者 |
写入 |
|
消费者 | 从源 Kafka 集群检索主题信息。 |
|
类型 | Description | 配置 |
---|---|---|
制作者 | 发送消费者偏移检查点。 |
|
消费者 |
加载 |
|
您可以将 offset-syncs.topic.location
设置为 target
来使用目标 Kafka 集群作为 offset-syncs
主题的位置。
类型 | Description | 配置 |
---|---|---|
制作者 | 发送心跳. |
|
以下示例演示了如何配置制作者和使用者。
连接器制作者和消费者配置示例
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
资源中指定要从源集群复制的主题和消费者组。您可以使用 topicsPattern
和 groupsPattern
属性进行此操作。您可以提供名称或使用正则表达式的列表。默认情况下,如果没有设置 topicsPattern
和 groupsPattern
属性,则会复制所有主题和消费者组。您还可以使用 ".*"
作为正则表达式来复制所有主题和消费者组。但是,尝试只指定您所需的主题和消费者组,以避免造成集群中的不必要的额外负载。
处理大量消息
您可以调整配置来处理大量消息。更多信息请参阅 第 2.7 节 “处理大量消息”。
先决条件
- AMQ Streams 处于运行状态
- 源集群和目标 Kafka 集群可用
流程
编辑
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
- 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
- 24
- 可选设置,用于更改新主题的检查频率。默认值每 10 分钟进行一次检查。
- 25
- 定义用于重命名远程主题的分隔符。
- 26
- 添加可覆盖远程主题自动重命名的策略。该主题不会用源集群的名称来附加名称,而是保留其原始名称。此可选设置可用于主动/被动备份和数据迁移。要配置主题偏移同步,必须为
checkpointConnector.config
设置此属性。 - 27
- 执行连接检查的
MirrorHeartbeatConnector
配置。配置
会覆盖默认配置选项。 - 28
- 在目标集群中创建的 heartbeat 主题的复制因素。
- 29
- 用于跟踪偏移 的
MirrorCheckpointConnector
配置。配置
会覆盖默认配置选项。 - 30
- 在目标集群中创建的检查点主题的复制因素。
- 31
- 可选设置,用于更改新消费者组的检查频率。默认值每 10 分钟进行一次检查。
- 32
- 可选设置同步消费者组偏移,这对于在主动/被动配置中恢复非常有用。默认情况下不启用同步。
- 33
- 如果启用了消费者组偏移的同步,您可以调整同步的频率。
- 34
- 调整偏移跟踪的检查频率。如果更改偏移同步的频率,您可能需要调整这些检查的频率。
- 35
- 来自源集群的主题复制 ,定义为用逗号分开的列表或正则表达式模式。源连接器复制指定的主题。Checkpoint 连接器跟踪指定主题的偏移量。此处我们按名称请求三个主题。
- 36
- 来自源集群的消费者组复制 ,定义为以逗号分隔的列表或正则表达式模式。checkpoint 连接器复制指定的使用者组。此处我们根据名称请求三个消费者组。
- 37
- 38
- 指定的 Kafka Connect 日志记录器和日志级别 直接(
内联
)或通过 ConfigMap 间接添加(外部
)。自定义 ConfigMap 必须放在log4j.properties
或log4j2.properties
键下。对于 Kafka Connectlog4j.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
创建或更新资源:
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。
流程
配置两个
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: {}
在单独的命名空间中创建或更新
Kafka
资源。oc apply -f <kafka_configuration_file> -n <namespace>
Cluster Operator 创建监听程序并设置集群和客户端证书颁发机构(CA)证书,以便在 Kafka 集群中启用身份验证。
证书在 secret <
cluster_name> -cluster-ca-cert
中创建。配置两个
KafkaUser
资源,一个用于源 Kafka 集群的用户,一个用于目标 Kafka 集群的用户。-
配置与对应的源和目标 Kafka 集群相同的身份验证和授权类型。例如,如果您在源 Kafka 集群的
Kafka
配置中使用了tls
验证和simple
授权类型,请在KafkaUser
配置中使用相同的。 配置 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 外部发布的证书。如需更多信息,请参阅 用户身份验证。-
配置与对应的源和目标 Kafka 集群相同的身份验证和授权类型。例如,如果您在源 Kafka 集群的
在您为源和目标集群创建的每个命名空间中创建或更新
KafkaUser
资源。oc apply -f <kafka_user_configuration_file> -n <namespace>
User Operator 根据所选的身份验证类型创建代表客户端(MirrorMaker)和用于客户端身份验证的安全凭证的用户。
User Operator 会创建一个与
KafkaUser
资源名称相同的新 secret。secret 包含用于 TLS 客户端身份验证的私钥和公钥。公钥包含在用户证书中,由客户端证书颁发机构(CA)签名。使用身份验证详情配置
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"
在与目标 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 正在运行。
流程
查找控制要重启的 Kafka MirrorMaker 2.0 连接器的
KafkaMirrorMaker2
自定义资源的名称:oc get KafkaMirrorMaker2
查找 Kafka MirrorMaker 2.0 连接器的名称,以便从
KafkaMirrorMaker2
自定义资源重启。oc describe KafkaMirrorMaker2 KAFKAMIRRORMAKER-2-NAME
要重启连接器,请在 OpenShift 中注解
KafkaMirrorMaker2
资源。在本例中,oc annotate
重启名为my-source->my-target.MirrorSourceConnector 的连接器
:oc annotate KafkaMirrorMaker2 KAFKAMIRRORMAKER-2-NAME "strimzi.io/restart-connector=my-source->my-target.MirrorSourceConnector"
等待下一次协调发生(默认为两分钟)。
Kafka MirrorMaker 2.0 连接器将重启,只要该注解由协调过程检测到。当接受重启请求时,注解会从
KafkaMirrorMaker2
自定义资源中删除。
2.5.10. 执行 Kafka MirrorMaker 2.0 连接器任务重启
此流程描述了如何使用 OpenShift 注解手动触发 Kafka MirrorMaker 2.0 连接器任务的重启。
先决条件
- Cluster Operator 正在运行。
流程
查找控制要重启的 Kafka MirrorMaker 2.0 连接器的
KafkaMirrorMaker2
自定义资源的名称:oc get KafkaMirrorMaker2
查找 Kafka MirrorMaker 2.0 连接器的名称以及要从
KafkaMirrorMaker2
自定义资源重启的任务 ID。任务 ID 是非负的整数,从 0 开始。oc describe KafkaMirrorMaker2 KAFKAMIRRORMAKER-2-NAME
要重启连接器任务,请在 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"
等待下一次协调发生(默认为两分钟)。
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 指南:
流程
编辑
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-512 或 PLAIN 机制。默认情况下,Kafka Bridge 会在没有身份验证的情况下连接到 Kafka 代理。
- 5
- 对 Kafka 代理的 HTTP 访问。
- 6
- CORS 访问 指定所选资源和访问方法。请求中的其他 HTTP 标头描述了允许访问 Kafka 集群的来源。
- 7
- 8
- 9
- 10
- 指定 Kafka Bridge 日志记录器和日志级别 直接(
内联
)或通过 ConfigMap 间接添加(外部
)。自定义 ConfigMap 必须放在log4j.properties
或log4j2.properties
键下。对于 Kafka Bridge 日志记录器,您可以将日志级别设置为 INFO、ERROR、WARN、TRACE、DEBUG、FATAL 或 OFF。 - 11
- JVM 配置选项,用于优化运行 Kafka Bridge 的虚拟机(VM)的性能。
- 12
- 状况检查,了解何时重启容器(持续)以及容器是否可以接受流量(就绪状态)。
- 13
- 可选: 容器镜像配置,这只在特殊情况下建议。
- 14
- 模板自定义。这里调度了带有反关联性的 pod,因此不会将 pod 调度到具有相同主机名的节点。
- 15
- 还使用 Jaeger 为分布式追踪 设置环境变量。
创建或更新资源:
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.bytes
和 max.partition.fetch.bytes
属性来增加 fetch 请求大小。您还可以使用 max.poll.records
属性针对使用者缓冲区返回的消息数量设置最大限制。
对于 MirrorMaker 2.0,配置 fetch.max.bytes
、max.partition.fetch.bytes
和 max.poll.records
值的来源连接器级别(consumer.*
),因为它们与从来源获取消息的特定使用者相关。
对于制作者而言,您可以增加一个生成请求中发送的消息批处理的大小。您可以使用 batch.size
属性来增加批处理大小。较大的批处理大小可减少已发送的未处理消息的数量,以及消息队列中 backlog 的大小。发送到同一分区的消息一起批处理。当达到批处理大小时,生成的请求将发送到目标集群。通过增加批处理大小,生成请求会延迟,更多的消息会添加到批处理中,并同时发送到代理。当您只拥有处理大量消息的几个主题分区时,这可以提高吞吐量。
考虑制作者为适合生产批处理大小处理的记录数和大小。
使用 linger.ms
添加等待时间(以毫秒为单位),以在生产负载减少时延迟生成请求。延迟意味着,如果这些记录在最大批处理大小下,可以向批处理添加更多记录。
在源连接器级别上配置 batch.size
和 linger.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 # ...
FileStreamSourceConnector
和 FileStreamSinkConnector
作为示例连接器提供。有关将其部署为 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 资源,如 Deployment
、StatefulSets
、Pod
和 Services
。这些资源由 AMQ Streams operator 管理。只有负责管理特定 OpenShift 资源的 Operator 才能更改该资源。如果您尝试手动更改操作器管理的 OpenShift 资源,Operator 将还原您的更改。
如果要执行某些任务,则更改操作器管理的 OpenShift 资源非常有用,例如:
-
添加控制 Istio 或其他服务如何处理
Pod
的自定义标签或注解 -
管理集群如何创建
Loadbalancer
-type Services
您可以使用 AMQ Streams 自定义资源中的 template
属性进行更改。以下资源支持 template
属性。API 引用提供有关可自定义字段的更多详情。
Kafka.spec.kafka
-
请查看 第 12.2.33 节 “
KafkaClusterTemplate
模式参考” Kafka.spec.zookeeper
-
请查看 第 12.2.43 节 “
ZookeeperClusterTemplate
模式参考” Kafka.spec.entityOperator
-
请查看 第 12.2.48 节 “
EntityOperatorTemplate
模式参考” Kafka.spec.kafkaExporter
-
请查看 第 12.2.54 节 “
KafkaExporterTemplate
模式参考” Kafka.spec.cruiseControl
-
请查看 第 12.2.51 节 “
CruiseControlTemplate
模式参考” KafkaConnect.spec
-
请查看 第 12.2.69 节 “
KafkaConnectTemplate
模式参考” KafkaMirrorMaker.spec
-
请查看 第 12.2.110 节 “
KafkaMirrorMakerTemplate
模式参考” KafkaMirrorMaker2.spec
-
请查看 第 12.2.69 节 “
KafkaConnectTemplate
模式参考” KafkaBridge.spec
-
请查看 第 12.2.119 节 “
KafkaBridgeTemplate
模式参考” KafkaUser.spec
-
请查看 第 12.2.104 节 “
KafkaUserTemplate
模式参考”
在以下示例中,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 集群滚动更新。
其他资源
- 如需有关 Cluster Operator 配置的更多信息,请参阅 第 6.2 节 “使用 Cluster Operator”。
- 有关 Image Pull 策略的更多信息,请参阅分配策略。
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
流程
编辑指定集群部署的资源中的
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 自定义资源的名称。如果您甚至想确保 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 自定义资源的名称。创建或更新资源。
oc apply -f <kafka_configuration_file>
2.9.3. 在 Kafka 组件中配置 pod 反关联性
Pod 反关联性配置有助于获取 Kafka 代理的稳定性和性能。通过使用 podAntiAffinity
,OpenShift 不会将 Kafka 代理调度到与其他工作负载相同的节点上。通常,您需要避免 Kafka 与其他网络或存储密集型应用程序(如数据库、存储或其他消息传递平台)在同一 worker 节点上运行。
先决条件
- OpenShift 集群
- 正在运行的 Cluster Operator
流程
编辑指定集群部署的资源中的
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: # ...
创建或更新资源。
这可以通过
oc apply
完成:oc apply -f <kafka_configuration_file>
2.9.4. 在 Kafka 组件中配置节点关联性
先决条件
- OpenShift 集群
- 正在运行的 Cluster Operator
流程
标记 AMQ Streams 组件应该调度的节点。
这可以通过
oc label
完成:oc label node NAME-OF-NODE node-type=fast-network
或者,一些现有的标签可能会被重复使用。
编辑指定集群部署的资源中的
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: # ...
创建或更新资源。
这可以通过
oc apply
完成:oc apply -f <kafka_configuration_file>
2.9.5. 设置专用节点并在其上调度 pod
先决条件
- OpenShift 集群
- 正在运行的 Cluster Operator
流程
- 选择应用作专用节点。
- 确保这些节点上没有调度任何工作负载。
在所选节点上设置污点:
这可以通过
oc adm taint
完成:oc adm taint node NAME-OF-NODE dedicated=Kafka:NoSchedule
另外,还要为所选节点添加标签。
这可以通过
oc label
完成:oc label node NAME-OF-NODE dedicated=Kafka
编辑指定集群部署的资源中的
关联性
和容限
属性。例如:
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: # ...
创建或更新资源。
这可以通过
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 的 name
和 key
的值是必需的。如果没有设置 name
或 key
,则会使用默认日志记录。
2.10.1. Kafka 组件和 Operator 的日志记录选项
有关为特定 Kafka 组件或操作员配置日志记录的更多信息,请参见以下部分。
Kafka 组件日志记录
Operator 日志记录
2.10.2. 创建用于日志记录的 ConfigMap
要使用 ConfigMap 定义日志记录属性,您可以创建 ConfigMap,然后将其引用为资源 spec
中的日志记录定义的一部分。
ConfigMap 必须包含适当的日志记录配置。
-
Kafka 组件的
log4j.properties
、ZooKeeper 和 Kafka Bridge -
Topic Operator 和用户 Operator 的
log4j2.properties
配置必须放在这些属性下。
此流程中 ConfigMap 为 Kafka 资源定义根日志记录器。
流程
创建 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" # ...
在资源的
spec
中定义 外部日志记录,将logging.valueFrom.configMapKeyRef.name
设置为 ConfigMap 的名称,并将logging.valueFrom.configMapKeyRef.key
设置为此 ConfigMap 中的键。spec: # ... logging: type: external valueFrom: configMapKeyRef: name: logging-configmap key: log4j.properties
创建或更新资源。
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
您可以创建一个或多个过滤器。在这里,会针对两个 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
)。
流程
更新
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
如果您更新了 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,使用相同的方法。
流程
创建 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) # ...
在资源的
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
- 通过部署 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 组件,即使使用新的Secret
或ConfigMap
对象。此功能可避免在 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
属性 添加配置。您不需要通过这种方法设置访问权限。但是,当将新的 Secret
或 ConfigMap
用于连接器时,Kafka Connect 将需要重启。这会导致中断所有 Kafka Connect 实例连接器。
3.1. 从配置映射载入配置值
此流程演示了如何使用 OpenShift Configuration Provider 插件。
在此过程中,外部 ConfigMap
对象为连接器提供配置属性。
先决条件
- OpenShift 集群可用。
- Kafka 集群正在运行。
- Cluster Operator 正在运行。
流程
创建包含配置属性的
ConfigMap
或Secret
。在本例中,名为
my-connector-configuration
的ConfigMap
对象包含 connector 属性:使用连接器属性的
ConfigMap
示例apiVersion: v1 kind: ConfigMap metadata: name: my-connector-configuration data: option1: value1 option2: value2
在 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 # ...
创建或更新资源以启用该提供程序。
oc apply -f <kafka_connect_configuration_file>
创建允许访问外部配置映射中的值的角色。
从配置映射访问值的角色示例
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
配置映射的角色权限。创建一个角色绑定,以允许访问包含配置映射的命名空间。
访问包含配置映射的命名空间的角色绑定示例
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
自定义资源的名称。在连接器配置中引用配置映射。
引用配置映射的连接器配置示例
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 正在运行。
流程
在 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 # ...
创建或更新资源以启用该提供程序。
oc apply -f <kafka_connect_configuration_file>
在连接器配置中引用环境变量。
引用环境变量的连接器配置示例
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
使用 KubernetesIngress
和 NGINX Ingress Controller 用于 Kubernetes -
路由
使用OpenShift
路由和 HAProxy 路由器
有关监听器配置的更多信息,请参阅 通用KafkaListener
模式参考。
如果要了解有关每种连接类型的代理和配件的更多信息,请参阅 Strimzi 中的访问 Apache Kafka。
只有在 OpenShift 中才支持 路由
4.1. 使用节点端口访问 Kafka
此流程描述了如何使用节点端口从外部客户端访问 AMQ Streams Kafka 集群。
要连接到代理,您需要 Kafka bootstrap 地址 的主机名和端口号,以及用于身份验证的证书。
先决条件
- OpenShift 集群
- 正在运行的 Cluster Operator
流程
配置一个
Kafka
资源,并将外部监听程序设置为nodeport
类型。例如:
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka spec: kafka: # ... listeners: - name: external port: 9094 type: nodeport tls: true authentication: type: tls # ... # ... zookeeper: # ...
创建或更新资源。
oc apply -f <kafka_configuration_file>
为每个 Kafka 代理创建
NodePort
类型服务,以及外部的 bootstrap service。bootstrap 服务将外部流量路由到 Kafka 代理。用于连接的节点地址会被传播到 Kafka 自定义资源的状态
。在 secret <cluster
_name> -cluster-ca-cert 中也创建了用于验证 kafka 代理身份的集群
CA 证书。检索您用来从
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"}'
如果启用了 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
流程
配置一个
Kafka
资源,并将外部监听程序设置为loadbalancer
类型。例如:
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka spec: kafka: # ... listeners: - name: external port: 9094 type: loadbalancer tls: true # ... # ... zookeeper: # ...
创建或更新资源。
oc apply -f <kafka_configuration_file>
为每个 Kafka 代理创建
loadbalancer
类型服务和负载均衡器,以及外部 bootstrap 服务。bootstrap 服务将外部流量路由到所有 Kafka 代理。用于连接的 DNS 名称和 IP 地址会传播到每个服务的状态
。在 secret <cluster
_name> -cluster-ca-cert 中也创建了用于验证 kafka 代理身份的集群
CA 证书。检索可用于从
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"}'
如果启用了 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 透传文档。
先决条件
- OpenShift cluster
- 为启用了 TLS 透传 部署的 Kubernetes 的 NGINX Ingress Controller
- 正在运行的 Cluster Operator
流程
配置
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 主机。
创建或更新资源。
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 集群。提取代理证书颁发机构的公共证书。
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
流程
配置
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 个字符的最大值。创建或更新资源。
oc apply -f <kafka_configuration_file>
ClusterIP
类型服务为每个 Kafka 代理和外部 bootstrap 服务创建。服务将 OpenShift 路由的流量路由到 Kafka 代理。还为每个服务创建一个 OpenShiftRoute
资源,以使用 HAProxy 负载均衡器来公开它们。用于连接的 DNS 地址会传播到每个服务的状态
。在 secret <cluster
_name> -cluster-ca-cert 中也创建了用于验证 kafka 代理身份的集群
CA 证书。检索可用于从
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"}'
提取代理证书颁发机构的公共证书。
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。
支持的身份验证选项:
- 双向 TLS 身份验证(仅在启用 TLS 的监听程序中)
- SCRAM-SHA-512 身份验证
- 基于 OAuth 2.0 令牌的身份验证
- 自定义身份验证
您选择的身份验证选项取决于您要如何验证对 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
字段中定义。
支持的授权选项:
- 简单授权
- OAuth 2.0 授权 (如果您使用基于 OAuth 2.0 令牌的身份验证)
- 开放策略代理 (OPA) 授权
- 自定义授权
图 5.2. Kafka 集群授权选项

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 身份验证
如果指定了 tls
或 scram-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
解码生成的密码:
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 # ...
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
有关这些属性的更多信息,请参阅 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.authorization
与KafkaUser.spec.authorization
匹配
这些步骤显示,使用 TLS 身份验证进行简单授权和侦听器的配置。有关监听器配置的更多信息,请参阅 通用KafkaListener
模式参考。
另外,您可以使用 SCRAM-SHA 或 OAuth 2.0 进行 监听程序身份验证,以及 OAuth 2.0 或 OPA 用于 Kafka 授权。
流程
配置
Kafka
资源。-
配置
授权
属性以进行授权。 配置
监听程序
属性,以创建具有身份验证的监听程序。例如:
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。
如果您要配置外部监听程序,配置取决于所选的连接机制。
-
配置
创建或更新
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 验证用户。
先决条件
- 使用 TLS 身份验证和加密配置带有 Kafka 代理监听程序的 正在运行的 Kafka 集群。
- 正在运行的用户 Operator (通常使用 Entity Operator 部署)。
KafkaUser
中的身份验证类型应与 Kafka
代理中配置的身份验证匹配。
流程
配置
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
创建或更新
KafkaUser
资源。oc apply -f <user_config_file>
创建用户,以及与
KafkaUser
资源名称相同的 Secret。Secret 包含 TLS 客户端身份验证的私钥和公钥。
有关使用属性配置 Kafka 客户端以连接到 Kafka 代理的详情,请参考为 OpenShift 外部的客户端设置访问。
5.3.3. 使用网络策略限制 Kafka 侦听程序的访问
您可以使用 networkPolicyPeers
属性将对监听程序的访问限制为特定的应用程序。
先决条件
- 一个 OpenShift 集群,它支持 Ingress NetworkPolicies。
- Cluster Operator 正在运行。
流程
-
打开
Kafka
资源。 在
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: # ...
创建或更新资源。
使用
oc apply
:oc apply -f your-file
5.4. 使用基于 OAuth 2.0 令牌的身份验证
AMQ Streams 支持使用 OAUTHBEARER 和 PLAIN 机制使用 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 username
和 password
属性,以便将凭证传递给 Kafka 代理。客户端使用这些属性来传递客户端 ID 和 secret 或用户名和访问令牌。
客户端 ID 和 secret 用于获取访问令牌。
访问令牌作为 密码
属性值传递。您可以使用 或不使用 $accessToken:
前缀传递访问令牌。
-
如果您在监听程序配置中配置令牌端点(
tokenEndpointUri
),则需要使用前缀。 -
如果您没有在监听器配置中配置令牌端点(
tokenEndpointUri
),则不需要这个前缀。Kafka 代理将密码解析为原始访问令牌。
如果 密码
被设置为访问令牌,则 用户名
必须设置为 Kafka 代理从访问令牌获取的相同主体名称。您可以使用 userNameClaim
、fallbackUserNameClaim
、fallUsernamePrefix
和 userInfoEndpointUri
属性在监听程序中指定用户名提取选项。用户名提取过程也取决于您的授权服务器,特别是它如何将客户端 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
, tls
和 external
监听程序,但不建议使用带有 OAuth 2.0 禁用了 TLS 加密的 plain
或 external
监听程序,因为这会产生一个漏洞,通过令牌对网络造成破坏和未经授权的访问。
您可以使用 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
属性。根据授权服务器,通常必须指定 clientId
和 clientSecret
,因为内省端点通常受到保护。
内省端点配置示例
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 机制 username
和 password
属性传递。
侦听器配置支持以下令牌验证选项:
- 您可以基于 JWT 签名检查和本地令牌内省使用快速本地令牌验证,而无需联系授权服务器。授权服务器提供了一个 JWKS 端点,其公共证书用于验证令牌上的签名。
- 您可以使用授权服务器提供的令牌内省端点调用。每次建立新的 Kafka 代理连接时,代理都会将从客户端接收的访问令牌传递给授权服务器。Kafka 代理检查响应,以确认令牌是否有效。
授权服务器可能只允许使用不透明的访问令牌,这意味着无法进行本地令牌验证。
还可以为以下类型的身份验证配置 Kafka 客户端凭证:
- 使用之前生成的长期访问令牌直接进行本地访问
- 与授权服务器联系,以获取要发出的新访问令牌(使用客户端 ID 和 secret 或刷新令牌)
5.4.5.1. 使用 SASL OAUTHBEARER 机制的客户端验证流示例
您可以使用 SASL OAUTHBEARER 机制对 Kafka 身份验证使用以下通信流。
使用客户端 ID 和 secret 的客户端,并将验证委派到授权服务器
- Kafka 客户端使用客户端 ID 和 secret 从授权服务器请求访问令牌,以及可选的刷新令牌。
- 授权服务器生成新的访问令牌。
- Kafka 客户端使用 SASL OAUTHBEARER 机制通过 Kafka 代理进行身份验证,以传递访问令牌。
- Kafka 代理使用自己的客户端 ID 和 secret 调用授权服务器上的令牌内省端点来验证访问令牌。
- 如果令牌有效,则建立 Kafka 客户端会话。
使用客户端 ID 和 secret 的客户端,以及执行快速本地令牌验证的代理
- Kafka 客户端使用令牌端点的授权服务器验证,使用客户端 ID 和 secret,以及可选的刷新令牌。
- 授权服务器生成新的访问令牌。
- Kafka 客户端使用 SASL OAUTHBEARER 机制通过 Kafka 代理进行身份验证,以传递访问令牌。
- Kafka 代理使用 JWT 令牌签名检查和本地令牌内省在本地验证访问令牌。
使用长期访问令牌的客户端,并将验证委派到授权服务器
- Kafka 客户端使用 SASL OAUTHBEARER 机制通过 Kafka 代理进行身份验证,以传递长期的访问令牌。
- Kafka 代理使用自己的客户端 ID 和 secret 调用授权服务器上的令牌内省端点来验证访问令牌。
- 如果令牌有效,则建立 Kafka 客户端会话。
使用长期访问令牌的客户端,以及执行快速本地验证的代理
- Kafka 客户端使用 SASL OAUTHBEARER 机制通过 Kafka 代理进行身份验证,以传递长期的访问令牌。
- Kafka 代理使用 JWT 令牌签名检查和本地令牌内省在本地验证访问令牌。
快速本地 JWT 令牌签名验证仅适用于短传输的令牌,因为如果撤销令牌,则不会检查授权服务器。令牌到期时间写入到令牌中,但可以随时进行撤销,因此无需联系授权服务器即可考虑。任何发出的令牌都将被视为有效,直到它到期为止。
5.4.5.2. 使用 SASL PLAIN 机制的客户端验证流示例
您可以使用 OAuth PLAIN 机制对 Kafka 身份验证使用以下通信流。
使用客户端 ID 和 secret 的客户端,代理获取客户端的访问令牌
-
Kafka 客户端以用户名和
secret
作为密码通过clientId
。 -
Kafka 代理使用令牌端点将
clientId
和secret
传递给授权服务器。 - 如果客户端凭据无效,授权服务器会返回一个全新的访问令牌或错误。
Kafka 代理使用以下方法之一验证令牌:
- 如果指定了令牌内省端点,则 Kafka 代理通过调用授权服务器上的端点来验证访问令牌。如果令牌验证成功,则会建立一个会话。
- 如果使用本地令牌内省,则不会向授权服务器发出请求。Kafka 代理使用 JWT 令牌签名检查在本地验证访问令牌。
使用没有客户端 ID 和 secret 的长期访问令牌的客户端
- Kafka 客户端通过用户名和密码。密码提供在运行客户端之前手动和配置的访问令牌的值。
密码通过 或不使用
$accessToken:
字符串前缀传递,具体取决于 Kafka 代理监听程序配置了用于身份验证的令牌端点。-
如果配置了令牌端点,密码应以
$accessToken:
前缀,以便代理知道 password 参数包含访问令牌而不是客户端 secret。Kafka 代理将用户名解释为帐户用户名。 -
如果没有在 Kafka 代理监听器上配置令牌端点(强制使用
no-client-credentials 模式
),密码应该提供没有前缀的访问令牌。Kafka 代理将用户名解释为帐户用户名。在这个模式中,客户端不使用客户端 ID 和 secret,密码
参数始终被解释为原始访问令牌。
-
如果配置了令牌端点,密码应以
Kafka 代理使用以下方法之一验证令牌:
- 如果指定了令牌内省端点,则 Kafka 代理通过调用授权服务器上的端点来验证访问令牌。如果令牌验证成功,则会建立一个会话。
- 如果使用了本地令牌内省,则不会向授权服务器发出请求。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 访问的信息,请参阅授权服务器的产品文档。
如果您已经部署了授权服务器,您可以跳过部署步骤并使用当前的部署。
流程
- 将授权服务器部署到集群中。
访问授权服务器的 CLI 或管理控制台,以便为 AMQ Streams 配置 OAuth 2.0。
现在,准备授权服务器以用于 AMQ Streams。
-
配置
kafka-broker
客户端。 - 为应用程序的每个 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 授权服务器
流程
在编辑器中更新
Kafka
资源的 Kafka 代理配置(Kafka.spec.kafka
)。oc edit kafka my-cluster
配置 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
根据您应用 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
、freUserNameClaim
和fallbackUserNamePrefix
设置应用于userinfo
端点的响应。 - 7
- 将其设置为
false
,以禁用监听器上的 OAUTHBEARER 机制。必须至少启用 PLAIN 或 OAUTHBEARER 之一。默认为true
。 - 8
- 设置为
true
,以在监听器上启用 PLAIN 身份验证,在所有平台上的客户端都受支持。 - 9
- 用于 PLAIN 机制的其他配置。如果指定,客户端可以使用
$accessToken:
前缀将访问令牌作为密码
传递,通过 PLAIN 进行身份验证。对于生产环境,始终使用https://
urls。 - 10
- 可以在验证过程中对 JWT 访问令牌实施额外的自定义规则,方法是将其设置为 JsonPath 过滤器查询。如果访问令牌不包含必要的数据,则会被拒绝。在使用
introspectionEndpointUri
时,自定义检查将应用到内省端点响应 JSON。 - 11
- 一个
audience
参数传递给令牌端点。在获取用于代理身份验证的访问令牌时,需要使用 使用者。它还使用在 PLAIN 客户端身份验证中使用clientId
和secret
的 OAuth 2.0 客户端名称。这只会影响获取令牌的能力,以及令牌的内容,具体取决于授权服务器。它不会受到监听程序影响令牌验证规则。 - 12
- 传递给令牌端点的
scope
参数。获取访问令牌进行代理身份验证时使用的 范围。它还使用在 PLAIN 客户端身份验证中使用clientId
和secret
的 OAuth 2.0 客户端名称。这只会影响获取令牌的能力,以及令牌的内容,具体取决于授权服务器。它不会受到监听程序影响令牌验证规则。 - 13
- 连接授权服务器时出现连接超时(以秒为单位)。默认值为 60。
- 14
- 连接到授权服务器时读取超时(以秒为单位)。默认值为 60。
- 15
- JsonPath 查询,用于从 JWT 令牌或内省端点响应中提取组信息。默认情况下不设置。这可以由自定义授权者用来根据用户组做出授权决策。
- 16
- 以单个分隔字符串返回时用于解析组信息的分隔符。默认值为 ','(comma)。
- 保存并退出编辑器,然后等待滚动更新完成。
检查日志中的更新,或者查看 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 代理
流程
将支持 OAuth 2.0 的客户端程序库添加到 Kafka 客户端的
pom.xml
文件中:<dependency> <groupId>io.strimzi</groupId> <artifactId>kafka-oauth-client</artifactId> <version>0.10.0.redhat-00014</version> </dependency>
为回调配置系统属性:
例如:
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
在 Kafka 客户端配置中,在 TLS 加密连接中启用 OAUTHBEARER 或 PLAIN 机制。
例如:
为 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
而不是未加密的连接。
- 验证 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 代理
流程
创建客户端 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 格式。
创建或编辑 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
根据您应用 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。
将更改应用到 Kafka 资源的部署。
oc apply -f your-file
检查日志中的更新,或者查看 pod 状态转换:
oc logs -f ${POD_NAME} -c ${CONTAINER_NAME} oc get pod -w
滚动更新配置组件,以使用 OAuth 2.0 身份验证与 Kafka 代理交互。
5.5. 使用基于 OAuth 2.0 令牌的授权
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。
流程
- 访问 Red Hat Single Sign-On Admin Console,或使用 Red Hat Single Sign-On Admin CLI 为设置 OAuth 2.0 身份验证时创建的 Kafka 代理客户端启用授权服务。
- 使用授权服务定义客户端的资源、授权范围、策略和权限。
- 通过分配角色和组,将权限绑定到用户和客户端。
通过在编辑器中更新
Kafka
代理配置Kafka.spec.kafka
,将 Kafka 代理配置为使用 Red Hat Single Sign-On 授权。oc edit kafka my-cluster
将 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。
- 保存并退出编辑器,然后等待滚动更新完成。
检查日志中的更新,或者查看 pod 状态转换:
oc logs -f ${POD_NAME} -c kafka oc get pod -w
滚动更新将代理配置为使用 OAuth 2.0 授权。
- 通过将 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 使用五个资源类型来控制访问: 主题
、组
、Cluster
、TransactionalId
和 DelegationToken
。每个资源类型都有一组可用权限。
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-kafka
或 cluster-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 开始的主题读取
。
其他资源
- 有关如何通过 Red Hat Single Sign-On 授权服务配置权限的更多信息,请参阅 第 5.5.4 节 “试用红帽单点登录授权服务”。
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
显示主题详情
要显示主题详情,在主题上需要 Describe
和 DescribeConfigs
权限。
bin/kafka-topics.sh --describe --topic my-topic \ --bootstrap-server my-cluster-kafka-bootstrap:9092 --command-config=/tmp/config.properties
将消息生成到主题
要将消息生成到主题,主题上需要 Describe
和 Write
权限。
如果主题尚未创建,并且启用了主题自动创建,则需要创建主题的权限。
bin/kafka-console-producer.sh --topic my-topic \ --bootstrap-server my-cluster-kafka-bootstrap:9092 --producer.config=/tmp/config.properties
使用来自主题的消息
为了使用主题中的消息 ,
需要描述和 Read
权限。在主题中使用通常依赖于将消费者偏移存储在消费者组中,这需要对消费者组需要额外的 Describe
和 Read
权限。
匹配需要两个 资源
。例如:
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
更改主题配置
要更改主题的配置,在主题上需要 Describe
和 Alter
权限。
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
上需要 DescribeConfigs
和 AlterConfigs
权限。
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
删除主题
要删除主题,在主题上需要 Describe
和 Delete
权限。
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
上需要 Describe
和 Alter
权限。另外,有关涉及的主题还需要 描述
权限。
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
文件,该文件包含预先配置的域。
流程
- 使用 Red Hat Single Sign-On Operator 安装 Red Hat Single Sign-On 服务器,如 Red Hat Single Sign-On 文档中的服务器安装和配置 中所述。
- 等待 Red Hat Single Sign-On 实例处于运行状态。
获取外部主机名,以访问管理控制台。
NS=sso oc get ingress keycloak -n $NS
在本例中,我们假定 Red Hat Single Sign-On 服务器正在
sso
命名空间中运行。获取
admin
用户的密码。oc get -n $NS pod keycloak-0 -o yaml | less
密码存储为 secret,因此要获取 Red Hat Single Sign-On 实例的配置 YAML 文件,以标识 secret 的名称(
secretKeyRef.name
)。使用 secret 的名称获取明文密码。
SECRET_NAME=credential-keycloak oc get -n $NS secret $SECRET_NAME -o yaml | grep PASSWORD | awk '{print $2}' | base64 -D
在本例中,我们假定 secret 的名称为
credential-keycloak
。使用您获取的用户名
admin
和密码登录 Admin 控制台。使用
https://HOSTNAME
来访问 OpenShift 入口。现在,您可以使用 Admin 控制台将示例域上传到 Red Hat Single Sign-On。
- 单击 Add Realm 以导入示例域。
添加 example
/security/keycloak-authorization/kafka-authz-realm.json
文件,然后点 Create。现在,在 Admin 控制台中将
kafka-authz
作为当前域。默认视图显示 Master 域。
在 Red Hat Single Sign-On Admin Console 中,进入 Clients > kafka > Authorization > Settings,并检查是否将 Decision Strategy 设置为 Affirmative。
Affirmative 策略意味着必须满足至少一个策略来访问 Kafka 集群。
在 Red Hat Single Sign-On Admin Console 中,进入 Groups, Users, Roles 和 Clients 来查看 realm 配置。
- 组
-
组
用于创建用户组并设置用户权限。组是一组分配了名称的用户。它们用于将用户整理到地理、组织或部门单位。组可以链接到 LDAP 身份提供程序。您可以通过自定义 LDAP 服务器 admin 用户界面使用户成为一个组的成员,例如,授予 Kafka 资源的权限。 - 用户
-
用户
用于创建用户。在本例中,定义了alice
和bob
。alice
是ClusterManager
组的成员,bob
是ClusterManager-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-client
和team-b-client
客户端是负责访问某些 Kafka 主题的部分服务的机密客户端。
-
Kafka 代理使用
在 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_*
、Describe
和Write
范围以及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
自定义资源。
流程
使用您部署的 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)连接。
将证书作为机密部署到 OpenShift。
oc create secret generic oauth-server-cert --from-file=/tmp/sso.crt -n $NS
将主机名设置为环境变量
SSO_HOST=SSO-HOSTNAME
创建并部署示例 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 集群。
流程
使用 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 错误。附加到 pod 容器。
oc attach -ti kafka-cli -n $NS
使用 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
为与 Kafka 代理的 TLS 连接创建信任存储。
keytool -keystore /tmp/truststore.p12 -storetype pkcs12 -alias sso -storepass $STOREPASS -import -file /tmp/sso.crt -noprompt
使用 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
将 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-client
和 team-b-client
客户端检查授权规则。使用 alice
admin 用户在 Kafka 上执行额外的管理任务。
本例中使用的 AMQ Streams Kafka 镜像包含 Kafka producer 和 consumer 二进制文件。
先决条件
- zookeeper 和 Kafka 在 OpenShift 集群中运行,以便能够发送和接收信息。
设置客户端和 admin 用户配置
使用
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 代理并使用访问令牌进行身份验证。
准备 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
使用
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}')
刷新令牌是一个离线令牌,它是长期的且无法过期。
使用 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_
开头的主题。
将 写入到主题
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
的主题都匹配这些规则。将 写入到主题
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 中成功生成信息。
- 按 CTRL+C 退出 CLI 应用程序。
检查 Kafka 容器日志,获取请求的
Authorization GRANTED
的 debug 日志。oc logs my-cluster-kafka-0 -f -n $NS
使用具有授权访问权限的消息
使用 team-a-client
配置来消耗主题 a_messages
中的消息。
从主题
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-client
的Dev Team A
角色只能访问具有以_
开始名称的消费者组。更新
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
是一个没有集群级别访问权限的帐户,但它可用于一些管理操作。
列出主题。
bin/kafka-topics.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --command-config /tmp/team-a-client.properties --list
返回
a_messages
主题。列出使用者组。
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_
开头的主题生成消息。
将 写入到主题
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]
错误。将主题
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 中成功生成信息。
将 写入到主题
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
中读取。使用
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 集群上的所有内容的完整访问权限。
以
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
主题创建成功。
列出所有主题为
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-client
和team-b-client
只能列出它们可访问的主题。Dev 团队 A
和Dev Team B
角色都描述
以x_
开头的主题,但它们无法看到其他组的主题,因为它们没有描述
权限。使用
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 Message 2 Message 3
因为
alice
创建x_messages
主题,因此成功生成给 Kafka 的信息。使用
team-b-client
向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 4 Message 5
此请求返回
Not authorized 以访问主题:[x_messages]
错误。使用
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
主题的所有消息。使用
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]
错误。使用
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
访问权限。使用
alice
向x_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
可以从任何主题读取或写入。使用
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 集群有匹配的标签时,才会执行KafkaRebalance
和KafkaConnector
资源。env: - name: STRIMZI_CUSTOM_RESOURCE_SELECTOR value: label1=value1,label2=value2
STRIMZI_KAFKA_IMAGES
-
必需。这可让您从 Kafka 版本映射到包含该版本的 Kafka 代理的对应 Docker 镜像。所需语法是空格或逗号分隔 <
version> = <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> = <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> = <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
资源,以及对其他自定义资源(Kafka
、KafkaConnect
等等)的任何更改。这个模式有助于确保根据需要重新创建 Pod,但不会对集群进行其他更改。 STRIMZI_FEATURE_GATES
- 可选。启用或禁用由 功能门 控制的功能和功能。
6.2.1.1. ConfigMap 的日志记录配置
Cluster Operator 的日志记录由 strimzi-cluster-operator
ConfigMap
配置。
安装 Cluster Operator 时会创建包含日志记录配置的 ConfigMap
。此 ConfigMap
在 install/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
要更改重新加载间隔的频率,请在所创建 ConfigMap
的 monitorInterval
选项中设置一个时间(以秒为单位)。
如果部署 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 集群中的权限,以便与 Kafka
、KafkaConnect
等资源交互,以及受管资源,如 ConfigMap
、Pod
、Deployment
、StatefulSet
和服务
。这些权限包括在 OpenShift 基于角色的访问控制(RBAC)资源中:
-
ServiceAccount
、 -
角色和
ClusterRole
, -
Rolebinding
和ClusterRoleBinding
。
除了在带有 ClusterRoleBinding
的 ServiceAccount
下运行,Cluster Operator 还为需要访问 OpenShift 资源的组件管理一些 RBAC 资源。
OpenShift 还包括特权升级保护,防止一个 ServiceAccount
下运行的组件授予授予 ServiceAccount
不具有的其他 ServiceAccount
权限。因为 Cluster Operator 必须能够创建 ClusterRoleBindings
和它管理的资源所需的 RoleBindings
,所以 Cluster Operator 还必须具有同样的权限。
6.2.1.5. 委派的权限
当 Cluster Operator 为所需的 Kafka
资源部署资源时,它还会创建 ServiceAccounts
、RoleBindings
和 ClusterRoleBindings
,如下所示:
Kafka 代理 pod 使用一个名为
cluster-name-kafka
的ServiceAccount
-
当使用 rack 功能时,会使用
strimzi-cluster-name-kafka-init
ClusterRoleBinding
通过名为strimzi-kafka-broker
的ClusterRole
授予这个ServiceAccount
访问权限 - 如果不使用机架功能,且集群不会通过 nodeport 公开,则不会创建绑定
-
当使用 rack 功能时,会使用
-
ZooKeeper pod 使用一个名为
cluster-name-zookeeper
的ServiceAccount
Entity Operator pod 使用一个名为
cluster-name-entity-operator
的ServiceAccount
-
Topic Operator 生成带有状态信息的 OpenShift 事件,因此
ServiceAccount
绑定到一个名为strimzi-entity-operator
的ClusterRole
,它通过strimzi-entity-operator
RoleBinding
授予此访问权限
-
Topic Operator 生成带有状态信息的 OpenShift 事件,因此
-
KafkaConnect
资源的 pod 使用一个名为cluster-name-cluster-connect
的ServiceAccount
-
KafkaMirrorMaker
的 pod 使用一个名为cluster-name-mirror-maker
的ServiceAccount
-
KafkaMirrorMaker2
的 pod 使用一个名为cluster-name-mirrormaker2
的ServiceAccount
-
KafkaBridge
的 pod 使用一个名为cluster-name-bridge
的ServiceAccount
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 资源,如 StatefulSets
、Deployment
、Pod
和 ConfigMap
。
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 需要 ClusterRoleBindings
和 RoleBindings
,它将其 ClusterRole
与 ServiceAccount
相关联:包含集群范围资源的 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_PROXY
、HTTPS_PROXY
和 NO_PROXY
)作为环境变量。代理设置适用于所有 AMQ Streams 容器。
代理地址的格式是 http://IP-ADDRESS:PORT-NUMBER。要使用名称和密码设置代理,格式为 http://USERNAME:PASSWORD@IP-ADDRESS:PORT-NUMBER。
先决条件
此流程需要使用 OpenShift 用户帐户来创建 CustomResourceDefinitions
、ClusterRoles
和 ClusterRoleBindings
。在 OpenShift 集群中使用 Role Base Access Control (RBAC)通常意味着创建、编辑和删除这些资源的权限仅限于 OpenShift 集群管理员,如 system:admin
。
流程
要在 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 # ...
或者,直接编辑
Deployment
:oc edit deployment strimzi-cluster-operator
如果您更新了 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 集群上运行。
流程
要在 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
如果您更新了 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 #...
同步副本与生产者应用的 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-topic 的 KafkaTopic
。当主题 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
更改主题名称
-
使用
先决条件
- 使用 TLS 身份验证和加密配置带有 Kafka 代理监听程序的 正在运行的 Kafka 集群。
- 正在运行的主题 Operator (通常使用 Entity Operator 部署)。
-
要删除主题,请在
Kafka
资源的spec.kafka.config
中的delete.topic.enable=true
(默认)。
流程
配置
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
来获取资源的当前版本。在 OpenShift 中创建
KafkaTopic
资源。oc apply -f <topic_config_file>
等待主题的就绪状态更改为
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
时,主题创建成功。如果
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 正在运行。
流程
根据需要,在编辑器中更新 Kafka 集群配置:
oc edit kafka MY-CLUSTER
在
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
应用新配置来创建或更新资源。
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 < ;user_name>
用户代表 Kafka 客户端。配置 Kafka 用户时,您可以启用客户端访问 Kafka 所需的用户身份验证和授权机制。所用的机制必须与对应的 Kafka
配置匹配。有关使用 Kafka
和 KafkaUser
资源保护对 Kafka 代理的访问的更多信息,请参阅 保护对 Kafka 代理的访问。
先决条件
- 使用 TLS 身份验证和加密配置带有 Kafka 代理监听程序的 正在运行的 Kafka 集群。
- 正在运行的用户 Operator (通常使用 Entity Operator 部署)。
流程
配置
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: "*"
在 OpenShift 中创建
KafkaUser
资源。oc apply -f <user_config_file>
等待用户就绪状态更改为
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
时,用户创建成功。如果
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 正在运行。
流程
根据需要,在编辑器中更新 Kafka 集群配置:
oc edit kafka MY-CLUSTER
在
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 部署引入该功能。
功能门的默认状态是 enabled 或 disabled。
要修改功能门的默认状态,请在 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 节点都有
controller
和broker
KRaft 角色。不支持具有独立controller
和broker
节点的 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 核心功能中,且无法禁用。
功能门 | alpha | beta | GA |
---|---|---|---|
| 1.8 | 2.0 | - |
| 1.8 | 2.0 | - |
| 2.1 | - | - |
| 2.2 | - | - |
如果启用了功能门,您可能需要在从特定的 AMQ Streams 版本升级或降级前禁用它。下表显示了在升级或降级 AMQ Streams 版本时需要禁用哪些功能门。
禁用功能门 | 从 AMQ Streams 版本升级 | 降级到 AMQ Streams 版本 |
---|---|---|
| 1.7 及更早版本 | 1.7 及更早版本 |
| - | 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 项目中开发的大部分优化目标。支持的目标按默认优先级降序排列,如下所示:
- rack-awareness
- 一组主题的每个代理的最小领导副本数
- 副本容量
容量目标
- 磁盘容量
- 网络入站容量
- 网络出站容量
- CPU 容量
- 副本分发
- 潜在的网络输出
资源分布目标
- 磁盘使用分布
- 网络入站利用率分布
- 网络出站利用率分布
- CPU 使用率分发
- leader 字节(以字节为单位)分布
- 主题副本分发
- 领导副本分发
- 首选领导机制
- in-broker 磁盘容量
- intra-broker 磁盘用量分布
有关每个优化目标的更多信息,请参阅 Cruise Control Wiki 中的 Goals。
"编写您自己的"目标和 Kafka 分配器目标尚不受支持。
7.2.2. AMQ Streams 自定义资源中的目标配置
您可以在 Kafka
和 KafkaRebalance
自定义资源中配置优化目标。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 节 “生成优化方案”。
其他资源
- 使用 Kafka 配置和部署 Cruise 控制
- Cruise Control Wiki 中的配置。
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-brokers
和 remove-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. 优化建议概述属性
下表说明了优化建议部分中包含的属性。
JSON 属性 | Description |
---|---|
| 集群代理磁盘之间传输的分区副本数量。
重新平衡操作期间的性能影响 :相对高,但小于 |
| 尚不受支持。返回空列表。 |
| 在独立代理之间移动的分区副本数量。 重新平衡操作期间的性能影响 :相对高. |
| Kafka 集群的整体 平衡 度量,在生成优化建议前和之后。
分数的计算是通过减去每个违反软目标的
|
|
在同一代理上的磁盘间移动的每个分区副本的总和(请参阅
重新平衡操作期间的性能影响 :变量.集群重新平衡所需的时间越大,完成集群重新平衡所需的时间。在同一代理上的磁盘间移动大量数据的影响要低于独立的代理(请参阅 |
| 优化提议的指标窗口数量。 |
|
将移到一个单独的代理的每个分区副本的大小总和(请参阅 重新平衡操作期间的性能影响 :变量.集群重新平衡所需的时间越大,完成集群重新平衡所需的时间。 |
|
Kafka 集群中由优化提议覆盖的分区百分比。受 |
|
如果您在 |
| 领导程序切换到不同副本的分区数量。这包括对 ZooKeeper 配置的更改。 重新平衡操作期间的性能影响 :相对较低的. |
| 尚不受支持。返回空列表。 |
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 |
---|---|
| 这个代理中的副本数量是分区领导的。 |
| 此代理上的副本数量。 |
| CPU 使用率作为定义容量的百分比。 |
| 磁盘利用率作为定义容量的百分比。 |
| 绝对磁盘使用量(以 MB 为单位)。 |
| 代理的网络输出率总数。 |
| 此代理上所有分区领导副本的网络输入率。 |
| 此代理中所有后续副本的网络输入率。 |
| 如果此代理成为当前主机的所有副本的领导人,则这种代理成为当前主机的所有副本的领导数,这将实现的最多网络输出率。 |
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
下设置。
下表总结了相关的配置。
Cruise Control 属性 | KafkaRebalance 属性 | 默认 | Description |
---|---|---|---|
|
| 5 | 每个分区重新分配批量的最大代理分区移动数 |
|
| 2 | 每个分区重新分配批量的最大内代理分区移动数 |
|
| 1000 | 每个分区重新分配批量的分区领导更改的最大数量 |
|
| null (无限制) | 分配给分区的带宽(以字节/秒为单位) |
|
|
|
用于决定针对生成的提议执行分区重新分配命令的策略列表(按优先级顺序)。对于 server 设置,使用具有策略类完全限定名称(add |
- |
| 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
流程
编辑
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
- 4
- 为对 Cruise Control API 的只读访问 启用并配置 CORS。
- 5
- 6
- 通过 ConfigMap 直接添加(
内联
)或间接(外部 )的控制
日志记录器和日志级别。自定义 ConfigMap 必须放在log4j.properties
键下。Cruise Control 有一个名为rootLogger.level
的单个日志记录器。您可以将日志级别设置为 INFO、ERROR、WARN、TRACE、DEBUG、FATAL 或 OFF。 - 7
- 模板自定义。此处为 pod 调度了额外的安全属性。
- 8
- 状况检查,了解何时重启容器(持续)以及容器是否可以接受流量(就绪状态)。
- 9
- 启用 Prometheus 指标。在本例中,为 Prometheus JMX Exporter 配置指标(默认指标导出器)。
创建或更新资源:
oc apply -f <kafka_configuration_file>
检查部署的状态:
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 才能正常工作,且不得删除或更改。您可以使用指定的配置选项更改主题名称。
自动创建的主题配置 | 默认主题名称 | 创建者 | 功能 |
---|---|---|---|
|
| AMQ Streams Metrics Reporter | 将 Metrics Reporter 中的原始指标存储在每个 Kafka 代理中。 |
|
| Sything Control | 存储每个分区的派生指标。它们由 指标示例聚合器 创建。 |
|
| 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 集群前重新平衡。如需更多信息,请参阅 使用代理扩展 重新平衡模式。
先决条件
- 您已将 Cruise Control 部署到 AMQ Streams 集群。
- 您已配置 优化目标,以及可选的 broker 资源的容量限制。
流程
创建
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
- 要通过缩减操作删除的代理列表。这个属性是必需的。
注意无论使用的重新平衡模式如何,以下步骤以及批准或停止重新平衡的步骤都相同。
要配置 用户提供的优化目标 而不使用默认的目标,请添加
目标
属性并输入一个或多个目标。在以下示例中,机架意识和副本容量配置为用户提供的优化目标:
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaRebalance metadata: name: my-rebalance labels: strimzi.io/cluster: my-cluster spec: goals: - RackAwareGoal - ReplicaCapacityGoal
要忽略配置的硬目标,请添加
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
创建或更新资源:
oc apply -f <kafka_rebalance_configuration_file>
Cluster Operator 从 Cruise Control 请求优化探测。这可能需要几分钟时间,具体取决于 Kafka 集群的大小。
等待优化提议的状态更改为
ProposalReady
:oc get kafkarebalance -o wide -w -n <namespace>
PendingProposal
-
PendingProposal
状态意味着重新平衡 Operator 正在轮询 Cruise Control API 来检查优化提议是否就绪。 ProposalReady
-
ProposalReady
状态表示优化提议已准备好审核和批准。
当状态变为
ProposalReady
时,优化提议可以批准。回顾优化方案。
优化的提议包含在
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. 批准优化方案
如果它的状态是 ProposalReady
,您可以批准 Cruise Control 生成的 优化提议。然后,Cruise Control 将对 Kafka 集群应用优化建议,将分区重新分配给代理和更改分区领导。
这不是空运行。在批准优化方案前,您必须:
- 刷新提议(如果过期)。
- 请仔细检查 提议的内容。
先决条件
- 您已从 Cruise 控制中 生成了优化的提议。
-
KafkaRebalance
自定义资源状态为ProposalReady
。
流程
对您要批准的优化提议执行这些步骤。
除非新生成的优化提议,否则请检查它是否基于有关 Kafka 集群状态的最新信息。要做到这一点,刷新优化方案以确保它使用最新的集群指标:
使用
strimzi.io/rebalance=refresh
注解 OpenShift 中的KafkaRebalance
资源:oc annotate kafkarebalance <kafka_rebalance_resource_name> strimzi.io/rebalance=refresh
等待优化提议的状态更改为
ProposalReady
:oc get kafkarebalance -o wide -w -n <namespace>
PendingProposal
-
PendingProposal
状态意味着重新平衡 Operator 正在轮询 Cruise Control API 来检查优化提议是否就绪。 ProposalReady
-
ProposalReady
状态表示优化提议已准备好审核和批准。
当状态变为
ProposalReady
时,优化提议可以批准。批准您希望 Cruise Control 适用的优化方案。
使用
strimzi.io/rebalance=approve
给 OpenShift 中的KafkaRebalance
资源标注:oc annotate kafkarebalance <kafka_rebalance_resource_name> strimzi.io/rebalance=approve
- Cluster Operator 检测到注解的资源,并指示 Cruise Control 来重新平衡 Kafka 集群。
等待优化提议的状态更改为
Ready
:oc get kafkarebalance -o wide -w -n <namespace>
重新平衡
-
重新平衡
状态意味着重新平衡正在进行。 Ready
-
Ready
状态表示重新平衡已完成。 NotReady
-
NotReady
状态表示发生错误 - 请参阅KafkaRebalance
资源中的修复问题。
当状态变为
Ready
时,重新平衡即完成。要使用同一个
KafkaRebalance
自定义资源来生成另一个优化的提议,请将刷新
注解应用到自定义资源。这会将自定义资源移到PendingProposal
或ProposalReady
状态。然后,您可以审查优化方案,并根据需要批准它。
7.8. 停止集群重新平衡
启动后,集群重新平衡操作可能需要一些时间才能完成,并影响 Kafka 集群的整体性能。
如果要停止进行中的集群重新平衡操作,请将 stop
注解应用到 KafkaRebalance
自定义资源。这会指示 Cruise Control 完成当前的分区重新分配,然后停止重新平衡。当重新平衡停止后,已应用完成的分区重新分配量;因此,与开始重新平衡操作之前,Kafka 集群的状态会不同。如果需要进一步重新平衡,您应该生成新的优化提议。
Kafka 集群处于中间(停止)状态的性能可能比初始状态更糟。
先决条件
-
您已通过使用
approve
注解了KafkaRebalance
自定义资源来批准优化的提议。 -
KafkaRebalance
自定义资源的状态是重新平衡
。
流程
在 OpenShift 中注解
KafkaRebalance
资源:oc annotate kafkarebalance rebalance-cr-name strimzi.io/rebalance=stop
检查
KafkaRebalance
资源的状态:oc describe kafkarebalance rebalance-cr-name
-
等待状态变为
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
。
流程
从
KafkaRebalance
状态获取有关错误的信息:oc describe kafkarebalance rebalance-cr-name
-
尝试解决
KafkaRebalance
资源中的问题。 在 OpenShift 中注解
KafkaRebalance
资源:oc annotate kafkarebalance rebalance-cr-name strimzi.io/rebalance=refresh
检查
KafkaRebalance
资源的状态:oc describe kafkarebalance rebalance-cr-name
-
等待状态变为
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 中的模式。这样可确保一致的模式使用,并帮助在运行时防止数据错误。
其他资源
- Service Registry 文档
- Service Registry 基于 GitHub 上可用的 Apicurio Registry 开源社区项目构建:Apicur io/apicurio-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 设置追踪,请按照以下步骤执行:
为客户端设置追踪:
使用 tracers 检测客户端:
- 为 MirrorMaker、Kafka Connect 和 Kafka Bridge 设置追踪
先决条件
- Jaeger 后端组件部署到 OpenShift 集群。有关部署说明,请参阅 Jaeger 文档。
9.1. OpenTracing 和 Jaeger 概述
AMQ Streams 使用 OpenTracing 和 Jaeger 项目。
OpenTracing 是一种独立于追踪或监控系统的 API 规范。
- OpenTracing API 用于检测 应用代码
- 检测的应用程序会在 分布式系统中为独立事务生成追踪
- trace 由 范围 组成,它们定义一段时间内的特定工作单元
Jaeger 是基于微服务的分布式系统的追踪系统。
- Jaeger 实施 OpenTracing API,并提供客户端库以用于检测
- Jaeger 用户界面允许您查询、过滤和分析追踪数据
其他资源
9.2. 为 Kafka 客户端设置追踪
初始化 Jaeger tracer,以检测您的客户端应用程序以进行分布式追踪。
9.2.1. 为 Kafka 客户端初始化 Jaeger tracer
使用一组 追踪环境变量 配置和初始化 Jaeger tracer。
流程
在每个客户端应用程序中:
将 Jaeger 的 Maven 依赖项添加到客户端应用程序的
pom.xml
文件中:<dependency> <groupId>io.jaegertracing</groupId> <artifactId>jaeger-client</artifactId> <version>1.5.0.redhat-00001</version> </dependency>
- 使用 追踪环境变量 定义 Jaeger tracer 的配置。
从您在第两个步骤中定义的环境变量创建 Jaeger tracer:
Tracer tracer = Configuration.fromEnv().getTracer();
注意有关初始化 Jaeger tracer 的替代方法,请参阅 Java OpenTracing 库 文档。
将 Jaeger tracer 注册为全局 tracer:
GlobalTracer.register(tracer);
现在,为要使用的客户端应用程序初始化 Jaeger tracer。
9.2.2. 用于追踪的环境变量
在为 Kafka 客户端配置 Jaeger tracer 时使用这些环境变量。
追踪环境变量是 Jaeger 项目的一部分,可能会有所变化。有关最新的环境变量,请参阅 Jaeger 文档。
属性 | 必需 | Description |
---|---|---|
| 是 | Jaeger tracer 服务的名称。 |
| 否 |
通过 User Datagram Protocol (UDP)与 |
| 否 |
用于通过 UDP 与 |
| 否 |
|
| 否 | 以 bearer 令牌的形式发送到端点的身份验证令牌。 |
| 否 | 如果使用基本身份验证发送到端点的用户名。 |
| 否 | 如果使用基本身份验证发送到端点的密码。 |
| 否 |
用于传播 trace 上下文的以逗号分隔的格式列表。默认为标准 Jaeger 格式。有效值为 |
| 否 | 指明报告程序是否还应记录范围。 |
| 否 | 报告者的最大队列大小。 |
| 否 | 报告者的清除间隔,以 ms 为单位。定义 Jaeger reporter flushes span batches 的频率。 |
| 否 | 用于客户端 trace 的抽样策略:
要示例所有 trace,请使用 Constant sampling 策略和参数 1。 如需了解 Jaeger 架构和客户端抽样配置参数概述,请参阅 Jaeger 文档。 |
| 否 | sampler 参数(数字)。 |
| 否 | 如果选择了 Remote sampling 策略,要使用的主机名和端口。 |
| 否 | 添加到所有报告的 span 的 tracer 级别标签的逗号分隔列表。
该值也可以使用 |
9.3. 使用 tracer 检查 Kafka 客户端
检测 Kafka producer 和使用者客户端,以及用于分布式追踪的 Kafka Streams API 应用程序。
9.3.1. 提取制作者和消费者以进行追踪
使用 Decorator 模式或 Interceptors 来检测您的 Java 制作者和消费者应用程序代码进行追踪。
流程
在每个制作者和消费者应用程序的应用程序代码中:
将 OpenTracing 的 Maven 依赖项添加到制作者或消费者的
pom.xml
文件。<dependency> <groupId>io.opentracing.contrib</groupId> <artifactId>opentracing-kafka-client</artifactId> <version>0.1.15.redhat-00006</version> </dependency>
使用 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 模式检测您的制作者和消费者应用程序,请在创建 TracingKafkaProducer
和 TracingKafkaConsumer
对象时将 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_NAME
和 PRODUCER_OPERATION_NAME
。
BiFunction | Description |
---|---|
|
返回 |
|
返回 |
|
以格式 |
|
返回 |
|
返回操作名称和主题名称:" |
|
返回 |
9.3.2. 用于追踪的 Kafka Streams 应用程序
本节论述了如何使用 Kafka Streams API 应用程序进行分布式追踪。
流程
在每个 Kafka Streams API 应用程序中:
将
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>
创建
TracingKafkaClientSupplier
供应商接口实例:KafkaClientSupplier supplier = new TracingKafkaClientSupplier(tracer);
为
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 资源中启用追踪
更新 KafkaMirrorMaker
、KafkaMirrorMaker2
、KafkaConnect
和 KafkaBridge
自定义资源的配置,为每个资源指定并配置 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。
流程
为每个 KafkaMirrorMaker
、KafkaMirrorMaker2
、KafkaConnect
和 KafkaBridge
资源执行这些步骤。
在
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 #...
创建或更新资源:
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.clusterCa
和 Kafka.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,则必须在证书文件中包括整个链。链应该按照以下顺序:
- 集群或客户端 CA
- 一个或多个中间 CA
- 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 格式中包含证书。
流程
替换 Cluster Operator 生成的 CA 证书。
删除现有的 secret。
oc delete secret CA-CERTIFICATE-SECRET
ca-CERTIFICATE-SECRET 是
Secret
的名称:-
集群 CA 证书的
CLUSTER-NAME-cluster-ca-cert
-
CLUSTER-NAME-clients-ca-cert
用于客户端 CA 证书
将 CLUSTER-NAME 替换为 Kafka 集群的名称。
忽略任何 "Not Exists" 错误。
-
集群 CA 证书的
创建新 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
替换 Cluster Operator 生成的私钥。
删除现有的 secret。
oc delete secret CA-KEY-SECRET
ca-KEY-SECRET 是 CA 密钥的名称:
-
集群 CA 键的
CLUSTER-NAME-cluster-ca
-
客户端 CA 密钥的
CLUSTER-NAME-clients-ca
-
集群 CA 键的
创建新 secret。
oc create secret generic CA-KEY-SECRET --from-file=ca.key=ca.key
标记 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 集群。
-
标签
注解 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 证书。在更新证书时设置更高的增量值。
-
注解
为集群创建
Kafka
资源,配置Kafka.spec.clusterCa
或Kafka.spec.clientsCa
对象来 不使用 生成的 CA。配置集群 CA 的片段
Kafka
资源示例,使用您提供的证书kind: Kafka version: kafka.strimzi.io/v1beta2 spec: # ... clusterCa: generateCertificateAuthority: false
其他资源
- 要续订之前安装的 CA 证书,请参阅 第 10.3.5 节 “更新您自己的 CA 证书”。
- 要替换您之前安装的 CA 证书的私钥,请参考 第 10.3.6 节 “替换您自己的 CA 证书使用的私钥”。
- 第 10.7.1 节 “提供您自己的 Kafka 侦听器证书”.
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 代理证书。
字段 | Description |
---|---|
| 集群 CA 的当前私钥。 |
字段 | Description |
---|---|
| PKCS #12 归档文件用于存储证书和密钥。 |
| 用于保护 PKCS #12 归档文件的密码。 |
| 集群 CA 的当前证书。 |
字段 | Description |
---|---|
| PKCS #12 归档文件用于存储证书和密钥。 |
| 用于保护 PKCS #12 归档文件的密码。 |
|
Kafka 代理 pod < num> 的证书。由 <cluster |
|
Kafka 代理 pod < |
字段 | Description |
---|---|
| PKCS #12 归档文件用于存储证书和密钥。 |
| 用于保护 PKCS #12 归档文件的密码。 |
|
ZooKeeper node < num> 的证书。由 <cluster |
|
ZooKeeper pod < |
字段 | Description |
---|---|
| PKCS #12 归档文件用于存储证书和密钥。 |
| 用于保护 PKCS #12 归档文件的密码。 |
|
Cluster Operator 和 Kafka 或 ZooKeeper 之间的 TLS 通信的证书。由 <cluster |
| Cluster Operator 和 Kafka 或 ZooKeeper 之间的 TLS 通信的私钥。 |
字段 | Description |
---|---|
| PKCS #12 归档文件用于存储证书和密钥。 |
| 用于保护 PKCS #12 归档文件的密码。 |
|
主题 Operator 和 Kafka 或 ZooKeeper 之间的 TLS 通信证书。由 <cluster |
| 适用于主题 Operator 和 Kafka 或 ZooKeeper 间的 TLS 通信的私钥。 |
字段 | Description |
---|---|
| PKCS #12 归档文件用于存储证书和密钥。 |
| 用于保护 PKCS #12 归档文件的密码。 |
|
用户 Operator 和 Kafka 或 ZooKeeper 之间的 TLS 通信证书。由 <cluster |
| 用户 Operator 和 Kafka 或 ZooKeeper 之间的 TLS 通信的私钥。 |
字段 | Description |
---|---|
| PKCS #12 归档文件用于存储证书和密钥。 |
| 用于保护 PKCS #12 归档文件的密码。 |
|
Cruise 控制和 Kafka 或 ZooKeeper 之间的 TLS 通信证书。由 <cluster |
| 用于 Cruise 控制和 Kafka 或 ZooKeeper 之间的 TLS 通信的私钥。 |
字段 | Description |
---|---|
| PKCS #12 归档文件用于存储证书和密钥。 |
| 用于保护 PKCS #12 归档文件的密码。 |
|
Kafka Exporter 和 Kafka 或 ZooKeeper 之间的 TLS 通信证书。由 <cluster |
| Kafka Exporter 和 Kafka 或 ZooKeeper 之间的 TLS 通信的私钥。 |
10.2.4. 客户端 CA secret
客户端 CA secret 由 Kafka 集群中的 Cluster Operator 管理。
< cluster_name> -clients-ca-cert
中的证书是 Kafka 代理信任的证书。
& lt;cluster_name> -clients-ca
secret 用于签署客户端应用程序的证书。如果打算在不使用 User Operator 的情况下发布应用程序证书,则必须访问该 secret。AMQ Streams 组件以及管理访问权限需要被访问。如果需要,您可以使用 OpenShift 基于角色的访问控制来执行此操作。
字段 | Description |
---|---|
| 客户端 CA 的当前私钥。 |
字段 | Description |
---|---|
| PKCS #12 归档文件用于存储证书和密钥。 |
| 用于保护 PKCS #12 归档文件的密码。 |
| 客户端 CA 的当前证书。 |
10.2.5. 用户 secret
用户 secret 由 User Operator 管理。
使用 User Operator 创建用户时,会使用用户名称生成 secret。
Secret 名称 | secret 中的字段 | Description |
---|---|---|
|
| PKCS #12 归档文件用于存储证书和密钥。 |
| 用于保护 PKCS #12 归档文件的密码。 | |
| 用户的证书,由客户端 CA 签名 | |
| 用户的私钥 |
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 的行为取决于证书生成属性的设置,generateCertificateAuthority
和 generateCertificateAuthority
。
true
-
如果属性被设置为
true
,Cluster Operator 会自动生成 CA 证书,并在续订周期内自动续订。 false
-
如果属性设置为
false
,Cluster Operator 不会生成 CA 证书。如果您要 安装自己的证书,则使用此选项。
10.3.1. 使用自动生成的 CA 证书的续订过程
Cluster Operator 执行以下操作以续订 CA 证书:
-
生成新的 CA 证书,但保留现有的密钥。新证书将旧证书替换为对应
Secret
中的名称ca.crt
。 - 生成新客户端证书(用于 ZooKeeper 节点、Kafka 代理和实体 Operator)。这并非绝对必要,因为签名密钥没有更改,但它会使客户端证书的有效性期与 CA 证书保持同步。
- 重启 ZooKeeper 节点,以便他们信任新的 CA 证书并使用新的客户端证书。
- 重启 Kafka 代理,以便它们信任新的 CA 证书并使用新的客户端证书。
- 重启主题和用户 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 集群。
流程
将
strimzi.io/force-renew
注解应用到包含您要续订的 CA 证书的Secret
。表 10.13. 强制续订证书的 Secret 注解 证书 Secret annotate 命令 集群 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 证书。
检查 CA 证书的期间:
例如,使用
openssl
命令:oc get secret CA-CERTIFICATE-SECRET -o 'jsonpath={.data.CA-CERTIFICATE}' | base64 -d | openssl x509 -subject -issuer -startdate -enddate -noout
CA-CERTIFICATE-SECRET 是
Secret
的名称,即KAFKA-CLUSTER-NAME-cluster-ca-cert
,用于集群 CA 证书和KAFKA-CLUSTER-NAME-clients-ca-cert
。CA-CERTIFICATE 是 CA 证书的名称,如
jsonpath={.data.ca\.crt}
。该命令返回一个
notBefore
和notAfter
日期,这是 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
从 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. 替换私钥的命令 私钥: Secret annotate 命令 集群 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 证书。
先决条件
- Cluster Operator 正在运行。
- 已安装自己的 CA 证书和私钥。
- 您有 PEM 格式的新集群或客户端 X.509 证书。
流程
更新 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
将新 CA 证书编码为 base64。
cat <path_to_new_certificate> | base64
更新 CA 证书。
将上一步中的 base64 编码的 CA 证书复制为
data
下的ca.crt
属性的值。增加 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 证书续订时递增。使用新的 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
在下一协调中,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 证书。
先决条件
- Cluster Operator 正在运行。
- 已安装自己的 CA 证书和私钥。
- 您有 PEM 格式的新集群或客户端 X.509 证书和密钥。
流程
暂停
Kafka
自定义资源的协调。在 OpenShift 中注解自定义资源,将
pause-recon
ation 注解设置为true
:oc annotate Kafka <name_of_custom_resource> strimzi.io/pause-reconciliation="true"
例如,对于名为
my-cluster
的Kafka
自定义资源:oc annotate Kafka my-cluster strimzi.io/pause-reconciliation="true"
检查自定义资源的状态条件是否显示 Reconliation
Paused
的更改:oc describe Kafka <name_of_custom_resource>
类型
条件会改变在lastTransitionTime
中用于 ReconliationPaused
。
更新 CA 证书的
Secret
。编辑现有的 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
重命名当前 CA 证书以保留它。
将
data
下的ca.crt
属性重命名为ca- <date> .crt
,其中 & lt;date > 是证书过期日期,格式为 YEAR-MONTH-DAYTHOUR-MINUTE-SECONDZ。例如,ca-2022-01-26T17-32-00Z.crt:
保留 属性的值,因为它要保留当前的 CA 证书。将新 CA 证书编码为 base64。
cat <path_to_new_certificate> | base64
更新 CA 证书。
在
data
下创建一个新的ca.crt
属性,并将上一步中的 base64 编码的 CA 证书复制为ca.crt
属性的值。增加 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 证书续订时递增。使用新的 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
更新用于为新 CA 证书签名的 CA 密钥的
Secret
。编辑现有 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
将 CA 密钥编码为 base64。
cat <path_to_new_key> | base64
更新 CA 密钥。
将上一步中的 base64 编码的 CA 密钥复制为
data
下的ca.key
属性的值。增加 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 证书续订时递增。
使用新的 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
从暂停中恢复。
要恢复
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.listeners
的 tls
属性进行配置。
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)
在定义客户端 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 配置
使用以下属性配置 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)
在定义客户端 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
- 将证书与使用 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)
从 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 集群的名称。
使用以下属性配置 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)
从 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
- 将证书与使用 X.509 格式的证书的客户端一起使用。
10.7. Kafka 侦听器证书
您可以为启用 TLS 加密的任何监听程序提供自己的服务器证书和私钥。这些用户提供的证书称为 Kafka 侦听器证书。
提供 Kafka 侦听器证书允许您利用现有的安全基础架构,如您组织的私有 CA 或公共 CA。Kafka 客户端需要信任用于为监听程序证书签名的 CA。
在需要时,您必须手动续订 Kafka 侦听器证书。
10.7.1. 提供您自己的 Kafka 侦听器证书
此流程演示了如何将侦听器配置为使用您自己的私钥和服务器证书,称为 Kafka 侦听器证书。
您的客户端应用程序应使用 CA 公钥作为可信证书,以验证 Kafka 代理的身份。
先决条件
- OpenShift 集群。
- Cluster Operator 正在运行。
对于每个监听程序,由外部 CA 签名的兼容服务器证书。
- 以 PEM 格式提供 X.509 证书。
- 为每个监听程序指定正确的 Subject Alternative Names (SAN)。更多信息请参阅 第 10.7.2 节 “Kafka 监听器的服务器证书中的替代主题”。
- 您可以在证书文件中提供包含整个 CA 链的证书。
流程
创建包含私钥和服务器证书的
Secret
:oc create secret generic my-secret --from-file=my-listener-key.key --from-file=my-listener-certificate.crt
编辑集群的
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 # ...
应用新配置以创建或更新资源:
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 加密的外部监听程序,您需要在证书中指定的主机名取决于外部监听程序 类型
。
外部监听程序类型 | 在 SANs 中,指定… |
---|---|
|
所有 Kafka 您可以使用匹配的通配符名称。 |
|
所有 Kafka 代理 您可以使用匹配的通配符名称。 |
| 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
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
属性,如下表中所述。
AMQ Streams 资源 | 架构参考 | 发布状态信息 on… |
---|---|---|
| Kafka 集群。 | |
| Kafka Connect 集群(如果部署)。 | |
| KafkaConnector 资源(如果部署)。 | |
| Kafka MirrorMaker 工具(如果部署)。 | |
| Kafka 集群中的 Kafka 主题。 | |
| Kafka 集群中的 Kafka 用户。 | |
| 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 # ...
状态中列出的 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.listeners
或status.observedGeneration
)来微调您要查看的状态信息。
其他资源
- 第 11.1.2 节 “AMQ Streams 自定义资源状态信息”
- 有关使用 JSONPath 的更多信息,请参阅 JSONPath 支持。
11.2. 暂停对自定义资源的协调
有时,暂停由 AMQ Streams Operator 管理的自定义资源协调很有用,以便您可以执行修复或进行更新。如果协调暂停,Operator 将忽略对自定义资源所做的任何更改,直到暂停结束为止。
如果要暂停自定义资源的协调,请在其配置中将 strimzi.io/pause-
reconation 注解设置为 true
。这会指示适当的 Operator 暂停自定义资源协调。例如,您可以将注解应用到 KafkaConnect
资源,以便 Cluster Operator 协调暂停。
您还可以创建启用 pause 注解的自定义资源。创建自定义资源,但会忽略它。
先决条件
- 管理自定义资源的 AMQ Streams Operator 正在运行。
流程
在 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"
检查自定义资源的状态条件是否显示 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。
流程
使用
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 添加相同的配置。
更新
Kafka
资源:oc apply -f <kafka_configuration_file>
部署 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 根据注解执行滚动更新。
先决条件
流程
排空托管 Kafka 代理或 ZooKeeper pod 的指定 OpenShift 节点。
oc get nodes oc drain <name-of-node> --delete-emptydir-data --ignore-daemonsets --timeout=6000s --force
检查 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
检查 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 的资源中添加注解。您注解 StatefulSet
或 StrimziPodSet
资源(如果您启用了 UseStrimziPodSets 功能门)。
流程
查找控制您要手动更新的 Kafka 或 ZooKeeper pod 的资源名称。
例如,如果您的 Kafka 集群名为 my-cluster,则对应的名称为 my-cluster-kafka 和 my-cluster-zookeeper。
使用
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
- 等待下一次协调发生(默认为两分钟)。只要协调过程检测到注解,就会触发对注解中所有 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 # ...
流程
查找您要手动更新的 Kafka 或 ZooKeeper
Pod
的名称。例如,如果您的 Kafka 集群名为 my-cluster,则对应的
Pod
名称是 my-cluster-kafka-index 和 my-cluster-zookeeper-index。索引 从零开始,结尾为副本数减一。注解 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
-
等待下一次协调发生(默认为两分钟)。当在协调过程检测到注解时,就会触发被注解的
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
资源不存在。
当您获得重新创建集群的步骤时,有两个选项:
当您可以恢复所有
KafkaTopic
资源时,请使用 选项 1。因此,在集群启动前必须恢复
KafkaTopic
资源,以便 Topic Operator 不会删除对应的主题。当无法恢复所有
KafkaTopic
资源时,请使用 选项 2。在这种情况下,您在没有 Topic Operator 的情况下部署集群,删除 Topic Operator 主题存储元数据,然后使用 Topic Operator 重新部署 Kafka 集群,以便可以从对应的主题重新创建
KafkaTopic
资源。
如果没有部署 Topic Operator,则只需要恢复 PersistentVolumeClaim
(PVC)资源。
开始前
在这一流程中,PV 挂载到正确的 PVC 中,以避免数据崩溃。为 PVC 指定一个 volumeName
,它必须与 PV 的名称匹配。
如需更多信息,请参阅:
此流程不包括 KafkaUser
资源的恢复,必须手动重新创建。如果需要保留密码和证书,在创建 KafkaUser
资源前必须重新创建 secret。
流程
检查集群中 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 的链接。
重新创建原始命名空间:
oc create namespace myproject
重新创建原始 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
编辑 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
部署 Cluster Operator。
oc create -f install/cluster-operator -n my-project
重新创建集群。
根据您是否有足够的
KafkaTopic
资源来重新创建集群,请按照以下步骤操作。选项 1: 如果您拥有丢失集群之前存在的 所有
KafkaTopic
资源,包括内部主题,如从__consumer_offsets
的提交偏移:重新创建所有
KafkaTopic
资源。在部署集群前重新创建资源非常重要,否则主题 Operator 将删除主题。
部署 Kafka 集群。
例如:
oc apply -f kafka.yaml
选项 2: 如果您没有丢失集群前存在的所有
KafkaTopic
资源:与使用第一个选项一样部署 Kafka 集群,但部署前从 Kafka 资源中删除
topicOperator
属性。如果在部署中包含 Topic Operator,主题 Operator 将删除所有主题。
从 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 集群的监听程序和身份验证类型对应。
使用
topicOperator
属性重新部署 Kafka 集群以重新创建KafkaTopic
资源来启用主题 Operator。例如:
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: my-cluster spec: #... entityOperator: topicOperator: {} 1 #...
- 1
- 此处我们显示了默认配置,该配置没有额外属性。您可以使用 第 12.2.45 节 “
EntityTopicOperatorSpec
模式参考” 中描述的属性指定所需的配置。
列出
KafkaTopic
资源来验证恢复:oc get KafkaTopic
11.7. 使用 Kafka 静态配额插件在代理上设置限制
使用 Kafka 静态配额插件在 Kafka 集群中的代理上设置吞吐量和存储限制。您可以通过配置 Kafka
资源来启用插件和设置限制。您可以设置字节阈值和存储配额,以在与代理交互的客户端上放置限制。
您可以为制作者和消费者带宽设置字节速率阈值。总限值分布在访问代理的所有客户端上。例如,您可以为制作者设置字节的阈值 40 MBps。如果两个制作者正在运行,则它们各自限制为 20 MBps 吞吐量。
存储配额在软限制和硬限制之间节流 Kafka 磁盘存储限制。限制适用于所有可用磁盘空间。生产者在软限制和硬限制之间逐渐下降。限制可防止磁盘填满速度超过其容量。完整磁盘可能会导致难以修复的问题。硬限制是最大存储限制。
对于 JBOD 存储,限制适用于所有磁盘。如果代理使用两个 1 TB 磁盘,且配额是 1.1 TB,一个磁盘可能会填满,而其他磁盘几乎为空。
先决条件
- 管理 Kafka 集群的 Cluster Operator 正在运行。
流程
为
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
更新资源。
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 # ...
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. 资源
配置 资源的 requests 和 limits,以控制 AMQ Streams 容器的资源。您可以为 memory
和 cpu
资源指定 requests 和 limits。请求应该足以确保 Kafka 的稳定性能。
如何在生产环境中配置资源取决于多个因素。例如,应用可能会在 OpenShift 集群中共享资源。
对于 Kafka,部署的以下方面可能会影响您需要的资源:
- 消息吞吐量和大小
- 处理消息的网络线程数量
- 制作者和消费者的数量
- 主题和分区的数量
为资源请求指定的值会被保留,并始终可供容器使用。资源限值指定给定容器可以消耗的最大资源。请求和限制之间的数量不是保留的,可能并不总是可用。容器仅可在有限制时才使用最多的资源。资源限值是临时的,可重新分配。
资源请求和限值
如果您在没有请求或反之设置限值,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 请求和限制指定为 cores 或 millicpus/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 版本及其对应镜像之间的映射。映射与 镜像和
版本
属性一起使用:
-
如果自定义资源中未给出
image
和version
,则版本
将默认为 Cluster Operator 的默认 Kafka 版本,且镜像将是环境变量中与此版本对应的镜像。 -
如果给定
镜像
但不提供版本
,则使用给定镜像,并且假定
版本为 Cluster Operator 的默认 Kafka 版本。 -
如果给出了
版本
,但镜像
不是,则使用环境变量中与给定版本对应的镜像。 -
如果同时指定了
version
和镜像
,则使用给定的镜像。镜像假定为包含带有给定版本的 Kafka 镜像。
不同组件 的镜像和
版本
可在以下属性中配置:
-
对于
spec.kafka.image
和spec.kafka.version
中的 Kafka。 -
对于
spec.image
和spec.version
中的 Kafka Connect 和 Kafka MirrorMaker。
建议您仅提供 版本
,并将 image
属性保留为未指定状态。这可减少配置自定义资源时出错的机会。如果您需要更改用于不同版本的 Kafka 的镜像,最好配置 Cluster Operator 的环境变量。
在其他资源中配置 image
属性
对于其他自定义资源中的 image
属性,在部署期间将使用给定值。如果缺少 image
属性,则会使用 Cluster Operator 配置中指定 的镜像
。如果 Cluster Operator 配置中没有定义镜像
名称,则使用默认值。
对于主题 Operator:
-
在
STRIMZI_DEFAULT_TOPIC_OPERATOR_IMAGE
环境变量中指定的容器镜像。 -
registry.redhat.io/amq7/amq-streams-rhel8-operator:2.2.2
容器镜像。
-
在
对于 User Operator:
-
在
STRIMZI_DEFAULT_USER_OPERATOR_IMAGE
环境变量中指定的容器镜像。 -
registry.redhat.io/amq7/amq-streams-rhel8-operator:2.2.2
容器镜像。
-
在
对于实体 Operator TLS sidecar:
-
在
STRIMZI_DEFAULT_TLS_SIDECAR_ENTITY_OPERATOR_IMAGE
环境变量中指定的容器镜像。 -
registry.redhat.io/amq7/amq-streams-kafka-32-rhel8:2.2.2
容器镜像。
-
在
对于 Kafka 导出器:
-
在 Cluster Operator 配置中的
STRIMZI_DEFAULT_KAFKA_EXPORTER_IMAGE
环境变量中指定的容器镜像。 -
registry.redhat.io/amq7/amq-streams-kafka-32-rhel8:2.2.2
容器镜像。
-
在 Cluster Operator 配置中的
对于 Kafka Bridge:
-
在 Cluster Operator 配置中的
STRIMZI_DEFAULT_KAFKA_BRIDGE_IMAGE
环境变量中指定的容器镜像。 -
registry.redhat.io/amq7/amq-streams-bridge-rhel8:2.2.2
容器镜像。
-
在 Cluster Operator 配置中的
对于 Kafka 代理初始化器:
-
在 Cluster Operator 配置中的
STRIMZI_DEFAULT_KAFKA_INIT_IMAGE
环境变量中指定的容器镜像。 -
registry.redhat.io/amq7/amq-streams-rhel8-operator:2.2.2
容器镜像。
-
在 Cluster Operator 配置中的
容器镜像配置示例
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: my-cluster spec: kafka: # ... image: my-org/my-image:latest # ... zookeeper: # ...
12.1.7. livenessProbe
和 readinessProbe
状况检查
使用 livenessProbe
和 readinessProbe
属性配置 AMQ Streams 中支持的健康检查探测。
状况检查是定期测试,验证应用程序的健康状态。当 Healthcheck 探测失败时,OpenShift 会假定应用处于健康状态,并尝试修复它。
有关探测的详情,请参阅 配置存活度和就绪度探测。
livenessProbe
和 readinessProbe
支持以下选项:
-
initialDelaySeconds
-
timeoutSeconds
-
periodSeconds
-
successThreshold
-
failureThreshold
存活度和就绪度探测配置示例
# ... readinessProbe: initialDelaySeconds: 15 timeoutSeconds: 5 livenessProbe: initialDelaySeconds: 15 timeoutSeconds: 5 # ...
有关 livenessProbe
和 readinessProbe
选项的更多信息,请参阅 探测模式参考。
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
二进制文件接受的单元相同。因此,1g
或 1G
表示 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 根据内存资源配置百分比设置默认的最大值和最小堆值。
下表显示了默认的堆值。
组件 | 分配给堆的可用内存百分比 | 最大限制 |
---|---|---|
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。 |
status | Kafka 和 ZooKeeper 集群的状态,以及主题 Operator。 |
12.2.2. KafkaSpec
模式参考
使用的: Kafka
属性 | Description |
---|---|
kafka | Kafka 集群配置。 |
zookeeper | ZooKeeper 集群的配置。 |
entityOperator | 配置实体 Operator。 |
clusterCa | 集群证书颁发机构配置。 |
clientsCa | 配置客户端证书颁发机构。 |
cruiseControl | 配置控制部署。在指定时部署 Cruise Control 实例。 |
kafkaExporter | Kafka 导出器配置。Kafka Exporter 可以提供额外的指标,例如主题/分区中的使用者组。 |
maintenanceTimeWindows | 维护任务的时间窗口列表(即证书续订)。每次时间窗都由 cron 表达式定义。 |
字符串数组 |
12.2.3. KafkaClusterSpec
模式参考
使用的: KafkaSpec
配置 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
字段时,会按优先级顺序使用以下镜像:
-
在 Cluster Operator 配置中的
STRIMZI_DEFAULT_KAFKA_INIT_IMAGE
环境变量中指定的容器镜像。 -
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.name
和 logging.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 代理的监听程序。 |
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 |
存储配置(磁盘)。无法更新。这个类型取决于给定对象中的 |
授权 |
Kafka 代理的授权配置。类型取决于给定对象中的 |
| |
rack |
配置 |
brokerRackInitImage |
用于初始化 |
字符串 | |
livenessProbe | Pod 存活度检查。 |
readinessProbe | Pod 就绪度检查. |
jvmOptions | pod 的 JVM 选项。 |
jmxOptions | Kafka 代理的 JMX 选项。 |
资源 | 要保留的 CPU 和内存资源。如需更多信息,请参阅 core/v1 资源查询的外部文档。 |
metricsConfig |
指标配置。这个类型取决于给定对象中的 |
logging |
Kafka 的日志记录配置。类型取决于给定对象中的 |
模板 |
Kafka 集群资源的模板。通过该模板,用户可以指定如何生成 |
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
这个类型设置为 内部
,或将外部监听器设置为 路由
、loadbalancer
、nodeport
或 ingress
。
- 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
Ingress
和 NGINX Ingress Controller 来公开 Kafka。为每个 Kafka 代理 pod 创建专用的
Ingress
资源。创建额外的Ingress
资源,以用作 Kafka bootstrap 地址。Kafka 客户端可以使用这些Ingress
资源连接到端口 443 上的 Kafka。客户端通过端口 443 连接默认的控制器端口,但流量会被路由到您配置的端口,本例中为9095
。您必须使用
GenericKafkaListenerConfigurationBootstrap
和GenericKafkaListenerConfigurationBroker
属性指定 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-consumer
和app: kafka-sasl-producer
匹配的应用程序 pod 可以连接到普通
的监听程序。应用程序 pod 必须与 Kafka 代理在同一命名空间中运行。 -
只有在与标签
project: myproject
andproject: 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 |
侦听器的类型。目前,支持的类型有
|
字符串(一个 [ingress, internal, route, loadbalancer, nodeport]) | |
tls | 在监听器上启用 TLS 加密。这是必需的属性。 |
布尔值 | |
身份验证 |
此侦听器的身份验证配置。这个类型取决于给定对象中的 |
| |
配置 | 其他侦听器配置。 |
networkPolicyPeers | 应连接到此侦听器的对等点列表。使用逻辑 OR 操作组合此列表中的对等点。如果此字段为空或缺失,则此监听器将允许所有连接。如果此字段存在且至少包含一个项目,则监听程序只允许与此列表中至少匹配一个项目的流量。如需更多信息,请参阅 networking.k8s.io/v1 networkpolicypeer 的外部文档。 |
12.2.5. KafkaListenerAuthenticationTls
模式参考
使用的: GenericKafkaListener
type
属性是一种差异性,用于区分来自 KafkaListenerAuthenticationScramSha512
的 KafkaListenerAuthenticationTls
类型、KafkaListenerAuthenticationOAuth
、KafkaListenerAuthenticationCustom
。它必须具有类型为 KafkaListenerAuthenticationTls
的值 tls
。
属性 | Description |
---|---|
type |
必须为 |
字符串 |
12.2.6. KafkaListenerAuthenticationScramSha512
模式参考
使用的: GenericKafkaListener
type
属性是一种差异性,用于区分来自 KafkaListenerAuthenticationTls
, KafkaListenerAuthenticationOAuth
, KafkaListenerAuthenticationCustom
的 KafkaListenerAuthenticationScramSha512
类型。对于类型 KafkaListenerAuthenticationScramSha512
,它需要值 scram-sha-512
。
属性 | Description |
---|---|
type |
必须为 |
字符串 |
12.2.7. KafkaListenerAuthenticationOAuth
模式参考
使用的: GenericKafkaListener
type
属性是一种差异性,用于区分 KafkaListenerAuthentication OAuth
类型来自 KafkaListenerAuthenticationTls
、KafkaListenerAuthenticationScramSha512
、KafkaListenerAuthenticationCustom
。对于类型 KafkaListenerAuthenticationOAuth
,它需要带有值 oauth
。
属性 | Description |
---|---|
accessTokenIsJwt |
配置访问令牌是否被视为 JWT。如果授权服务器返回不透明令牌,则必须将其设置为 |
布尔值 | |
checkAccessTokenType |
配置访问令牌类型检查是否执行。如果授权服务器在 JWT 令牌中不包含 'typ' 声明,则此项应设为 |
布尔值 | |
checkAudience |
启用或禁用受众检查。受众检查确定令牌的接收者。如果启用了受众检查,还必须使用 |
布尔值 | |
checkIssuer |
启用或禁用签发者检查。默认情况下,使用由 |
布尔值 | |
clientAudience |
在向授权服务器的令牌端点发出请求时使用的对象。用于交集身份验证并使用 |
字符串 | |
clientId | Kafka 代理可以用来对授权服务器进行身份验证的 OAuth 客户端 ID,并使用 introspect 端点 URI。 |
字符串 | |
clientScope |
向授权服务器的令牌端点发出请求时使用的范围。用于交集身份验证并使用 |
字符串 | |
clientSecret | 链接到包含 Kafka 代理可以用来进行授权服务器进行身份验证的 OAuth 客户端 secret 的 OpenShift Secret,并使用 introspect 端点 URI。 |
connectTimeoutSeconds | 连接授权服务器时出现连接超时(以秒为单位)。如果没有设置,则有效连接超时为 60 秒。 |
整数 | |
customClaimCheck | JSONPath 过滤器查询以应用到 JWT 令牌,或对内省端点的响应进行额外的令牌验证。默认情况下不设置。 |
字符串 | |
disableTlsHostnameVerification |
启用或禁用 TLS 主机名验证。默认值为 |
布尔值 | |
enableECDSA |
|
布尔值 | |
enableOauthBearer |
启用或禁用 SASL_OAUTHBEARER 的 OAuth 身份验证。默认值为 |
布尔值 | |
enablePlain |
启用或禁用 SASL_PLAIN 的 OAuth 身份验证。使用这种机制时,不支持重新身份验证。默认值为 |
布尔值 | |
fallbackUserNameClaim |
如果不存在 |
字符串 | |
fallbackUserNamePrefix |
要用于 |
字符串 | |
groupsClaim | JSONPath 查询,用于在身份验证过程中提取用户的组。提取的组可被自定义授权者使用。默认情况下不提取任何组。 |
字符串 | |
groupsClaimDelimiter | 用于在将组提取为单个 String 值而不是 JSON 数组的分隔符。默认值为 ','(comma)。 |
字符串 | |
introspectionEndpointUri | 令牌内省端点的 URI,可用于验证不透明的非JWT 令牌。 |
字符串 | |
jwksEndpointUri | JWKS 证书端点的 URI,可用于本地 JWT 验证。 |
字符串 | |
jwksExpirySeconds |
配置 JWKS 证书被视为有效的频率。到期间隔必须至少为 60 秒,然后在 |
整数 | |
jwksMinRefreshPauseSeconds | 连续两次刷新之间的最短暂停。遇到未知签名密钥时,立即调度刷新,但会始终等待这个最小暂停。默认为 1 秒。 |
整数 | |
jwksRefreshSeconds |
配置 JWKS 证书刷新的频率。刷新间隔必须至少为 60 秒,然后是 |
整数 | |
maxSecondsWithoutReauthentication |
经过身份验证的会话在无需再身份验证的情况下保持有效的最多秒数。这可让 Apache Kafka 重新验证功能,并在访问令牌过期时导致会话过期。如果访问令牌在最大时间或达到最大时间前过期,客户端必须重新验证,否则服务器将丢弃连接。默认不设置 - 经过身份验证的用户会话会在访问令牌过期时过期。这个选项只适用于 SASL_OAUTHBEARER 身份验证机制(在 |
整数 | |
readTimeoutSeconds | 连接到授权服务器时读取超时(以秒为单位)。如果没有设置,则有效读取超时为 60 秒。 |
整数 | |
tlsTrustedCertificates | TLS 与 OAuth 服务器连接的可信证书。 |
tokenEndpointUri |
客户端通过 |
字符串 | |
type |
必须是 |
字符串 | |
userInfoEndpointUri | 当 Introspection Endpoint 没有返回可以用于用户 ID 的信息时,User Info Endpoint 的 URI 用作回退来获取用户 ID。 |
字符串 | |
userNameClaim |
JWT 身份验证令牌声明的名称、Introspection Endpoint 响应或 User Info Endpoint 响应,用于提取用户 ID。默认为 |
字符串 | |
validIssuerUri | 用于身份验证的令牌签发者的 URI。 |
字符串 | |
validTokenType |
Introspection Endpoint 返回的 |
字符串 |
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
生成协议映射,它使用 sasl
和 tls
值来确定要映射到监听程序的协议。
- 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> .sasl.enabled.mechanisms
.
12.2.10.2. secrets
secret 挂载到 /opt/kafka/custom-authn-secrets/custom-listener- <listener_name>-<port> / <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
类型来自 KafkaListenerAuthenticationTls
、KafkaListenerAuthenticationScramSha512
、KafkaListenerAuthenticationOAuth
。它必须 自定义
类型为 KafkaListenerAuthenticationCustom
。
属性 | Description |
---|---|
listenerConfig | 用于特定侦听器的配置。所有值的前缀为 listener.name。<listener_name>。 |
map | |
SASL | 在此侦听器上启用或禁用 SASL。 |
布尔值 | |
secrets | 要挂载到 /opt/kafka/custom-authn-secrets/custom-listener- <listener_name>-<port> / <secret_name > 的 secret。 |
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
属性用于 loadbalancer
和 nodeport
侦听程序。在 OpenShift 外部公开 Kafka 时,您可以选择 Local
或 Cluster
。本地
避免了对其他节点的跃点,并保留客户端 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
类
。
使用 Ingress
类 nginx-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 以标准优先级顺序进行操作:
- ExternalDNS
- ExternalIP
- Hostname
- InternalDNS
- 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 |
引用存放用于此侦听器的证书和私钥对的 |
externalTrafficPolicy |
指定服务是否将外部流量路由到节点本地或集群范围端点。 |
字符串([本地、Cluster] 之一) | |
loadBalancerSourceRanges |
CIDR 范围列表(例如 |
字符串数组 | |
bootstrap | Bootstrap 配置。 |
代理(broker) | 按代理配置. |
ipFamilyPolicy |
指定服务使用的 IP 系列策略。可用选项包括 |
字符串(一个 [RequireDualStack,SingleStack,PreferDualStack]) | |
ipFamilies |
指定服务使用的 IP Families。可用的选项有 |
字符串(一个或多个 [IPv6, IPv4])数组 | |
createBootstrapService |
是否要创建 bootstrap 服务。默认情况下创建 bootstrap 服务(如果未指定),则默认创建。此字段可用于 |
布尔值 | |
类 |
配置定义将要使用的 |
字符串 | |
终结器 |
为为这个监听器创建的 |
字符串数组 | |
maxConnectionCreationRate | 在任何时候,我们在此侦听器中允许的最大连接创建率。如果达到限制,则会减慢新连接。 |
整数 | |
maxConnections | 您可以随时在代理中允许此监听程序的最大连接数。如果达到限制,新连接会被阻止。 |
整数 | |
preferredNodePortAddressType |
定义应将哪个地址类型用作节点地址。可用类型有:
此字段用于选择首选地址类型,首先检查该类型。如果没有找到这个地址类型的地址,则按默认顺序检查其他类型。此字段只能与 |
字符串(一个 [ExternalDNS, ExternalIP, Hostname, InternalIP, InternalDNS]) | |
useServiceDnsDomain |
配置是否应使用 OpenShift 服务 DNS 域。如果设置为 |
布尔值 |
12.2.12. CertAndKeySecretSource
模式参考
使用的: GenericKafkaListenerConfiguration
、KafkaClientAuthenticationTls
属性 | Description |
---|---|
certificate | Secret 中文件证书的名称。 |
字符串 | |
key | Secret 中私钥的名称。 |
字符串 | |
secretName | 包含证书的 Secret 的名称。 |
字符串 |
12.2.13. GenericKafkaListenerConfigurationBootstrap
模式参考
使用的: GenericKafkaListenerConfiguration
GenericKafkaListenerConfigurationBootstrap
schema 属性的完整列表
与 nodePort
, host
, loadBalancerIP
和 annotations
属性相应的代理服务在 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
属性用于 route
和 ingress
监听程序,以指定 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 资源中使用,以指定所需主机名。此字段只能用于 |
字符串 | |
nodePort |
bootstrap 服务的节点端口。此字段只能与 |
整数 | |
loadBalancerIP |
负载均衡器请求使用此字段中指定的 IP 地址。此功能取决于创建负载均衡器时是否支持指定 |
字符串 | |
annotations |
将添加到 |
map | |
labels |
将添加到 |
map |
12.2.14. GenericKafkaListenerConfigurationBroker
模式参考
使用的: GenericKafkaListenerConfiguration
GenericKafkaListenerConfigurationBroker
schema 属性的完整列表
您可以在 GenericKafkaListenerConfigurationBootstrap
模式 中看到 nodePort
、host
、loadBalancerIP
和 annotations
属性配置示例,以配置 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 |
代理的 |
字符串 | |
advertisedPort |
代理的 |
整数 | |
主机 |
代理主机。此字段将在 Ingress 资源或 Route 资源中使用,以指定所需主机名。此字段只能用于 |
字符串 | |
nodePort |
每个broker 服务的节点端口。此字段只能与 |
整数 | |
loadBalancerIP |
负载均衡器请求使用此字段中指定的 IP 地址。此功能取决于创建负载均衡器时是否支持指定 |
字符串 | |
annotations |
将添加到 |
map | |
labels |
将添加到 |
map |
12.2.15. EphemeralStorage
schema 参考
使用的: JbodStorage
, KafkaClusterSpec
, ZookeeperClusterSpec
type
属性是一种分ator,用于区分使用 PersistentClaimStorage
的 EphemeralStorage
类型。它必须具有类型为 EphemeralStorage
的值 临时
的值。
属性 | Description |
---|---|
id | 存储识别号.这只适用于在存储类型 'jbod' 中定义的存储卷。 |
整数 | |
sizeLimit | 当 type=ephemeral 时,定义这个 EmptyDir 卷所需的本地存储总量(例如 1Gi)。 |
字符串 | |
type |
必须 |
字符串 |
12.2.16. PersistentClaimStorage
schema 参考
使用的: JbodStorage
, KafkaClusterSpec
, ZookeeperClusterSpec
type
属性是一个差异性,用于区分使用来自 EphemeralStorage
的 PersistentClaimStorage
类型。它必须具有类型为 PersistentClaimStorage
的 persistent-claim
值。
属性 | Description |
---|---|
type |
必须为 |
字符串 | |
size | 当 type=persistent-claim 时,定义持久性卷声明的大小(例如 1Gi)。type=persistent-claim 时必需。 |
字符串 | |
selector | 指定要使用的特定持久性卷。它包含代表选择此类卷的标签的 key:value 对。 |
map | |
deleteClaim | 指定在集群没有部署时是否必须删除持久性卷声明。 |
布尔值 | |
类 | 用于动态卷分配的存储类。 |
字符串 | |
id | 存储识别号.这只适用于在存储类型 'jbod' 中定义的存储卷。 |
整数 | |
overrides |
覆盖单个代理。 |
12.2.17. PersistentClaimStorageOverride
模式参考
属性 | Description |
---|---|
类 | 用于这个代理的动态卷分配的存储类。 |
字符串 | |
broker | kafka 代理(broker 标识符)的 ID。 |
整数 |
12.2.18. JbodStorage
schema 参考
使用的: KafkaClusterSpec
type
属性是一种分ator,用于区分 JbodStorage
类型与 EphemeralStorage
( PersistentClaimStorage
)。它必须具有类型 JbodStorage
的值 jbod
。
属性 | Description |
---|---|
type |
必须为 |
字符串 | |
卷 | 卷列表作为代表 JBOD 存储阵列的 Storage 对象。 |
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 |
必须为 |
字符串 | |
url | 用于连接到 Open Policy Agent 服务器的 URL。URL 必须包括由授权器查询的策略。这个选项是必需的。 |
字符串 | |
allowOnError |
定义当授权器无法查询 Open Policy Agent 时(例如,临时不可用)应允许或拒绝 Kafka 客户端。默认值为 |
布尔值 | |
initialCacheCapacity |
授权者使用的本地缓存的初始容量,以避免为每个请求默认查询 Open Policy Agent 变为 |
整数 | |
maximumCacheSize |
授权者使用的本地缓存的最大容量以避免为每个请求查询 Open Policy Agent。默认为 |
整数 | |
expireAfterMs |
记录的过期时间保存在本地缓存中,以避免为每个请求查询 Open Policy Agent。定义从 Open Policy Agent 服务器重新加载缓存的授权决策的频率。以毫秒为单位。默认为 |
整数 | |
superUsers | 超级用户列表,特别是具有无限访问权限的用户主体列表。 |
字符串数组 | |
enableMetrics |
定义 Open Policy Agent 授权器插件是否应提供指标。默认值为 |
布尔值 |
12.2.21. KafkaAuthorizationKeycloak
模式参考
使用的: KafkaClusterSpec
type
属性是一种差异性,用于区分在 KafkaAuthorizationKeycloak
类型中的 KafkaAuthorizationSimple
, KafkaAuthorizationOpa
, KafkaAuthorizationCustom
。对于类型 KafkaAuthorizationKeycloak
,它需要有值 keycloak
。
属性 | Description |
---|---|
type |
必须是 |
字符串 | |
clientId | Kafka 客户端可以用来向 OAuth 服务器进行身份验证并使用令牌端点 URI 的 OAuth 客户端 ID。 |
字符串 | |
tokenEndpointUri | 授权服务器令牌端点 URI。 |
字符串 | |
tlsTrustedCertificates | TLS 与 OAuth 服务器连接的可信证书。 |
disableTlsHostnameVerification |
启用或禁用 TLS 主机名验证。默认值为 |
布尔值 | |
delegateToKafkaAcls |
如果红帽单点登录授权服务策略 DENIED,是否应该授权决定为 'Simple' 授权程序。默认值为 |
布尔值 | |
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
属性是一种差异性,用于区分在 KafkaAuthorizationSimple
、KafkaAuthorizationOpa
、KafkaAuthorizationKeycloak
中使用 KafkaAuthorizationKeycloak 的 KafkaAuthorizationCustom
类型。它必须 自定义
类型为 KafkaAuthorizationCustom
的值。
属性 | Description |
---|---|
type |
必须为 |
字符串 | |
authorizerClass | 授权实施类必须在 classpath 中提供。 |
字符串 | |
superUsers | 超级用户列表,它们是具有无限访问权限的用户主体。 |
字符串数组 | |
supportsAdminApi |
指明自定义授权器是否支持使用 Kafka Admin API 管理 ACL。默认值为 |
布尔值 |
12.2.23. 机架
架构参考
使用的: KafkaClusterSpec
, KafkaConnectSpec
, KafkaMirrorMaker2Spec
机架
选项配置机架意识。机架 可以代表一个可用性区域、数据中心或数据中心中的实际机架。机架 通过 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
选项应该指定运行使用者的 机架 ID。RackAwareReplicaSelector
关联匹配的 broker.rack
和 client.rack
ID,以查找最接近的副本并使用它。如果同一机架中有多个副本,RackAwareReplicaSelector
始终选择最新的副本。如果没有指定机架 ID,或者找不到具有相同机架 ID 的副本,它将回退到领导副本。
图 12.1. 显示在同一可用区中消耗的副本的客户端示例

您还可以配置 Kafka Connect 和 MirrorMaker 2.0,以便连接器使用最接近的副本的消息。您可在 KafkaConnect
和 KafkaMirrorMaker2
自定义资源中启用机架意识。该配置不设置关联性规则,但您也可以配置 关联性
或 拓扑
规则。更多信息请参阅 第 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 集群节点的标签匹配的键。标签的值用于设置代理的 |
字符串 |
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 |
使用 |
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 端口的身份验证配置。类型取决于给定对象中的 |
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 |
必须为 |
字符串 | |
valueFrom | 存储 Prometheus JMX Exporter 配置的 ConfigMap 条目。有关此配置结构的详情,请查看 Prometheus JMX Exporter。 |
12.2.30. ExternalConfigurationReference
模式参考
使用的: ExternalLogging
、JmxPrometheusExporterMetrics
属性 | Description |
---|---|
configMapKeyRef | 对包含配置的 ConfigMap 中的键引用。如需更多信息,请参阅 core/v1 configmapkeyselector 的外部文档。 |
12.2.31. InlineLogging
模式参考
使用的: CruiseControlSpec
, EntityTopicOperatorSpec
, EntityUserOperatorSpec
, KafkaBridgeSpec
, KafkaConnectSpec
, KafkaConnectSpec
, KafkaMirrorMaker2Spec
, KafkaMirrorMakerSpec
, ZookeeperClusterSpec
type
属性是一种分辨符,用于区分来自 ExternalLogging
的 InlineLogging
类型。它必须具有类型为 InlineLogging
的值 内联
值。
属性 | Description |
---|---|
type |
必须是 |
字符串 | |
日志记录器 | 从日志记录器名称到日志记录器级别的映射。 |
map |
12.2.32. ExternalLogging
模式参考
使用的: CruiseControlSpec
, EntityTopicOperatorSpec
, EntityUserOperatorSpec
, KafkaBridgeSpec
, KafkaConnectSpec
, KafkaConnectSpec
, KafkaMirrorMaker2Spec
, KafkaMirrorMakerSpec
, ZookeeperClusterSpec
type
属性是一种分辨符,用于区分来自 InlineLogging
的 ExternalLogging
类型。对于类型 ExternalLogging
,它需要的值是 external
。
属性 | Description |
---|---|
type |
必须是 |
字符串 | |
valueFrom |
存储日志记录配置的 |
12.2.33. KafkaClusterTemplate
模式参考
使用的: KafkaClusterSpec
属性 | Description |
---|---|
statefulset |
Kafka |
Pod |
Kafka |
bootstrapService |
Kafka bootstrap |
brokersService |
Kafka 代理服务 |
externalBootstrapService |
Kafka 外部 bootstrap |
perPodService |
用于 OpenShift 外部的 Kafka 每个 pod |
externalBootstrapRoute |
Kafka 外部 bootstrap |
perPodRoute |
用于从 OpenShift 外部访问的 Kafka 每个 pod |
externalBootstrapIngress |
Kafka 外部 bootstrap |
perPodIngress |
用于从 OpenShift 外部访问的 Kafka 每个 pod |
persistentVolumeClaim |
所有 Kafka |
podDisruptionBudget |
Kafka |
kafkaContainer | Kafka 代理容器的模板。 |
initContainer | Kafka init 容器的模板。 |
clusterCaCert | 带有 Kafka 集群证书公钥的 Secret 模板。 |
serviceAccount | Kafka 服务帐户的模板。 |
jmxSecret | Kafka 集群 JMX 身份验证的 Secret 模板。 |
clusterRoleBinding | Kafka ClusterRoleBinding 的模板。 |
podSet |
Kafka |
12.2.34. StatefulSetTemplate
模式参考
使用的: KafkaClusterTemplate
, ZookeeperClusterTemplate
属性 | Description |
---|---|
metadata | 应用到资源的元数据。 |
podManagementPolicy |
PodManagementPolicy,用于此 StatefulSet。有效值为 |
string (one of [OrderedReady, Parallel]) |
12.2.35. MetadataTemplate
模式参考
使用的: BuildConfigTemplate
、DeploymentTemplate
、InternalServiceTemplate
、PodDisruptionBudgetTemplate
、PodTemplate
、ResourceTemplate
、StatefulTemplate、StatefulTemplate
Labels
和 Annotations
用于识别和组织资源,并在 metadata
属性中配置。
例如:
# ... template: pod: metadata: labels: label1: value1 label2: value2 annotations: annotation1: value1 annotation2: value2 # ...
labels
和 annotations
字段可以包含没有保留字符串 strimzi.io
的任何标签或注解。包含 strimzi.io
的标签和注解由 AMQ Streams 内部使用,且无法配置。
12.2.35.1. 元数据模板
架构属性
属性 | Description |
---|---|
labels |
添加到资源模板的标签。可以应用到不同的资源,如 |
map | |
annotations |
添加到资源模板中的注解。可以应用到不同的资源,如 |
map |
12.2.36. PodTemplate
模式参考
用于:CruiseControlTemplate
, EntityOperatorTemplate
, KafkaBridgeTemplate
, KafkaClusterTemplate
, KafkaConnectTemplate
, KafkaExporterTemplate
, KafkaMirrorMakerTemplate
, ZookeeperClusterTemplate
配置 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 | 应用到资源的元数据。 |
imagePullSecrets |
对同一命名空间中的 secret 的引用列表,用于拉取此 Pod 使用的任何镜像。当指定 Cluster Operator 中的 |
securityContext | 配置 pod 级别的安全属性和通用容器设置。如需更多信息,请参阅 core/v1 podsecuritycontext 的外部文档。 |
terminationGracePeriodSeconds | 宽限期是 Pod 中运行的进程发送终止信号后的持续时间(以秒为单位),以及进程被强制停止的时间(使用 kill 信号)。将这个值设置为比您的进程预期的清理时间长。值必须是非负的整数。零值表示立即删除。您可能需要为非常大的 Kafka 集群增加宽限期,以便 Kafka 代理有足够的时间将其工作传输至另一个代理,然后再被终止。默认为 30 秒。 |
整数 | |
关联性 | pod 的关联性规则。如需更多信息,请参阅 core/v1 关联性的外部文档。 |
容限(tolerations) | pod 的容限。如需更多信息,请参阅 core/v1 容限的外部文档。 |
容限 数组 | |
priorityClassName | 用于为 pod 分配优先级的优先级类的名称。有关优先级类的更多信息,请参阅 Pod 优先级和抢占。 |
字符串 | |
schedulerName |
用于分配此 |
字符串 | |
hostAliases | pod 的 HostAliases。hostAliases 是主机和 IP 的可选列表,在指定时将注入到 Pod 的主机文件中。如需更多信息,请参阅 core/v1 hostalias 的外部文档。 |
HostAlias 数组 | |
tmpDirSizeLimit |
定义临时 EmptyDir 卷( |
字符串 | |
enableServiceLinks | 指明有关服务的信息是否应该注入到 Pod 的环境变量中。 |
布尔值 | |
topologySpreadConstraints | pod 的拓扑分布限制。如需更多信息,请参阅 core/v1 topologyspreadconstraint 的外部文档。 |
12.2.37. InternalServiceTemplate
模式参考
使用的: CruiseControlTemplate
, KafkaBridgeTemplate
, KafkaClusterTemplate
, KafkaConnectTemplate
, ZookeeperClusterTemplate
属性 | Description |
---|---|
metadata | 应用到资源的元数据。 |
ipFamilyPolicy |
指定服务使用的 IP 系列策略。可用选项包括 |
字符串(一个 [RequireDualStack,SingleStack,PreferDualStack]) | |
ipFamilies |
指定服务使用的 IP Families。可用的选项有 |
字符串(一个或多个 [IPv6, IPv4])数组 |
12.2.38. resourcetemplate
模式参考
用于:CruiseControlTemplate
, EntityOperatorTemplate
, KafkaBridgeTemplate
, KafkaClusterTemplate
, KafkaConnectTemplate
, KafkaExporterTemplate
, KafkaMirrorMakerTemplate
, KafkaUserTemplate
, ZookeeperClusterTemplate
属性 | Description |
---|---|
metadata | 应用到资源的元数据。 |
12.2.39. PodDisruptionBudgetTemplate
模式参考
使用的: CruiseControlTemplate
, KafkaBridgeTemplate
, KafkaClusterTemplate
, KafkaConnectTemplate
, KafkaMirrorMakerTemplate
, ZookeeperClusterTemplate
PodDisruptionBudgetTemplate
模式属性的完整列表
AMQ Streams 为每个新的 StatefulSet
或 Deployment
创建一个 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 |
应用到 |
maxUnavailable |
允许自动 pod 驱除的最大不可用 pod 数量。当 |
整数 |
12.2.40. ContainerTemplate
模式参考
用于:CruiseControlTemplate
, EntityOperatorTemplate
, KafkaBridgeTemplate
, KafkaClusterTemplate
, KafkaConnectTemplate
, KafkaExporterTemplate
, KafkaMirrorMakerTemplate
, ZookeeperClusterTemplate
您可以为容器设置自定义安全上下文和环境变量。
环境变量在 env
属性下定义为带有 name
和 value
字段的对象列表。以下示例显示了为 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 | 应该应用到容器的环境变量。 |
securityContext | 容器的安全上下文。如需更多信息,请参阅 core/v1 安全上下文的外部文档。 |
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.name
和 logging.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 |
存储配置(磁盘)。无法更新。类型取决于给定对象中的 |
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 选项。 |
jmxOptions | Zookeeper 节点的 JMX 选项. |
资源 | 要保留的 CPU 和内存资源。如需更多信息,请参阅 core/v1 资源查询的外部文档。 |
metricsConfig |
指标配置。这个类型取决于给定对象中的 |
logging |
ZooKeeper 的日志记录配置。类型取决于给定对象中的 |
模板 |
ZooKeeper 集群资源模板。通过该模板,用户可以指定如何生成 |
12.2.43. ZookeeperClusterTemplate
模式参考
使用的: ZookeeperClusterSpec
属性 | Description |
---|---|
statefulset |
ZooKeeper |
Pod |
ZooKeeper |
clientService |
ZooKeeper 客户端服务 |
nodesService |
ZooKeeper 节点服务 |
persistentVolumeClaim |
所有 ZooKeeper |
podDisruptionBudget |
ZooKeeper |
zookeeperContainer | ZooKeeper 容器的模板。 |
serviceAccount | ZooKeeper 服务帐户的模板。 |
jmxSecret | Zookeeper 集群 JMX 身份验证的 Secret 模板。 |
podSet |
ZooKeeper |
12.2.44. EntityOperatorSpec
模式参考
使用的: KafkaSpec
属性 | Description |
---|---|
topicOperator | 配置主题 Operator。 |
userOperator | User Operator 配置。 |
tlsSidecar | TLS sidecar 配置。 |
模板 |
Entity Operator 资源的模板。通过该模板,用户可以指定如何生成 |
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.name
和 logging.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 资源查询的外部文档。 |
topicMetadataMaxAttempts | 获取主题元数据时的尝试次数。 |
整数 | |
logging |
日志记录配置。类型取决于给定对象中的 |
jvmOptions | pod 的 JVM 选项。 |
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.name
和 logging.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 |
|
整数 | |
secretPrefix | 将添加到 KafkaUser 名称的前缀,用作 Secret 名称。 |
字符串 | |
livenessProbe | Pod 存活度检查。 |
readinessProbe | Pod 就绪度检查. |
资源 | 要保留的 CPU 和内存资源。如需更多信息,请参阅 core/v1 资源查询的外部文档。 |
logging |
日志记录配置。类型取决于给定对象中的 |
jvmOptions | pod 的 JVM 选项。 |
12.2.47. TlsSidecar
模式参考
使用的: CruiseControlSpec
, EntityOperatorSpec
配置 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
属性配置将使用的容器镜像。
readinessProbe
和 livenessProbe
属性为 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 的日志级别。默认值为 |
string (one of [emerg, debug, crit, err, alert, warning, notice, info]) | |
readinessProbe | Pod 就绪度检查. |
资源 | 要保留的 CPU 和内存资源。如需更多信息,请参阅 core/v1 资源查询的外部文档。 |
12.2.48. EntityOperatorTemplate
模式参考
used in: EntityOperatorSpec
属性 | Description |
---|---|
部署 |
Entity Operator |
Pod |
实体 Operator |
topicOperatorContainer | Entity Topic Operator 容器的模板。 |
userOperatorContainer | Entity User Operator 容器的模板。 |
tlsSidecarContainer | Entity Operator TLS sidecar 容器的模板。 |
serviceAccount | Entity Operator 服务帐户的模板。 |
12.2.49. certificateAuthority
模式参考
使用的: KafkaSpec
在集群中如何使用 TLS 证书的配置。这适用于用于集群中内部通信的证书,以及通过 Kafka.spec.kafka.listeners.tls
用于访问的证书。
属性 | Description |
---|---|
generateCertificateAuthority | 如果为 true,则会自动生成证书颁发机构证书。否则,用户需要提供 CA 证书的 Secret。默认为 true。 |
布尔值 | |
generateSecretOwnerReference |
如果为 |
布尔值 | |
validityDays | 生成的证书应有效天数。默认值为 365。 |
整数 | |
renewalDays |
证书续订期间的天数。这是证书过期之前可以执行续订操作的天数。当 |
整数 | |
certificateExpirationPolicy |
在生成 |
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 # ...
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.name
和 logging.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 |
|
资源 | 为 Cruise Control 容器保留的 CPU 和内存资源。如需更多信息,请参阅 core/v1 资源查询的外部文档。 |
livenessProbe | 对 Cruise Control 容器进行 Pod 存活度检查。 |
readinessProbe | Pod 就绪度检查是否有 Cruise Control 容器。 |
jvmOptions | 断路器控制容器的 JVM 选项。 |
logging |
用于 Cruise Control 的日志记录配置(Log4j 2)类型取决于给定对象中的 |
模板 |
模板以指定如何生成控制资源 |
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 |
指标配置。这个类型取决于给定对象中的 |
12.2.51. CruiseControlTemplate
模式参考
使用的: CruiseControlSpec
属性 | Description |
---|---|
部署 |
用于控制部署的模板 |
Pod |
用于控制 |
apiService |
用于控制 API 服务 |
podDisruptionBudget |
用于控制 |
cruiseControlContainer | Cruise Control 容器的模板。 |
tlsSidecarContainer |
|
serviceAccount | Cruise Control 服务帐户的模板。 |
12.2.52. BrokerCapacity
schema 参考
使用的: CruiseControlSpec
属性 | Description |
---|---|
disk |
|
字符串 | |
cpuUtilization |
|
整数 | |
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 资源查询的外部文档。 |
logging |
仅记录给定严重性或更高严重性的日志消息。有效级别: [ |
字符串 | |
enableSaramaLogging | 启用 Sarama 日志记录,这是 Kafka Exporter 使用的 Go 客户端库。 |
布尔值 | |
模板 | 自定义部署模板和 pod。 |
livenessProbe | Pod 存活度检查。 |
readinessProbe | Pod 就绪度检查。 |
12.2.54. KafkaExporterTemplate
模式参考
使用的: KafkaExporterSpec
属性 | Description |
---|---|
部署 |
Kafka 导出器 |
Pod |
Kafka 导出器 |
service |
|
container | Kafka Exporter 容器的模板。 |
serviceAccount | Kafka Exporter 服务帐户的模板。 |
12.2.55. KafkaStatus
模式参考
使用的: Kafka
属性 | Description |
---|---|
conditions | 状态条件列表。 |
| |
observedGeneration | Operator 最后协调的 CRD 的生成。 |
整数 | |
监听器 | 内部和外部监听程序的地址。 |
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 |
|
字符串 | |
name | 侦听器的名称。 |
字符串 | |
addresses | 此侦听器的地址列表。 |
bootstrapServers |
用于使用此侦听器连接到 Kafka 集群的 |
字符串 | |
证书 |
用于在连接到给定侦听器时验证服务器身份的 TLS 证书列表。仅为 |
字符串数组 |
12.2.58. ListenerAddress
模式参考
used in: ListenerStatus
属性 | Description |
---|---|
主机 | Kafka bootstrap 服务的 DNS 名称或 IP 地址。 |
字符串 | |
port | Kafka bootstrap 服务的端口。 |
整数 |
12.2.59. KafkaConnect
模式参考
属性 | Description |
---|---|
spec | Kafka Connect 集群的规格。 |
status | Kafka Connect 集群的状态。 |
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-cluster
的group.id
-
使用默认值
connect-cluster-offsets
的offset.storage.topic
-
config.storage.topic
with default valueconnect-cluster-configs
-
status.storage.topic
with default valueconnect-cluster-status
-
key.converter
with default valueorg.apache.kafka.connect.json.JsonConverter
-
value.converter
with default valueorg.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.name
和 logging.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> :_<port>_ 对列表。 |
字符串 | |
tls | TLS 配置。 |
身份验证 |
Kafka Connect 的身份验证配置。这个类型取决于给定对象中的 |
| |
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 资源查询的外部文档。 |
livenessProbe | Pod 存活度检查。 |
readinessProbe | Pod 就绪度检查. |
jvmOptions | pod 的 JVM 选项。 |
jmxOptions | JMX 选项. |
logging |
Kafka Connect 的日志记录配置。类型取决于给定对象中的 |
clientRackInitImage |
用于初始化 |
字符串 | |
rack |
配置用作 |
tracing |
在 Kafka Connect 中配置追踪。类型取决于给定对象中的 |
模板 |
Kafka Connect 和 Kafka Mirror Maker 2 资源的模板。这个模板允许用户指定如何生成 |
externalConfiguration | 将 Secret 或 ConfigMap 中的数据传递给 Kafka Connect pod,并使用它们配置连接器。 |
build | 配置应如何构建 Connect 容器镜像。可选。 |
metricsConfig |
指标配置。这个类型取决于给定对象中的 |
12.2.61. ClientTls
模式参考
used in: KafkaBridgeSpec
, KafkaConnectSpec
, KafkaMirrorMaker2ClusterSpec
, KafkaMirrorMakerConsumerSpec
, KafkaMirrorMakerProducerSpec
配置用于连接 KafkaConnect、KafkaBridge、KafkaMirror、KafkaMirrorMaker2 到集群的 TLS 可信证书。
12.2.61.1. trustedCertificates
使用 trustedCertificates
属性 提供一个 secret 列表。
12.2.61.2. ClientTls
模式属性
属性 | Description |
---|---|
trustedCertificates | TLS 连接的可信证书。 |
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
类型来自 KafkaClientAuthenticationScramSha256
、KafkaClientAuthenticationScramSha512
、KafkaClientAuthenticationPlain
、KafkaClientAuthentication
Plain。它必须具有类型为 KafkaClientAuthenticationTls
的值 tls
。
属性 | Description |
---|---|
certificateAndKey |
对包含证书和私钥对的 |
type |
必须为 |
字符串 |
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 |
对包含密码的 |
type |
必须是 |
字符串 | |
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 |
对包含密码的 |
type |
必须为 |
字符串 | |
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
, KafkaClientAuthenticationOAuth
的 KafkaClientAuthenticationPlain
类型。对于类型 KafkaClientAuthenticationPlain
,它需要是值 plain
。
属性 | Description |
---|---|
passwordSecret |
对包含密码的 |
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
, KafkaClientAuthenticationPlain
的 KafkaClientAuthenticationOAuth
类型。对于类型 KafkaClientAuthenticationOAuth
,它需要是值 oauth
。
属性 | Description |
---|---|
accessToken | 链接到包含从授权服务器获取的访问令牌的 OpenShift Secret。 |
accessTokenIsJwt |
配置访问令牌是否应被视为 JWT。如果授权服务器返回不透明令牌,则此项应设为 |
布尔值 | |
受众 |
对授权服务器进行身份验证时使用的 OAuth 使用者。某些授权服务器需要明确设置使用者。可能的值取决于配置授权服务器的方式。默认情况下,在执行令牌端点请求时,不会指定 |
字符串 | |
clientId | Kafka 客户端可以用来向 OAuth 服务器进行身份验证并使用令牌端点 URI 的 OAuth 客户端 ID。 |
字符串 | |
clientSecret | 链接到包含 Kafka 客户端 secret 的 OpenShift Secret,这些 secret 可以用来与 OAuth 服务器进行身份验证,并使用令牌端点 URI。 |
connectTimeoutSeconds | 连接授权服务器时出现连接超时(以秒为单位)。如果没有设置,则有效连接超时为 60 秒。 |
整数 | |
disableTlsHostnameVerification |
启用或禁用 TLS 主机名验证。默认值为 |
布尔值 | |
maxTokenExpirySeconds | 设置或限制访问令牌的生存时间到指定的秒数。如果授权服务器返回不透明令牌,则应设置此项。 |
整数 | |
readTimeoutSeconds | 连接到授权服务器时读取超时(以秒为单位)。如果没有设置,则有效读取超时为 60 秒。 |
整数 | |
refreshToken | 链接到包含刷新令牌的 OpenShift Secret,该令牌可用于从授权服务器获取访问令牌。 |
scope |
对授权服务器进行身份验证时使用的 OAuth 范围。些授权服务器需要设置此项。可能的值取决于配置授权服务器的方式。默认情况下,在执行令牌端点请求时不指定 |
字符串 | |
tlsTrustedCertificates | TLS 与 OAuth 服务器连接的可信证书。 |
tokenEndpointUri | 授权服务器令牌端点 URI。 |
字符串 | |
type |
必须是 |
字符串 |
12.2.68. Jaegertracing 模式
参考
used in: KafkaBridgeSpec
, KafkaConnectSpec
, KafkaMirrorMaker2Spec
, KafkaMirrorMakerSpec
type
属性是一种分ator,用于区分使用与其它子类型中添加的 JaegerTracing
类型。它必须具有 jaeger
值才能类型 JaegerTracing
。
属性 | Description |
---|---|
type |
必须为 |
字符串 |
12.2.69. KafkaConnectTemplate
模式参考
使用的: KafkaConnectSpec
, KafkaMirrorMaker2Spec
属性 | Description |
---|---|
部署 |
Kafka Connect |
Pod |
Kafka Connect |
apiService |
Kafka Connect API |
connectContainer | Kafka Connect 容器的模板。 |
initContainer | Kafka init 容器的模板。 |
podDisruptionBudget |
Kafka Connect |
serviceAccount | Kafka Connect 服务帐户的模板。 |
clusterRoleBinding | Kafka Connect ClusterRoleBinding 的模板。 |
buildPod |
Kafka Connect Build |
buildContainer | Kafka Connect Build 容器的模板。构建容器仅用于 OpenShift。 |
buildConfig | 用于构建新容器镜像的 Kafka Connect BuildConfig 模板。BuildConfig 仅适用于 OpenShift。 |
buildServiceAccount | Kafka Connect Build 服务帐户的模板。 |
jmxSecret | Kafka Connect Cluster JMX 身份验证的 Secret 模板。 |
12.2.70. DeploymentTemplate
模式参考
used in: KafkaBridgeTemplate
, KafkaConnectTemplate
, KafkaMirrorMakerTemplate
属性 | Description |
---|---|
metadata | 应用到资源的元数据。 |
deploymentStrategy |
用于此 Deployment 的 DeploymentStrategy。有效值为 |
字符串(一个 [RollingUpdate, Recreate]) |
12.2.71. BuildConfigTemplate
模式参考
使用的: KafkaConnectTemplate
属性 | Description |
---|---|
metadata |
应用到 |
pullSecret | 带有用于拉取基础镜像的凭证的 Container Registry Secret。 |
字符串 |
12.2.72. ExternalConfiguration
模式参考
使用的: KafkaConnectSpec
, KafkaMirrorMaker2Spec
ExternalConfiguration
模式属性的完整列表
配置外部存储属性,以定义 Kafka 连接连接器的配置选项。
您可以将 ConfigMap 或 Secret 挂载到 Kafka Connect pod 中,作为环境变量或卷。卷和环境变量在 KafkaConnect.spec
的 externalConfiguration
属性中配置。
应用时,环境变量和卷可在开发您的连接器时使用。
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_ID
和 AWS_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
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
Secret 中属性值的占位符在连接器配置中被引用。占位符结构为 file:PATH-AND-FILE-NAME :PROPERTY
。FileConfigProvider
从连接程序配置中挂载的 Secret 读取并提取数据库的 username 和 password 属性值。
显示外部值的占位符示例
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
凭据的占位符在连接器配置中引用。占位符结构 是目录:PATH:FILE-NAME
。DirectoryConfigProvider
在连接器配置中从挂载的 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 的数据作为环境变量提供。 |
卷 | 使 Kafka Connect pod 中的 Secret 或 ConfigMap 的数据作为卷可用。 |
12.2.73. ExternalConfigurationEnv
模式参考
used in: ExternalConfiguration
属性 | Description |
---|---|
name |
传递给 Kafka Connect pod 的环境变量的名称。环境变量的名称不能以 |
字符串 | |
valueFrom | 将传递给 Kafka Connect pod 的环境变量值。它可以作为 Secret 或 ConfigMap 字段的引用传递。该字段必须正好指定一个 Secret 或 ConfigMap。 |
12.2.74. ExternalConfigurationEnvVarSource
模式参考
used in: ExternalConfigurationEnv
属性 | Description |
---|---|
configMapKeyRef | 引用 ConfigMap 中的键。如需更多信息,请参阅 core/v1 configmapkeyselector 的外部文档。 |
secretKeyRef | 引用 Secret 中的密钥。如需更多信息,请参阅 core/v1 secretkeyselector 的外部文档。 |
12.2.75. ExternalConfigurationVolumeSource
schema 引用
used in: ExternalConfiguration
属性 | Description |
---|---|
configMap | 引用 ConfigMap 中的键。必须指定一个 Secret 或 ConfigMap。如需更多信息,请参阅 core/v1 configmapvolumesource 的外部文档。 |
name | 添加至 Kafka Connect pod 的卷名称。 |
字符串 | |
secret | 引用 Secret 中的密钥。必须指定一个 Secret 或 ConfigMap。如需更多信息,请参阅 core/v1 secretvolume 源的外部文档。 |
12.2.76. 构建
架构参考
使用的: KafkaConnectSpec
为 Kafka Connect 部署配置额外的连接器。
12.2.76.1. output
要使用额外的连接器插件构建新容器镜像,AMQ Streams 需要一个容器 registry,其中可将镜像推送到、存储和拉取(pull)镜像。AMQ Streams 没有运行自己的容器 registry,因此必须提供 registry。AMQ Streams 支持私有容器 registry 和公共 registry,如 Quay 或 Docker Hub。容器 registry 在 KafkaConnect
自定义资源的 .spec.build.output
部分中配置。输出
配置(需要它)支持两种类型: docker
和 imagestream
。
使用 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 #...
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 #...
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 #...
使用 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 #...
使用 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 #...
使用其他
工件
其他
工件(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 #...
12.2.76.3. 构建
架构属性
属性 | Description |
---|---|
output |
配置应存储新构建的镜像的位置。必需。类型取决于给定对象中的 |
资源 | 为构建保留的 CPU 和内存资源。如需更多信息,请参阅 core/v1 资源查询的外部文档。 |
plugins | 应该添加到 Kafka 连接中的连接器插件列表。必需。 |
|
12.2.77. DockerOutput
模式参考
使用的: 构建
type
属性是一种分ator,用于区分 DockerOutput
类型与 ImageStreamOutput
类型。它必须具有 docker
的值才能类型为 DockerOutput
。
属性 | Description |
---|---|
image |
用于标记和推送新构建的镜像的完整名称。例如, |
字符串 | |
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 |
必须是 |
字符串 |
12.2.78. ImageStreamOutput
模式参考
使用的: 构建
type
属性是一种分ator,用于区分 ImageStreamOutput
类型与 DockerOutput
类型。它必须具有类型 ImageStreamOutput
的值 镜像流
。
属性 | Description |
---|---|
image |
将新构建镜像的 ImageStream 的名称和标签。例如, |
字符串 | |
type |
必须是 |
字符串 |
12.2.79. 插件
架构参考
使用的: 构建
属性 | Description |
---|---|
name |
连接器插件的唯一名称。将用于生成将存储连接器工件的路径。名称必须在 KafkaConnect 资源中唯一。名称必须遵循以下模式: |
字符串 | |
工件 | 属于此连接器插件的工件列表。必需。 |
|
12.2.80. JarArtifact
模式参考
使用的: 插件
属性 | Description |
---|---|
url |
要下载的构件的 URL。AMQ Streams 不执行下载工件的任何安全扫描。为安全起见,您应该首先手动验证工件并配置 checksum 验证,以确保自动构建中使用相同的工件。 |
字符串 | |
sha512sum |
工件的 SHA512 校验和。可选。如果指定,则在构建新容器时将验证校验和。如果没有指定,则不会验证下载的工件。不适用于 |
字符串 | |
insecure |
默认情况下,验证使用 TLS 的连接来检查它们是否安全。使用的服务器证书必须是有效、可信,并且包含服务器名称。通过将此选项设置为 |
布尔值 | |
type |
必须是 |
字符串 |
12.2.81. TgzArtifact
模式参考
使用的: 插件
属性 | Description |
---|---|
url |
要下载的构件的 URL。AMQ Streams 不执行下载工件的任何安全扫描。为安全起见,您应该首先手动验证工件并配置 checksum 验证,以确保自动构建中使用相同的工件。 |
字符串 | |
sha512sum |
工件的 SHA512 校验和。可选。如果指定,则在构建新容器时将验证校验和。如果没有指定,则不会验证下载的工件。不适用于 |
字符串 | |
insecure |
默认情况下,验证使用 TLS 的连接来检查它们是否安全。使用的服务器证书必须是有效、可信,并且包含服务器名称。通过将此选项设置为 |
布尔值 | |
type |
必须为 |
字符串 |
12.2.82. ZipArtifact
模式参考
使用的: 插件
属性 | Description |
---|---|
url |
要下载的构件的 URL。AMQ Streams 不执行下载工件的任何安全扫描。为安全起见,您应该首先手动验证工件并配置 checksum 验证,以确保自动构建中使用相同的工件。 |
字符串 | |
sha512sum |
工件的 SHA512 校验和。可选。如果指定,则在构建新容器时将验证校验和。如果没有指定,则不会验证下载的工件。不适用于 |
字符串 | |
insecure |
默认情况下,验证使用 TLS 的连接来检查它们是否安全。使用的服务器证书必须是有效、可信,并且包含服务器名称。通过将此选项设置为 |
布尔值 | |
type |
必须为 |
字符串 |
12.2.83. MavenArtifact
模式参考
使用的: 插件
type
属性是一个标尺,用于区分 MavenArtifact
类型与 JarArtifact
、TgzArtifact
、ZipArtifact
OtherArtifact
.它必须具有 MavenArtifact
类型的值 maven
。
属性 | Description |
---|---|
软件仓库 |
用于从中下载工件的 Maven 存储库。仅适用于 |
字符串 | |
group |
Maven 组 ID.仅适用于 |
字符串 | |
工件 |
Maven 工件 ID。仅适用于 |
字符串 | |
version |
Maven 版本号。仅适用于 |
字符串 | |
type |
必须为 |
字符串 |
12.2.84. OtherArtifact
模式参考
使用的: 插件
属性 | Description |
---|---|
url |
要下载的构件的 URL。AMQ Streams 不执行下载工件的任何安全扫描。为安全起见,您应该首先手动验证工件并配置 checksum 验证,以确保自动构建中使用相同的工件。 |
字符串 | |
sha512sum |
工件的 SHA512 校验和。可选。如果指定,则在构建新容器时将验证校验和。如果没有指定,则不会验证下载的工件。不适用于 |
字符串 | |
fileName | 将在其中存储工件的名称。 |
字符串 | |
insecure |
默认情况下,验证使用 TLS 的连接来检查它们是否安全。使用的服务器证书必须是有效、可信,并且包含服务器名称。通过将此选项设置为 |
布尔值 | |
type |
必须是 |
字符串 |
12.2.85. KafkaConnectStatus
schema 参考
使用的: KafkaConnect
属性 | Description |
---|---|
conditions | 状态条件列表。 |
| |
observedGeneration | Operator 最后协调的 CRD 的生成。 |
整数 | |
url | 用于管理和监控 Kafka 连接连接器的 REST API 端点的 URL。 |
字符串 | |
connectorPlugins | 此 Kafka Connect 部署中的连接器插件列表。 |
labelSelector | 提供此资源的 pod 的标签选择器。 |
字符串 | |
replicas | 提供此资源的当前 pod 数量。 |
整数 |
12.2.86. ConnectorPlugin
schema 参考
使用的: KafkaConnectStatus
, KafkaMirrorMaker2Status
属性 | Description |
---|---|
type |
连接器插件的类型。可用的类型是 |
字符串 | |
version | 连接器插件的版本。 |
字符串 | |
类 | 连接器插件的类。 |
字符串 |
12.2.87. KafkaTopic
模式参考
属性 | Description |
---|---|
spec | 主题的规格。 |
status | 主题的状态。 |
12.2.88. KafkaTopicSpec
模式参考
使用的: KafkaTopic
属性 | Description |
---|---|
分区 |
主题应具有的分区数量。这无法在创建主题后减少。可在创建主题后增加它,但务必要了解具有的后果,特别是与语义分区相关的主题。如果不存在,则默认使用 |
整数 | |
replicas |
主题应具有的副本数。如果不存在,则这个代理配置将默认为 |
整数 | |
config | 主题配置。 |
map | |
topicName | 主题的名称。如果不存在,则默认为主题的 metadata.name。建议不要设置此项,除非主题名称不是有效的 OpenShift 资源名称。 |
字符串 |
12.2.89. KafkaTopicStatus
模式参考
使用的: KafkaTopic
属性 | Description |
---|---|
conditions | 状态条件列表。 |
| |
observedGeneration | Operator 最后协调的 CRD 的生成。 |
整数 | |
topicName | 主题名称。 |
字符串 |
12.2.90. KafkaUser
模式参考
属性 | Description |
---|---|
spec | 用户的规格。 |
status | Kafka 用户的状态。 |
12.2.91. KafkaUserSpec
模式参考
使用的: KafkaUser
属性 | Description |
---|---|
身份验证 |
此 Kafka 用户启用了验证机制。支持的验证机制有
身份验证是可选的。如果没有配置身份验证,则不会生成任何凭证。为用户设置的 ACL 和配额以 < |
| |
授权 |
此 Kafka 用户的授权规则。类型取决于给定对象中的 |
配额 | 用于控制客户端使用的代理资源的请求的配额。可以强制使用网络带宽和请求率配额。Kafka 用户配额的Kafka 文档可在 http://kafka.apache.org/documentation/#design_quotas 中找到。 |
模板 |
模板来指定 Kafka 用户 |
12.2.92. KafkaUserTlsClientAuthentication
模式参考
使用的: KafkaUserSpec
type
属性是一种差异性,用于区分 KafkaUserTlsClientAuthentication
类型来自于 KafkaUserTlsExternalClientAuthentication
, KafkaUserScramSha512ClientAuthentication
。对于类型 KafkaUserTlsClientAuthentication
,它需要是值 tls
。
属性 | Description |
---|---|
type |
必须为 |
字符串 |
12.2.93. KafkaUserTlsExternalClientAuthentication
模式参考
使用的: KafkaUserSpec
type
属性是一个差异性,用于区分 KafkaUserTlsExternalClientAuthentication
类型来自 KafkaUserTlsClientAuthentication
, KafkaUserScramSha512ClientAuthentication
。它必须拥有类型为 KafkaUserTlsExternalClientAuthentication
的值 tls-external
。
属性 | Description |
---|---|
type |
必须是 |
字符串 |
12.2.94. KafkaUserScramSha512ClientAuthentication
架构参考
使用的: KafkaUserSpec
type
属性是一种差异性,用于区分来自 KafkaUserTlsClientAuthentication
的 KafkaUserScramSha512ClientAuthentication
类型,即 KafkaUserTlsExternalClientAuthentication
。它必须值为 scram-sha-512
类型,类型为 KafkaUserScramSha512ClientAuthentication
。
属性 | Description |
---|---|
password | 指定用户的密码。如果没有设置,则 User Operator 会生成一个新密码。 |
type |
必须为 |
字符串 |
12.2.95. 密码
架构参考
使用的: KafkaUserScramSha512ClientAuthentication
属性 | Description |
---|---|
valueFrom | 应该从中读取密码的机密。 |
12.2.96. PasswordSource
模式参考
使用的: 密码
属性 | Description |
---|---|
secretKeyRef | 在资源命名空间中选择 Secret 的键。如需更多信息,请参阅 core/v1 secretkeyselector 的外部文档。 |
12.2.97. KafkaUserAuthorizationSimple
模式参考
使用的: KafkaUserSpec
type
属性是一种分ator,用于区分使用 KafkaUserAuthorizationSimple
的子类型,它可能会在以后添加。它必须使类型 KafkaUserAuthorizationSimple
的值 很简单
。
属性 | Description |
---|---|
type |
必须 |
字符串 | |
ACL | 应用于此用户的 ACL 规则列表。 |
|
12.2.98. AclRule
模式参考
使用的: KafkaUserAuthorizationSimple
在使用 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 规则的资源。这个类型取决于给定对象中的 |
| |
type |
规则的类型。目前唯一支持的类型是 |
字符串([allow、deny] 之一) |
12.2.99. AclRuleTopicResource
模式参考
使用的: AclRule
type
属性是一种差异性,用于区分来自 AclRuleTopicResource
的 AclRuleTopicResource
类型、AclRuleClusterResource
、AclRuleTransactionalIdResource
。它必须具有类型 AclRuleTopicResource
的值 主题
。
属性 | Description |
---|---|
type |
必须为 |
字符串 | |
name |
应用给定 ACL 规则的资源名称。可以和 |
字符串 | |
patternType |
描述 resource 字段中使用的模式。支持的类型是 |
字符串([前缀、字面] 之一) |
12.2.100. AclRuleGroupResource
模式参考
使用的: AclRule
type
属性是一种差异性,用于区分来自 AclRuleTopicResource
的 AclRuleGroupResource
类型、AclRuleClusterResource
、AclRuleTransactionalIdResource
。它必须具有类型 AclRuleGroupResource
的值 组
。
属性 | Description |
---|---|
type |
必须为 |
字符串 | |
name |
应用给定 ACL 规则的资源名称。可以和 |
字符串 | |
patternType |
描述 resource 字段中使用的模式。支持的类型是 |
字符串([前缀、字面] 之一) |
12.2.101. AclRuleClusterResource
模式参考
使用的: AclRule
type
属性是一个差异性符,用于区分来自 AclRuleTopicResource
的 AclRuleClusterResource
类型、AclRuleGroupResource
、AclRuleTransactionalIdResource
。对于类型 AclRuleClusterResource
,它需要值 cluster
。
属性 | Description |
---|---|
type |
必须是 |
字符串 |
12.2.102. AclRuleTransactionalIdResource
schema 参考
使用的: AclRule
type
属性是一种差异性,用于区分来自 AclRuleTransactionalIdResource
的 AclRuleTransactionalIdResource
、AclRuleGroupResource
、AclRuleClusterResource
。对于类型 AclRuleTransactionalIdResource
,它必须是值 transactionalId
。
属性 | Description |
---|---|
type |
必须是 |
字符串 | |
name |
应用给定 ACL 规则的资源名称。可以和 |
字符串 | |
patternType |
描述 resource 字段中使用的模式。支持的类型是 |
字符串([前缀、字面] 之一) |
12.2.103. KafkaUserQuotas
模式参考
使用的: KafkaUserSpec
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
为 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 证书的 |
12.2.105. KafkaUserStatus
schema 参考
使用的: KafkaUser
属性 | Description |
---|---|
conditions | 状态条件列表。 |
| |
observedGeneration | Operator 最后协调的 CRD 的生成。 |
整数 | |
username | 用户名。 |
字符串 | |
secret |
存储凭证的 |
字符串 |
12.2.106. KafkaMirrorMaker
模式参考
KafkaMirrorMaker
类型已弃用。请使用 KafkaMirrorMaker2
替代。
属性 | Description |
---|---|
spec | Kafka MirrorMaker 的规格。 |
status | Kafka MirrorMaker 的状态。 |
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. KafkaMirrorMakerConsumerSpec
和 KafkaMirrorMakerProducerSpec
使用 KafkaMirrorMakerConsumerSpec
和 KafkaMirrorMakerProducerSpec
配置源(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.name
和 logging.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 镜像。 |
字符串 | |
消费者 | 源集群的配置。 |
制作者 | 目标集群的配置。 |
资源 | 要保留的 CPU 和内存资源。如需更多信息,请参阅 core/v1 资源查询的外部文档。 |
白名单 |
|
字符串 | |
Include |
镜像中包含的主题列表。此选项允许使用 Java 风格的正则表达式。使用表达式 |
字符串 | |
jvmOptions | pod 的 JVM 选项。 |
logging |
MirrorMaker 的日志记录配置。类型取决于给定对象中的 |
metricsConfig |
指标配置。这个类型取决于给定对象中的 |
tracing |
Kafka MirrorMaker 中的追踪配置。类型取决于给定对象中的 |
模板 |
模板来指定 Kafka MirrorMaker 资源、 |
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 地址
- 安全(加密、验证和授权)
- 消费者组标识符
- 拦截器
具体来说,所有与以下字符串之一相等或开始的配置选项都会被禁止:
-
bootstrap.servers
-
group.id
-
interceptor.classes
-
SSL.
(不包括具体的例外) -
SASL:
-
安全性.
当在 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 | 标识此使用者所属的消费者组的唯一字符串。 |
字符串 | |
身份验证 |
用于连接到集群的身份验证配置。这个类型取决于给定对象中的 |
| |
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 配置。 |
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 地址
- 安全(加密、验证和授权)
- 拦截器
具体来说,所有与以下字符串之一相等或开始的配置选项都会被禁止:
-
bootstrap.servers
-
interceptor.classes
-
SSL.
(不包括具体的例外) -
SASL:
-
安全性.
当在 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 设置为在失败的发送中退出的标志。默认值为 |
布尔值 | |
身份验证 |
用于连接到集群的身份验证配置。这个类型取决于给定对象中的 |
| |
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 配置。 |
12.2.110. KafkaMirrorMakerTemplate
模式参考
使用的: KafkaMirrorMakerSpec
属性 | Description |
---|---|
部署 |
Kafka MirrorMaker |
Pod |
Kafka MirrorMaker |
podDisruptionBudget |
Kafka MirrorMaker |
mirrorMakerContainer | Kafka MirrorMaker 容器的模板。 |
serviceAccount | Kafka MirrorMaker 服务帐户的模板。 |
12.2.111. KafkaMirrorMakerStatus
模式参考
使用的: KafkaMirrorMaker
属性 | Description |
---|---|
conditions | 状态条件列表。 |
| |
observedGeneration | Operator 最后协调的 CRD 的生成。 |
整数 | |
labelSelector | 提供此资源的 pod 的标签选择器。 |
字符串 | |
replicas | 提供此资源的当前 pod 数量。 |
整数 |
12.2.112. KafkaBridge
模式参考
属性 | Description |
---|---|
spec | Kafka Bridge 的规格。 |
status | Kafka Bridge 的状态。 |
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
文件中定义,该文件对 healthy
和 ready
端点有以下默认配置:
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.name
和 logging.valueFrom.configMapKeyRef.key
属性是必需的。如果没有设置 name
或 key
,则会使用默认日志记录。在 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 配置。 |
身份验证 |
用于连接到集群的身份验证配置。这个类型取决于给定对象中的 |
| |
http | HTTP 相关配置。 |
adminClient | Kafka 管理与客户端相关的配置。 |
消费者 | Kafka 消费者相关的配置。 |
制作者 | Kafka producer 相关配置。 |
资源 | 要保留的 CPU 和内存资源。如需更多信息,请参阅 core/v1 资源查询的外部文档。 |
jvmOptions | 目前,pod 支持 JVM 选项。 |
logging |
Kafka Bridge 的日志记录配置。类型取决于给定对象中的 |
enableMetrics | 为 Kafka Bridge 启用指标。默认为 false。 |
布尔值 | |
livenessProbe | Pod 存活度检查。 |
readinessProbe | Pod 就绪度检查. |
模板 |
Kafka Bridge 资源的模板。通过该模板,用户可以指定如何生成 |
tracing |
Kafka Bridge 中的追踪配置。类型取决于给定对象中的 |
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 配置。 |
12.2.115. KafkaBridgeHttpCors
模式参考
属性 | 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 |
Pod |
Kafka Bridge |
apiService |
Kafka Bridge API |
podDisruptionBudget |
Kafka Bridge |
bridgeContainer | Kafka Bridge 容器的模板。 |
serviceAccount | Kafka Bridge 服务帐户的模板。 |
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 的规格。 |
status | Kafka Connector 的状态。 |
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 集群的规格。 |
status | Kafka MirrorMaker 2.0 集群的状态。 |
12.2.125. KafkaMirrorMaker2Spec
模式参考
使用的: KafkaMirrorMaker2
属性 | Description |
---|---|
version | Kafka Connect 版本。默认为 3.2.3。参阅用户文档来了解升级或降级版本所需的流程。 |
字符串 | |
replicas | Kafka Connect 组中的 pod 数量。 |
整数 | |
image | pod 的 docker 镜像。 |
字符串 | |
connectCluster |
用于 Kafka Connect 的集群别名。别名必须与位于 |
字符串 | |
clusters | 用于镜像的 Kafka 集群。 |
mirrors | 配置 MirrorMaker 2.0 连接器。 |
资源 | CPU 和内存资源和请求的初始资源的最大限制。如需更多信息,请参阅 core/v1 资源查询的外部文档。 |
livenessProbe | Pod 存活度检查。 |
readinessProbe | Pod 就绪度检查. |
jvmOptions | pod 的 JVM 选项。 |
jmxOptions | JMX 选项. |
logging |
Kafka Connect 的日志记录配置。类型取决于给定对象中的 |
clientRackInitImage |
用于初始化 |
字符串 | |
rack |
配置用作 |
tracing |
在 Kafka Connect 中配置追踪。类型取决于给定对象中的 |
模板 |
Kafka Connect 和 Kafka Mirror Maker 2 资源的模板。这个模板允许用户指定如何生成 |
externalConfiguration | 将 Secret 或 ConfigMap 中的数据传递给 Kafka Connect pod,并使用它们配置连接器。 |
metricsConfig |
指标配置。这个类型取决于给定对象中的 |
12.2.126. KafkaMirrorMaker2ClusterSpec
模式参考
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 集群连接的 |
字符串 | |
tls | 用于将 MirrorMaker 2.0 连接器连接到集群的 TLS 配置。 |
身份验证 |
用于连接到集群的身份验证配置。这个类型取决于给定对象中的 |
| |
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
模式参考
属性 | Description |
---|---|
sourceCluster |
Kafka MirrorMaker 2.0 连接器使用的源集群的别名。别名必须与位于 |
字符串 | |
targetCluster |
Kafka MirrorMaker 2.0 连接器使用的目标集群的别名。别名必须与位于 |
字符串 | |
sourceConnector | Kafka MirrorMaker 2.0 源连接器的规格。 |
heartbeatConnector | Kafka MirrorMaker 2.0 heartbeat 连接器的规格。 |
checkpointConnector | Kafka MirrorMaker 2.0 检查点连接器的规格。 |
topicsPattern | 与要镜像的主题匹配的正则表达式,如 "topic1|topic2|topic3"。也支持以逗号分隔的列表。 |
字符串 | |
topicsBlacklistPattern |
|
字符串 | |
topicsExcludePattern | 与要从镜像中排除的主题匹配的正则表达式。也支持以逗号分隔的列表。 |
字符串 | |
groupsPattern | 与要镜像的消费者组匹配的正则表达式。也支持以逗号分隔的列表。 |
字符串 | |
groupsBlacklistPattern |
|
字符串 | |
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 部署中的连接器插件列表。 |
connectors | MirrorMaker 2.0 连接器状态列表,如 Kafka Connect REST API 报告。 |
映射数组 | |
labelSelector | 提供此资源的 pod 的标签选择器。 |
字符串 | |
replicas | 提供此资源的当前 pod 数量。 |
整数 |
12.2.130. KafkaRebalance
模式参考
属性 | Description |
---|---|
spec | Kafka 重新平衡的规格。 |
status | Kafka 重新平衡的状态。 |
12.2.131. KafkaRebalanceSpec
模式参考
使用的: KafkaRebalance
属性 | Description |
---|---|
模式 |
模式以运行重新平衡。支持的模式是
|
字符串(一个 [remove-brokers、full、add-brokers]) | |
代理(broker) |
当扩展或要删除的代理时,新添加的代理列表(如果缩减)用于重新平衡。此列表只能用于重新平衡模式 |
整数数组 | |
目标 | 目标列表,按降序排列,用于生成和执行重新平衡提议。支持的目标可在 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 通过软件订阅提供。要管理您的订阅,请访问红帽客户门户中的帐户。
访问您的帐户
- 转至 access.redhat.com。
- 如果您还没有帐户,请创建一个帐户。
- 登录到您的帐户。
激活订阅
- 转至 access.redhat.com。
- 导航到 My Subscriptions。
- 导航到 激活订阅 并输入您的 16 位激活号。
下载 Zip 和 Tar 文件
要访问 zip 或 tar 文件,请使用客户门户网站查找下载的相关文件。如果您使用 RPM 软件包,则不需要这一步。
- 打开浏览器并登录红帽客户门户网站 产品下载页面,网址为 access.redhat.com/downloads。
- 在 INTEGRATION AND AUTOMATION 目录中找到 AMQ Streams for Apache Kafka 项。
- 选择所需的 AMQ Streams 产品。此时会打开 Software Downloads 页面。
- 单击组件的 Download 链接。
使用 DNF 安装软件包
要安装软件包以及所有软件包的依赖软件包,请使用:
dnf install <package_name>
要从本地目录中安装之前下载的软件包,请使用:
dnf install <path_to_download_package>
更新于 2023-10-30