You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: contributors/devel/sig-architecture/feature-gates.md
+21-9Lines changed: 21 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,13 +6,13 @@ Feature gates are intended to cover the development life cycle of a feature - th
6
6
7
7
## Lifecycle
8
8
9
-
Feature progress through `Alpha` -> `Beta` -> `GA`. Sometimes we end up deciding that a feature is not going to be supported and we end up marking them as `Deprecated`.
9
+
Features generally progress through `Alpha` -> `Beta` -> `GA`. Sometimes we end up deciding that a feature is not going to be supported and we end up marking them as `Deprecated`.
10
10
11
11
The majority of features will go through all three stages, but occasionally there are features which may skip stages.
12
12
13
13
When we add a feature flag, we basically add if/else conditions to ensure that a feature is ONLY activated when either the default is on or if the deployer has switched it on explicitly. When a feature gate is disabled, the system should behave as if the feature doesn't exist. The only exception to this is [API input validation](https://kubernetes.io/docs/reference/using-api/deprecation-policy/#deprecating-parts-of-the-api) on updates, which should preserve and validate data if and only if it was present before the update (which could occur in case of a version rollback).
14
14
15
-
There is no supported way to trigger a feature gate at runtime for production Kubernetes use. A feature gate is typically toggled by a component restart.
15
+
There is no supported way to change a feature gate at runtime for production Kubernetes use. A feature gate is typically toggled by a component restart.
16
16
17
17
Unless an exception is granted for a particular feature, as documented and approved as part of [Production Readiness Review], it is expected that:
18
18
@@ -39,37 +39,49 @@ Unless an exception is granted for a particular feature, as documented and appro
39
39
*`Default` is always set to `false`
40
40
*`LockToDefault` is not set. Defaults to `false`
41
41
42
-
By default it is not switched on. This enables folks to switch on the feature using the command line. All API changes must start with an Alpha gate, which makes it possible to rollback from future versions.
42
+
By default Alpha features are not switched on. This enables folks to switch on the feature using the command line. All API changes must start with an Alpha gate, which makes it possible to rollback from future versions.
43
43
44
44
## Beta Features
45
45
46
46
*`PreRelease` is set to `featuregate.Beta`
47
47
*`Default` is usually set to `true` (see below)
48
48
*`LockToDefault` is not set. Defaults to `false`
49
49
50
-
This enables the feature to be on and available in the default installation of Kubernetes.
50
+
Beta features are usually on by default. This enables the feature to be available in the default installation of Kubernetes.
51
51
52
-
Sometimes (rarely) the `Default` is set to `false`. This tells folks that while this feature is in Beta, they will still need to do some work to switch it on and use it and potentially take some other explicit action outside of Kubernetes. For example, see the [CSIMigration feature gates](https://github.com/kubernetes/kubernetes/blob/5b0a2c3a29f6b5392e0f8f94ba5669bdc9eb73f6/pkg/features/kube_features.go#L792).
52
+
Sometimes (rarely) the `Default` is set to `false` in Beta. This tells folks that while this feature is Beta, they will still need to do some work to switch it on and use it, and potentially take some other explicit action outside of Kubernetes. For example, the CSIMigration feature gates looked like this:
CSIMigrationGCE: {Default: false, PreRelease: featuregate.Beta}, // Off by default (requires GCE PD CSI Driver)
57
+
CSIMigrationAWS: {Default: false, PreRelease: featuregate.Beta}, // Off by default (requires AWS EBS CSI driver)
58
+
CSIMigrationAzureDisk: {Default: false, PreRelease: featuregate.Beta}, // Off by default (requires Azure Disk CSI driver)
59
+
CSIMigrationAzureFile: {Default: false, PreRelease: featuregate.Beta}, // Off by default (requires Azure File CSI driver)
60
+
CSIMigrationvSphere: {Default: false, PreRelease: featuregate.Beta}, // Off by default (requires vSphere CSI driver)
61
+
```
53
62
54
63
## GA Features
55
64
56
65
*`PreRelease` is set to `featuregate.GA`
57
66
*`Default` is always set to `true`
58
67
*`LockToDefault` is set to `true`
59
68
60
-
GA features are always on.
69
+
GA features are always on by default, and usually cannot be disabled.
61
70
62
-
Sometimes (rarely) we do not set `LockToDefault`and let it default to `false`. This enables folks to switch off the GA feature. We do this to tell folks that while the feature (for example `coredns`) is GA, they need to move off say `kubedns` to `coredns` in their infrastructures pretty soon and if they want to continue `kubedns` for a short time, they will have to switch off the GA flag. When we do remove the support for `kubedns` entirely we would set `LockToDefault` to `true` with some grace period for the transition.
71
+
Sometimes (rarely) we do not set `LockToDefault`(thus defaulting to `false`, meaning "not locked"). This enables folks to switch off the GA feature. We do this to indicate that while the feature (for example `coredns`) is GA, they need to move off `kubedns` to `coredns` in their infrastructure. If they want to continue using `kubedns` for a short time, they can choose to switch off the GA flag. When we eventually remove the support for `kubedns` entirely we would set `LockToDefault` to `true` with some grace period for the transition.
63
72
64
-
[After at least two releases post-GA and deprecation](https://kubernetes.io/docs/reference/using-api/deprecation-policy/#deprecation), the feature gate is removed. Typically, we add a comment in [kubefeatures.go](https://github.com/kubernetes/kubernetes/blob/master/pkg/features/kube_features.go) such as: `// remove in 1.23` to signal when we plan to remove the feature gate. Remember when the feature gate is removed and the deployer has forgotten to drop the reference to the feature in the CLI flags (say the `kube-apiserver`), then they will see a hard failure.
73
+
[After at least two releases post-GA and deprecation](https://kubernetes.io/docs/reference/using-api/deprecation-policy/#deprecation), the feature gate is removed. Typically, we add a comment in [kubefeatures.go](https://github.com/kubernetes/kubernetes/blob/master/pkg/features/kube_features.go) such as: `// remove in 1.23` to signal when we plan to remove the feature gate. Remember when the feature gate is removed and the deployer has forgotten to drop the reference to the feature in the CLI flags (say the `kube-apiserver`), then they will see a hard failure.
65
74
66
-
Also note that when we set `LockToDefault` to `true`, we remove all references (if/then conditions) to the feature gate from the codebase.
75
+
Also note that when we set `LockToDefault` to `true`, we remove all references (if/then conditions) to the feature gate from the codebase.
67
76
68
77
## Deprecation
69
78
70
79
*`PreRelease` is set to `featuregate.Deprecated`
80
+
*`Default` is set to `false`
71
81
* See [Kubernetes Deprecation Policy](https://kubernetes.io/docs/reference/using-api/deprecation-policy/#deprecation) for more details
72
82
83
+
Very rarely we will deprecate some aspect of Kubernetes (almost always something that has no actual impact). When we do that, the pattern is to name the gate so it describes the functionality being deprecated and to default the value to `false`. If some user is impacted by the deprecation, they can set that gate to `true` to unbreak themselves (and then file a bug). If this happens, we must reconsider the deprecation and may choose to abandon it entirely by changing the gate back to `true` for a release or two and eventually removing it.
84
+
73
85
## Other scenarios
74
86
75
87
Sometimes we use`{Default: true, PreRelease: featuregate.Beta}` for keeping legacy behavior on while a new alternative is being implemented. When the new default behavior is transitioning to GA and it is time to drop the old legacy behavior, we will end up with `{Default: false, PreRelease: featuregate.GA, LockToDefault: true}`. For an example, see: [LegacyNodeRoleBehavior & ServiceNodeExclusion](https://github.com/kubernetes/kubernetes/pull/97543/files).
0 commit comments