Chapter 8. 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 KafkaNodePools feature gate introduced 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 using the .spec.roles property. When used with a ZooKeeper-based Apache Kafka cluster, it must be set to the broker role. When used with a KRaft-based Apache Kafka cluster, 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. The Kafka resource configuration must also include the strimzi.io/node-pools: enabled annotation, which is required when using node pools.

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

The UnidirectionalTopicOperator feature gate introduced 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”.

The UseKRaft feature gate introduced the KRaft (Kafka Raft metadata) mode for running Apache Kafka clusters 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. For more information on using KRraft, see Chapter 5, Using Kafka in KRaft mode.

The ContinueReconciliationOnManualRollingUpdateFailure feature gate has a default state of disabled.

The ContinueReconciliationOnManualRollingUpdateFailure feature gate allows the Cluster Operator to continue a reconciliation if the manual rolling update of the operands fails. It applies to the following operands that support manual rolling updates using the strimzi.io/manual-rolling-update annotation:

Continuing the reconciliation after a manual rolling update failure allows the operator to recover from various situations that might prevent the update from succeeding. For example, a missing Persistent Volume Claim (PVC) or Persistent Volume (PV) might cause the manual rolling update to fail. However, the PVCs and PVs are created only in a later stage of the reconciliation. By continuing the reconciliation after this failure, the process can recreate the missing PVC or PV and recover.

The ContinueReconciliationOnManualRollingUpdateFailure feature gate is used by the Cluster Operator. It is ignored by the User and Topic Operators.