diff options
| author | Kubernetes Prow Robot <k8s-ci-robot@users.noreply.github.com> | 2021-11-21 07:57:00 -0800 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2021-11-21 07:57:00 -0800 |
| commit | 36811ea138d1c2edd40df3625efaacceeae6bf1b (patch) | |
| tree | 6dcdfe163447dc0fb6bdf823250d5fa5f52c304b | |
| parent | a3e061811d9fc4dcaaa1258b638c8d92eef03f0e (diff) | |
| parent | 80764617017b441bf32490cc548e2694fcbaf89c (diff) | |
Merge pull request #6238 from ehashman/feature-gate-docs
Document expectations of feature gate use per PRR
| -rw-r--r-- | contributors/devel/sig-architecture/feature-gates.md | 10 |
1 files changed, 10 insertions, 0 deletions
diff --git a/contributors/devel/sig-architecture/feature-gates.md b/contributors/devel/sig-architecture/feature-gates.md index 2ee71bfd..f18eb0ef 100644 --- a/contributors/devel/sig-architecture/feature-gates.md +++ b/contributors/devel/sig-architecture/feature-gates.md @@ -12,6 +12,16 @@ The majority of features will go through all three stages, but occasionally ther 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). +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. + +Unless an exception is granted for a particular feature, as documented and approved as part of [Production Readiness Review], it is expected that: + +- Toggling a feature gate will not affect other components, i.e. disabling a feature gate in the API server will work independently of disabling that same feature gate in the kubelet or scheduler, and no coordination between components is needed. +- The effects of toggling a feature gate should be limited to the scope of the feature. Enabling or disabling a feature gate should not affect workloads that do not use the feature gate. +- Toggling feature gates should not result in fanout effects or cascading interactions in a cluster. + +[Production Readiness Review]: /sig-architecture/production-readiness.md + ## Specification Fields // Default is the default enablement state for the feature. Possible values are true/false. Default bool |