Chapter 7. Feature gates

The ControlPlaneListener feature gate separates listeners for data replication and coordination:

The ServiceAccountPatching feature gate ensures that the Cluster Operator always reconciles service accounts and updates them when needed. For example, when you change service account labels or annotations using the template property of a custom resource, the operator automatically updates them on the existing service account resources.

The UseStrimziPodSets feature gate introduced the StrimziPodSet custom resource for managing Kafka and ZooKeeper pods, replacing the use of OpenShift StatefulSet resources.

The StableConnectIdentities feature gate introduced the StrimziPodSet custom resource for managing Kafka Connect and Kafka MirrorMaker 2 pods, replacing the use of OpenShift Deployment resources.

StrimziPodSet resources give the pods stable names and stable addresses, which do not change during rolling upgrades, replacing the use of OpenShift Deployment resources.

The UseKRaft feature gate has a default state of enabled.

The UseKRaft feature gate deploys a Kafka cluster in KRaft (Kafka Raft metadata) mode without ZooKeeper. ZooKeeper and KRaft are mechanisms used to manage metadata and coordinate operations in Kafka clusters. KRaft mode eliminates the need for an external coordination service like ZooKeeper. In KRaft mode, Kafka nodes take on the roles of brokers, controllers, or both. They collectively manage the metadata, which is replicated across partitions. Controllers are responsible for coordinating operations and maintaining the cluster’s state.

Using the UseKRaft feature gate requires the KafkaNodePools feature gate to be enabled as well. To deploy a Kafka cluster in KRaft mode, you must use the KafkaNodePool resources. For more details and examples, see Section 6.3.1, “Deploying a Kafka cluster with node pools”. The Kafka custom resource using KRaft mode must also have the annotation strimzi.io/kraft="enabled".

Currently, the KRaft mode in Streams for Apache Kafka has the following major limitations:

The KafkaNodePools feature gate has a default state of enabled.

The KafkaNodePools feature gate introduces a new KafkaNodePool custom resource that enables the configuration of different pools of Apache Kafka nodes.

A node pool refers to a distinct group of Kafka nodes within a Kafka cluster. Each pool has its own unique configuration, which includes mandatory settings such as the number of replicas, storage configuration, and a list of assigned roles. You can assign the controller role, broker role, or both roles to all nodes in the pool in the .spec.roles field. When used with a ZooKeeper-based Apache Kafka cluster, it must be set to the broker role. When used with the UseKRaft feature gate, it can be set to broker, controller, or both.

In addition, a node pool can have its own configuration of resource requests and limits, Java JVM options, and resource templates. Configuration options not set in the KafkaNodePool resource are inherited from the Kafka custom resource.

The KafkaNodePool resources use a strimzi.io/cluster label to indicate to which Kafka cluster they belong. The label must be set to the name of the Kafka custom resource.

Examples of the KafkaNodePool resources can be found in the example configuration files provided by Streams for Apache Kafka.

The UnidirectionalTopicOperator feature gate has a default state of enabled.

The UnidirectionalTopicOperator feature gate introduces a unidirectional topic management mode for creating Kafka topics using the KafkaTopic resource. Unidirectional mode is compatible with using KRaft for cluster management. With unidirectional mode, you create Kafka topics using the KafkaTopic resource, which are then managed by the Topic Operator. Any configuration changes to a topic outside the KafkaTopic resource are reverted. For more information on topic management, see Section 10.1, “Topic management modes”.