1.2. Streams for Apache Kafka operators


Streams for Apache Kafka operators are purpose-built with specialist operational knowledge to effectively manage Kafka on OpenShift. Each operator performs a distinct function.

Cluster Operator
The Cluster Operator handles the deployment and management of Apache Kafka clusters on OpenShift. It automates the setup of Kafka brokers, and other Kafka components and resources.
Topic Operator
The Topic Operator manages the creation, configuration, and deletion of topics within Kafka clusters.
User Operator
The User Operator manages Kafka users that require access to Kafka brokers.

When you deploy Streams for Apache Kafka, you first deploy the Cluster Operator. The Cluster Operator is then ready to handle the deployment of Kafka. You can also deploy the Topic Operator and User Operator using the Cluster Operator (recommended) or as standalone operators. You would use a standalone operator with a Kafka cluster that is not managed by the Cluster Operator.

The Topic Operator and User Operator are part of the Entity Operator. The Cluster Operator can deploy one or both operators based on the Entity Operator configuration.

重要

To deploy the standalone operators, you need to set environment variables to connect to a Kafka cluster. These environment variables do not need to be set if you are deploying the operators using the Cluster Operator as they will be set by the Cluster Operator.

Operators watch and manage Streams for Apache Kafka resources in OpenShift namespaces. The Cluster Operator can watch a single namespace, multiple namespaces, or all namespaces in an OpenShift cluster. The Topic Operator and User Operator can watch a single namespace.

  • The Cluster Operator watches for Kafka resources
  • The Topic Operator watches for KafkaTopic resources
  • The User Operator watches for KafkaUser resources

The Topic Operator and the User Operator can only watch a single Kafka cluster in a namespace. And they can only be connected to a single Kafka cluster.

If multiple Topic Operators watch the same namespace, name collisions and topic deletion can occur. This is because each Kafka cluster uses Kafka topics that have the same name (such as __consumer_offsets). Make sure that only one Topic Operator watches a given namespace.

When using multiple User Operators with a single namespace, a user with a given username can exist in more than one Kafka cluster.

If you deploy the Topic Operator and User Operator using the Cluster Operator, they watch the Kafka cluster deployed by the Cluster Operator by default. You can also specify a namespace using watchedNamespace in the operator configuration.

For a standalone deployment of each operator, you specify a namespace and connection to the Kafka cluster to watch in the configuration.

1.2.2. Managing RBAC resources

The Cluster Operator creates and manages role-based access control (RBAC) resources for Streams for Apache Kafka components that need access to OpenShift resources.

For the Cluster Operator to function, it needs permission within the OpenShift cluster to interact with Kafka resources, such as Kafka and KafkaConnect, as well as managed resources like ConfigMap, Pod, Deployment, and Service.

Permission is specified through the following OpenShift RBAC resources:

  • ServiceAccount
  • Role and ClusterRole
  • RoleBinding and ClusterRoleBinding

The Cluster Operator runs under a service account called strimzi-cluster-operator. It is assigned cluster roles that give it permission to create the RBAC resources for Streams for Apache Kafka components. Role bindings associate the cluster roles with the service account.

OpenShift prevents components operating under one ServiceAccount from granting another ServiceAccount privileges that the granting ServiceAccount does not have. Because the Cluster Operator creates the RoleBinding and ClusterRoleBinding RBAC resources needed by the resources it manages, it requires a role that gives it the same privileges.

The following sections describe the RBAC resources required by the Cluster Operator.

1.2.2.2. ClusterRole resources

The Cluster Operator uses ClusterRole resources to provide the necessary access to resources. Depending on the OpenShift cluster setup, a cluster administrator might be needed to create the cluster roles.

注意

Cluster administrator rights are only needed for the creation of ClusterRole resources. The Cluster Operator will not run under a cluster admin account.

The RBAC resources follow the principle of least privilege and contain only those privileges needed by the Cluster Operator to operate the cluster of the Kafka component.

All cluster roles are required by the Cluster Operator in order to delegate privileges.

Expand
表 1.3. ClusterRole resources
NameDescription

strimzi-cluster-operator-namespaced

