第 5 章 使用 AMQ Streams Operator
使用 AMQ Streams 操作器来管理您的 Kafka 集群,以及 Kafka 主题和用户。
5.1. 使用 Cluster Operator 复制链接链接已复制到粘贴板!
Cluster Operator 用于部署 Kafka 集群和其他 Kafka 组件。
Cluster Operator 使用 YAML 安装文件进行部署。
如需有关部署 Cluster Operator 的信息,请参阅 OpenShift 指南中的 Deploying and upgrade AMQ Streams 中的 部署 Cluster Operator。
有关 Kafka 可用部署选项的详情,请参考 Kafka 集群配置。
在 OpenShift 中,Kafka Connect 部署可以纳入 Source2Image 功能,以提供添加额外连接器的便捷方式。
5.1.1. Cluster Operator 配置 复制链接链接已复制到粘贴板!
Cluster Operator 可以通过以下支持的环境变量和日志记录配置进行配置。
STRIMZI_NAMESPACEOperator 应操作的命名空间的逗号分隔列表。如果没有设置,设为空字符串,或设置为
*,Cluster Operator 将在所有命名空间中运行。Cluster Operator 部署可能会使用 OpenShift Downward API 自动将其设置为 Cluster Operator 部署到的命名空间。请参见以下示例:env: - name: STRIMZI_NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespaceenv: - name: STRIMZI_NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespaceCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
STRIMZI_FULL_RECONCILIATION_INTERVAL_MS - 可选,默认为 120000 ms。定期协调之间的间隔,以毫秒为单位。
STRIMZI_OPERATION_TIMEOUT_MS- 可选,默认为 300000 ms。内部操作的超时,以毫秒为单位。当在常规 OpenShift 操作需要比平时更长的集群中使用 AMQ Streams 时,这个值应该会增加(例如,因为 Docker 镜像下载速度较慢)。
STRIMZI_KAFKA_IMAGES-
必需。这提供了从 Kafka 版本到相应 Docker 镜像的映射,其中包含该版本的 Kafka 代理。所需语法为空格或用逗号分开的
<version>=<image>对。例如2.5.0=registry.redhat.io/amq7/amq-streams-kafka-25-rhel7:1.6.7, 2.6.0=registry.redhat.io/amq7/amq-streams-kafka-26-rhel7:1.6.7。这在指定了Kafka.spec.kafka.version属性而不是Kafka.spec.kafka.image时使用,如 第 2.1.18 节 “容器镜像” 所述。 STRIMZI_DEFAULT_KAFKA_INIT_IMAGE-
可选,默认
registry.redhat.io/amq7/amq-streams-rhel7-operator:1.6.7。如果没有将镜像指定为 第 2.1.18 节 “容器镜像” 中的 kafka-init-image,则在代理之前启动的 init 容器的镜像名称(即机架支持)没有指定为kafka-init-image。 STRIMZI_KAFKA_CONNECT_IMAGES-
必需。这提供了从 Kafka 版本到相应 Docker 镜像的映射,其中包含该版本的 Kafka 连接。所需语法为空格或用逗号分开的
<version>=<image>对。例如2.5.0=registry.redhat.io/amq7/amq-streams-kafka-25-rhel7:1.6.7, 2.6.0=registry.redhat.io/amq7/amq-streams-kafka-26-rhel7:1.6.7。这在指定了KafkaConnect.spec.version属性而不是KafkaConnect.spec.image时使用,如 第 B.1.6 节 “镜像” 所述。 STRIMZI_KAFKA_CONNECT_S2I_IMAGES-
必需。这提供了从 Kafka 版本到相应 Docker 镜像的映射,其中包含该版本的 Kafka 连接。所需语法为空格或用逗号分开的
<version>=<image>对。例如2.5.0=registry.redhat.io/amq7/amq-streams-kafka-25-rhel7:1.6.7, 2.6.0=registry.redhat.io/amq7/amq-streams-kafka-26-rhel7:1.6.7。这在指定KafkaConnectS2I.spec.version属性而不是KafkaConnectS2I.spec.image时使用,如 第 B.1.6 节 “镜像” 所述。 STRIMZI_KAFKA_MIRROR_MAKER_IMAGES-
必需。这提供了从 Kafka 版本到相应 Docker 镜像的映射,其中包含该版本的 Kafka 镜像制作器。所需语法为空格或用逗号分开的
<version>=<image>对。例如2.5.0=registry.redhat.io/amq7/amq-streams-kafka-25-rhel7:1.6.7, 2.6.0=registry.redhat.io/amq7/amq-streams-kafka-26-rhel7:1.6.7。这在指定了KafkaMirrorMaker.spec.version属性而不是KafkaMirrorMaker.spec.image时使用,如 第 B.1.6 节 “镜像” 所述。 STRIMZI_DEFAULT_TOPIC_OPERATOR_IMAGE-
可选,默认
registry.redhat.io/amq7/amq-streams-rhel7-operator:1.6.7。部署主题 Operator 时要使用的镜像名称,如果没有在 Kafka资源第 2.1.18 节 “容器镜像” 中指定为Kafka.spec.entityOperator.topicOperator.image镜像名称。 STRIMZI_DEFAULT_USER_OPERATOR_IMAGE-
可选,默认
registry.redhat.io/amq7/amq-streams-rhel7-operator:1.6.7。部署用户 Operator 时要使用的镜像名称,如果没有在 Kafka资源第 2.1.18 节 “容器镜像” 中指定为Kafka.spec.entityOperator.userOperator.image镜像。 STRIMZI_DEFAULT_TLS_SIDECAR_ENTITY_OPERATOR_IMAGE-
Optional, default
registry.redhat.io/amq7/amq-streams-kafka-26-rhel7:1.6.7.部署 sidecar 容器时要使用的镜像名称,该容器为 Entity Operator 提供 TLS 支持,如果没有将镜像指定为 第 2.1.18 节 “容器镜像” 中的Kafka.spec.entityOperator.tlsSidecar.image。 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 包含从中提取容器镜像的容器注册表的凭据。secret 在imagePullSecrets字段中用于 Cluster Operator 创建的所有Pod。更改此列表会导致所有 Kafka、Kafka Connect 和 Kafka MirrorMaker 集群进行滚动更新。 STRIMZI_KUBERNETES_VERSION可选。覆盖从 API 服务器检测到的 OpenShift 版本信息。请参见以下示例:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow KUBERNETES_SERVICE_DNS_DOMAIN可选。覆盖默认的 OpenShift DNS 域名后缀。
默认情况下,OpenShift 集群中分配的服务的 DNS 域名使用默认的后缀
cluster.local。例如,对于代理 kafka-0 :
<cluster-name>-kafka-0.<cluster-name>-kafka-brokers.<namespace>.svc.cluster.local
<cluster-name>-kafka-0.<cluster-name>-kafka-brokers.<namespace>.svc.cluster.localCopy to Clipboard Copied! Toggle word wrap Toggle overflow DNS 域名被添加到用于主机名验证的 Kafka 代理证书中。
如果您在集群中使用不同的 DNS 域名后缀,请将
KUBERNETES_SERVICE_DNS_DOMAIN环境变量从默认值改为您用来与 Kafka 代理建立连接的变量。
通过 ConfigMap 配置
Cluster Operator 的日志记录由 strimzi-cluster-operator ConfigMap 配置。
安装 Cluster Operator 时会创建一个包含日志配置的 ConfigMap。此 ConfigMap 在文件 install/cluster-operator/050-ConfigMap-strimzi-cluster-operator.yaml 中描述。您可以通过更改此 ConfigMap 中的 data 字段 log4j2.properties 来配置 Cluster Operator 日志。
要更新日志记录配置,您可以编辑 050-ConfigMap-strimzi-cluster-operator.yaml 文件,然后运行以下命令:
oc apply -f install/cluster-operator/050-ConfigMap-strimzi-cluster-operator.yaml
oc apply -f install/cluster-operator/050-ConfigMap-strimzi-cluster-operator.yaml
或者,直接编辑 ConfigMap:
oc edit cm strimzi-cluster-operator
oc edit cm strimzi-cluster-operator
要更改重新加载间隔的频率,请在创建的 ConfigMap 中的 monitorInterval 选项中设置一个时间(以秒为单位)。
如果在部署 Cluster Operator 时缺少 ConfigMap,则会使用默认的日志记录值。
如果在部署 Cluster Operator 后意外删除 ConfigMap,则会使用最新载入的日志配置。创建新 ConfigMap 以 加载新的日志配置。
不要从 ConfigMap 中删除 monitorInterval 选项。
5.1.1.1. 定期协调 复制链接链接已复制到粘贴板!
虽然 Cluster Operator 会响应从 OpenShift 集群收到所需集群资源的所有通知,但如果操作器没有运行,或者因任何原因未收到通知,则所需的资源将与正在运行的 OpenShift 集群的状态保持同步。
为了正确处理故障切换,由 Cluster Operator 执行定期协调过程,以便它可以将所需资源的状态与当前集群部署进行比较,以便在所有这些部署中保持一致状态。您可以使用 [STRIMZI_FULL_RECONCILIATION_INTERVAL_MS] 变量为定期协调设置时间间隔。
5.1.2. 调配基于角色的访问控制(RBAC) 复制链接链接已复制到粘贴板!
要使 Cluster Operator 正常工作,需要在 OpenShift 集群中与资源(如 Kafka、Kafka Connect 等)以及受管资源(如 ConfigMap、Pod、 Deployment、 StatefulSet 和 Services )交互。这种权限在 OpenShift 基于角色的访问控制(RBAC)资源中描述:
-
ServiceAccount, -
角色和ClusterRole, -
rolebinding 和ClusterRoleBinding。
除了使用 ClusterRoleBinding 在其自身 ServiceAccount 中运行外,Cluster Operator 还为需要访问 OpenShift 资源的组件管理一些 RBAC 资源。
OpenShift 还包含特权升级保护,可防止在一个 ServiceAccount 下操作的组件授予授予授权 ServiceAccount 没有的其他 特权。因为 Cluster Operator 必须能够创建 ServiceAccount sClusterRoleBindings,以及它管理的资源所需的 RoleBindings,所以 Cluster Operator 还必须具有相同的权限。
5.1.2.1. 委派的权限 复制链接链接已复制到粘贴板!
当 Cluster Operator 为所需的 Kafka 资源部署资源时,它还会创建 ServiceAccount、 RoleBindings 和 ClusterRoleBindings,如下所示:
Kafka 代理 pod 使用一个名为
cluster-name-kafka的ServiceAccount-
使用机架功能时,
strimzi-cluster-name-kafka-initClusterRoleBinding用来通过ClusterRole(名为strimzi-kafka-broker)对集群中的节点授予这个ServiceAccount访问权限 - 当不使用机架功能时,不会创建绑定
-
使用机架功能时,
-
ZooKeeper pod 使用名为
cluster-name-zookeeper的ServiceAccount Entity Operator pod 使用名为
cluster-name-entity-operator的ServiceAccount-
Topic Operator 生成带有状态信息的 OpenShift 事件,因此
ServiceAccount绑定到名为strimzi-entity-operator的ClusterRole,它通过strimzi-entity-operatorRoleBinding授予此访问权限
-
Topic Operator 生成带有状态信息的 OpenShift 事件,因此
-
KafkaConnect 和资源的 pod 使用名为KafkaConnectS2Icluster-name-cluster-connect的ServiceAccount -
KafkaMirrorMaker的 pod 使用名为cluster-name-mirror-maker的ServiceAccount -
KafkaMirrorMaker2的 pod 使用名为cluster-name-mirrormaker2的ServiceAccount -
KafkaBridge的 pod 使用名为cluster-name-bridge的ServiceAccount
5.1.2.2. ServiceAccount 复制链接链接已复制到粘贴板!
Cluster Operator 最好使用 ServiceAccount 运行:
Cluster Operator 的 ServiceAccount 示例
然后,Operator 的 Deployment 需要在其 spec.template.spec.serviceAccountName 中指定 :
Cluster Operator 部署 的部分示例
注意 12 行,其中 strimzi-cluster-operator ServiceAccount 指定为 serviceAccountName。
5.1.2.3. ClusterRoles 复制链接链接已复制到粘贴板!
Cluster Operator 需要使用 提供所需资源访问的 ClusterRole 运行。根据 OpenShift 集群设置,可能需要集群管理员来创建 ClusterRole。
集群管理员权限只在创建 ClusterRole 时需要。Cluster Operator 不会在集群管理员帐户下运行。
ClusterRole 遵循最小 权限, 仅包含 Cluster Operator 运行 Kafka、Kafka Connect 和 ZooKeeper 集群所需的权限。第一组分配的权限允许 Cluster Operator 管理 OpenShift 资源,如 StatefulSets、Deployment、Pod 和 ConfigMap。
Cluster Operator 使用 ClusterRole 在命名空间范围的资源级别和集群范围的资源级别授予权限:
具有 Cluster Operator 资源命名空间资源的 ClusterRole
第二个包括集群范围资源所需的权限。
为 Cluster Operator 带有集群范围资源的 ClusterRole
The strimzi-kafka-broker ClusterRole 代表 Kafka pod 中 init 容器所需的访问权限,用于机架功能。如 委派的特权 部分所述,Cluster Operator 还需要此角色才能委派此访问权限。
Cluster Operator 的 ClusterRole,允许它将 OpenShift 节点的访问权限委派给 Kafka 代理 pod
The strimzi-topic-operator ClusterRole 代表 Topic Operator 所需的访问权限。如 委派的特权 部分所述,Cluster Operator 还需要此角色才能委派此访问权限。
Cluster Operator 的 ClusterRole,允许它将对事件的访问委托给主题 Operator
The strimzi-kafka-client ClusterRole 代表组件所需的访问,这些客户端使用客户端机架感知能力。如 委派的特权 部分所述,Cluster Operator 还需要此角色才能委派此访问权限。
Cluster Operator 的 ClusterRole,允许它将对 OpenShift 节点的访问委托给基于 Kafka 客户端的 pod
5.1.2.4. ClusterRoleBindings 复制链接链接已复制到粘贴板!
Operator 需要 ClusterRoleBindings 和 RoleBindings,它们将其 ClusterRole 与其 ServiceAccount 相关联:包含集群范围资源的 ClusterRole 需要 ClusterRoleBinding。
Cluster Operator 的 ClusterRoleBinding 示例
委派 所需的 ClusterRole 还需要 ClusterRoleBinding :
Kafka 代理 rack-awarness 的 Cluster Operator 的 Cluster RoleBinding 示例
和
Kafka 客户端 rack-awarness 的 Cluster Operator 的 Cluster RoleBinding 示例
仅 包含有命名空间资源的 ClusterRole 只会使用 RoleBindings 绑定。