このコンテンツは選択した言語では利用できません。
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.
| Feature gate | Alpha | Beta | GA |
|---|---|---|---|
|
| 1.8 | 2.0 | 2.3 |
|
| 1.8 | 2.0 | 2.3 |
|
| 2.1 | 2.3 | 2.5 |
|
| 2.2 | 2.7 | 2.8 |
|
| 2.4 | 2.6 | 2.7 |
|
| 2.5 | 2.7 | 2.8 |
|
| 2.5 | 2.7 | 2.8 |
|
| 2.8 | 2.9 | 3.0 |
|
| 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
env:
- name: STRIMZI_FEATURE_GATES
value: +FeatureGate1,-FeatureGate2