このコンテンツは選択した言語では利用できません。

Chapter 9. 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.

9.1. Feature gate releases

Feature gates have three stages of maturity:

Alpha
Alpha stage features are disabled by default.
They might be experimental or unstable, subject to change, or not sufficiently tested for production use.
Beta
Beta stage features are enabled by default, but they can be disabled if needed.
They are well tested and their functionality is not likely to change.
General Availability (GA)
GA features are always enabled and cannot be disabled.
They are stable and should not change in the future. Feature gates might be removed when they reach GA, which means that the feature was incorporated into the Streams for Apache Kafka core features.

Alpha and beta stage features are removed if they do not prove to be useful. When a feature gate reaches GA, it is permanently enabled and can no longer be disabled. The following table shows the maturity of the feature gates introduced across Streams for Apache Kafka versions.

Expand
Table 9.1. Feature gate maturity across Streams for Apache Kafka versions
Feature gateAlphaBetaGA

ControlPlaneListener

1.8

2.0

2.3

ServiceAccountPatching

1.8

2.0

2.3

UseStrimziPodSets

2.1

2.3

2.5

UseKRaft

2.2

2.7

2.8

StableConnectIdentities

2.4

2.6

2.7

KafkaNodePools

2.5

2.7

2.8

UnidirectionalTopicOperator

2.5

2.7

2.8

ContinueReconciliationOnManualRollingUpdateFailure

2.8

2.9

3.0

ServerSideApplyPhase1

3.1

-

-

9.2. Graduated feature gates (GA)

For information on feature gates that have reached GA, see the documentation for the Streams for Apache Kafka version in which they were introduced.

9.3. Stable feature gates (Beta)

Stable feature gates have reached a beta level of maturity, and are generally enabled by default for all users. Stable feature gates are production-ready, but they can still be disabled. Currently, there are no beta level feature gates.

9.4. Early access feature gates (Alpha)

Early access feature gates have not yet reached the beta stage, and are disabled by default. An early access feature gate provides an opportunity for assessment before its functionality is permanently incorporated into Streams for Apache Kafka. Currently, there are no alpha level feature gates.

9.4.1. ServerSideApplyPhase1 feature gate

The ServerSideApplyPhase1 feature gate has a default state of disabled.

When enabled, the Cluster Operator uses Server-Side Apply (SSA) for creating and updating certain resources. SSA is an OpenShift feature that provides better tracking of field ownership and more controlled resource updates. In Phase 1, Server-Side Apply is used for the following resources:

  • PersistentVolumeClaim
  • ConfigMap
  • Ingress
  • ServiceAccount
  • Service

All other resources continue to be reconciled using the existing mechanism - client-side apply. If users change the fields of operator-managed resources, the operator reverts these changes.

With SSA, the Cluster Operator modifies only the fields it manages. User changes to the other fields are preserved as long as they don’t conflict. On the first update attempt, the Cluster Operator sets force = false when applying changes, respecting user changes. If a conflict occurs in a managed field, the update is retried with force = true. The conflict and the switch to forced apply are logged by the Cluster Operator.

Ownership of individual fields is tracked through the .metadata.managedFields property of the resource being updated.

To enable the ServerSideApplyPhase1 feature gate, specify +ServerSideApplyPhase1 in the STRIMZI_FEATURE_GATES environment variable in the Cluster Operator configuration.

9.5. Enabling feature gates

To modify a feature gate’s default state, use the STRIMZI_FEATURE_GATES environment variable in the operator’s configuration. You can modify multiple feature gates using this single environment variable. Specify a comma-separated list of feature gate names and prefixes. A + prefix enables the feature gate and a - prefix disables it.

Example feature gate configuration that enables FeatureGate1 and disables FeatureGate2

env:
  - name: STRIMZI_FEATURE_GATES
    value: +FeatureGate1,-FeatureGate2
Copy to Clipboard Toggle word wrap

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

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

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

会社概要

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

Theme

© 2026 Red Hat
トップに戻る