第8章 Feature gates


Streams for Apache Kafka operators use feature gates to enable or disable specific features and functions. Enabling a feature gate alters the behavior of the associated operator, introducing the corresponding feature to your Streams for Apache Kafka deployment.

The purpose of feature gates is to facilitate the trial and testing of a feature before it is fully adopted. The state (enabled or disabled) of a feature gate may vary by default, depending on its maturity level.

As a feature gate graduates and reaches General Availability (GA), it transitions to an enabled state by default and becomes a permanent part of the Streams for Apache Kafka deployment. A feature gate at the GA stage cannot be disabled.

The supported feature gates are applicable to all Streams for Apache Kafka operators. While a particular feature gate might be used by one operator and ignored by the others, it can still be configured in all operators. When deploying the User Operator and Topic Operator within the context of the`Kafka` custom resource, the Cluster Operator automatically propagates the feature gates configuration to them. When the User Operator and Topic Operator are deployed standalone, without a Cluster Operator available to configure the feature gates, they must be directly configured within their deployments.

8.1. Graduated feature gates (GA)

Graduated feature gates have reached General Availability (GA) and are permanently enabled features.

8.1.1. ControlPlaneListener feature gate

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

  • Connections between the Kafka controller and brokers use an internal control plane listener on port 9090.
  • Replication of data between brokers, as well as internal connections from Streams for Apache Kafka operators, Cruise Control, or the Kafka Exporter use a replication listener on port 9091.
重要

With the ControlPlaneListener feature gate permanently enabled, direct upgrades or downgrades between Streams for Apache Kafka 1.7 and earlier and Streams for Apache Kafka 2.3 and newer are not possible. You must first upgrade or downgrade through one of the Streams for Apache Kafka versions in-between, disable the ControlPlaneListener feature gate, and then downgrade or upgrade (with the feature gate enabled) to the target version.

8.1.2. ServiceAccountPatching feature gate

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.

8.1.3. UseStrimziPodSets feature gate

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

重要

With the UseStrimziPodSets feature gate permanently enabled, direct downgrades from Streams for Apache Kafka 2.5 and newer to Streams for Apache Kafka 2.0 or earlier are not possible. You must first downgrade through one of the Streams for Apache Kafka versions in-between, disable the UseStrimziPodSets feature gate, and then downgrade to Streams for Apache Kafka 2.0 or earlier.

8.1.4. StableConnectIdentities feature gate

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.

重要

With the StableConnectIdentities feature gate permanently enabled, direct downgrades from Streams for Apache Kafka 2.7 and newer to Streams for Apache Kafka 2.3 or earlier are not possible. You must first downgrade through one of the Streams for Apache Kafka versions in-between, disable the StableConnectIdentities feature gate, and then downgrade to Streams for Apache Kafka 2.3 or earlier.

8.1.5. KafkaNodePools feature gate

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.

Downgrading from KafkaNodePools

If your cluster already uses KafkaNodePool custom resources, and you wish to downgrade to an older version of Streams for Apache Kafka that does not support them or with the KafkaNodePools feature gate disabled, you must first migrate from KafkaNodePool custom resources to managing Kafka nodes using only Kafka custom resources. For more information, see the instructions for reversing a migration to node pools.

8.1.6. UnidirectionalTopicOperator feature gate

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 「Topic management」.

8.1.7. UseKRaft feature gate

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 5章Using Kafka in KRaft mode.

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

Red Hat ドキュメントについて

Legal Notice

Theme

© 2026 Red Hat
トップに戻る