Access rights for namespace-scoped resources used by the Cluster Operator to deploy and manage the operands.

strimzi-cluster-operator-global

Access rights for cluster-scoped resources used by the Cluster Operator to deploy and manage the operands.

strimzi-cluster-operator-leader-election

Access rights used by the Cluster Operator for leader election.

strimzi-cluster-operator-watched

Access rights used by the Cluster Operator to watch and manage the Streams for Apache Kafka custom resources.

strimzi-kafka-broker

Access rights to allow Kafka brokers to get the topology labels from OpenShift worker nodes when rack-awareness is used.

strimzi-entity-operator

Access rights used by the Topic and User Operators to manage Kafka users and topics.

strimzi-kafka-client

Access rights to allow Kafka Connect, MirrorMaker (1 and 2), and Kafka Bridge to get the topology labels from OpenShift worker nodes when rack-awareness is used.

1.2.2.3. ClusterRoleBinding resources

The Cluster Operator uses ClusterRoleBinding and RoleBinding resources to associate its ClusterRole with its ServiceAccount. Cluster role bindings are required by cluster roles containing cluster-scoped resources.

Expand
表 1.4. ClusterRoleBinding resources
NameDescription

strimzi-cluster-operator

Grants the Cluster Operator the rights from the strimzi-cluster-operator-global cluster role.

strimzi-cluster-operator-kafka-broker-delegation

Grants the Cluster Operator the rights from the strimzi-entity-operator cluster role.

strimzi-cluster-operator-kafka-client-delegation

Grants the Cluster Operator the rights from the strimzi-kafka-client cluster role.

Expand
表 1.5. RoleBinding resources
NameDescription

strimzi-cluster-operator

Grants the Cluster Operator the rights from the strimzi-cluster-operator-namespaced cluster role.

strimzi-cluster-operator-leader-election

Grants the Cluster Operator the rights from the strimzi-cluster-operator-leader-election cluster role.

strimzi-cluster-operator-watched

Grants the Cluster Operator the rights from the strimzi-cluster-operator-watched cluster role.

strimzi-cluster-operator-entity-operator-delegation

Grants the Cluster Operator the rights from the strimzi-cluster-operator-entity-operator-delegation cluster role.

1.2.2.4. ServiceAccount resources

The Cluster Operator runs using the strimzi-cluster-operator ServiceAccount. This service account grants it the privileges it requires to manage the operands. The Cluster Operator creates additional ClusterRoleBinding and RoleBinding resources to delegate some of these RBAC rights to the operands.

Each of the operands uses its own service account created by the Cluster Operator. This allows the Cluster Operator to follow the principle of least privilege and give the operands only the access rights that are really need.

Expand
表 1.6. ServiceAccount resources
NameUsed by

<cluster_name>-zookeeper

ZooKeeper pods

<cluster_name>-kafka

Kafka broker pods

<cluster_name>-entity-operator

Entity Operator

<cluster_name>-cruise-control

Cruise Control pods

<cluster_name>-kafka-exporter

Kafka Exporter pods

<cluster_name>-connect

Kafka Connect pods

<cluster_name>-mirror-maker

MirrorMaker pods

<cluster_name>-mirrormaker2

MirrorMaker 2 pods

<cluster_name>-bridge

Kafka Bridge pods

1.2.3. Managing pod resources

The StrimziPodSet custom resource is used by Streams for Apache Kafka to create and manage Kafka, Kafka Connect, and MirrorMaker 2 pods. If you are using ZooKeeper, ZooKeeper pods are also created and managed using StrimziPodSet resources.

You must not create, update, or delete StrimziPodSet resources. The StrimziPodSet custom resource is used internally and resources are managed solely by the Cluster Operator. As a consequence, the Cluster Operator must be running properly to avoid the possibility of pods not starting and Kafka clusters not being available.

注意

OpenShift Deployment resources are used for creating and managing the pods of other components: Kafka Bridge, Kafka Exporter, Cruise Control, (deprecated) MirrorMaker 1, User Operator and Topic Operator.

Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

关于红帽文档

Legal Notice

Theme

© 2026 Red Hat
返回顶部