Merge pull request #30003 from jlowdermilk/config-proposal

Automatic merge from submit-queue

component feature config proposal

This adds a proposal for a simple mechanism to pass runtime config to kube system components. Motivation is to have a consistent way to toggle new features that are not tied to an API group. Feedback appreciated

@mikedanese @lavalamp @kubernetes/sig-api-machinery @kubernetes/sig-cluster-lifecycle @kubernetes/sig-node

<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.kubernetes.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.kubernetes.io/reviews/kubernetes/kubernetes/30003)
<!-- Reviewable:end -->

1 files changed, 98 insertions, 0 deletions

diff --git a/runtimeconfig.md b/runtimeconfig.md
new file mode 100644
index 00000000..18cf4eb4
--- /dev/null
+++ b/runtimeconfig.md
@@ -0,0 +1,98 @@
+<!-- BEGIN MUNGE: UNVERSIONED_WARNING -->
+
+<!-- BEGIN STRIP_FOR_RELEASE -->
+
+<img src="http://kubernetes.io/kubernetes/img/warning.png" alt="WARNING"
+     width="25" height="25">
+<img src="http://kubernetes.io/kubernetes/img/warning.png" alt="WARNING"
+     width="25" height="25">
+<img src="http://kubernetes.io/kubernetes/img/warning.png" alt="WARNING"
+     width="25" height="25">
+<img src="http://kubernetes.io/kubernetes/img/warning.png" alt="WARNING"
+     width="25" height="25">
+<img src="http://kubernetes.io/kubernetes/img/warning.png" alt="WARNING"
+     width="25" height="25">
+
+<h2>PLEASE NOTE: This document applies to the HEAD of the source tree</h2>
+
+If you are using a released version of Kubernetes, you should
+refer to the docs that go with that version.
+
+Documentation for other releases can be found at
+[releases.k8s.io](http://releases.k8s.io).
+</strong>
+--
+
+<!-- END STRIP_FOR_RELEASE -->
+
+<!-- END MUNGE: UNVERSIONED_WARNING -->
+
+# Overview
+
+Proposes adding a `--feature-config` to core kube system components:
+apiserver , scheduler, controller-manager, kube-proxy, and selected addons.
+This flag will be used to enable/disable alpha features on a per-component basis.
+
+## Motivation
+
+Motivation is enabling/disabling features that are not tied to
+an API group. API groups can be selectively enabled/disabled in the
+apiserver via existing `--runtime-config` flag on apiserver, but there is
+currently no mechanism to toggle alpha features that are controlled by
+e.g. annotations. This means the burden of controlling whether such
+features are enabled in a particular cluster is on feature implementors;
+they must either define some ad hoc mechanism for toggling (e.g. flag
+on component binary) or else toggle the feature on/off at compile time.
+
+By adding a`--feature-config` to all kube-system components, alpha features
+can be toggled on a per-component basis by passing `enableAlphaFeature=true|false`
+to `--feature-config` for each component that the feature touches.
+
+## Design
+
+The following components will all get a `--feature-config` flag,
+which loads a `config.ConfigurationMap`:
+
+- kube-apiserver
+- kube-scheduler
+- kube-controller-manager
+- kube-proxy
+- kube-dns
+
+(Note kubelet is omitted, it's dynamic config story is being addressed
+by #29459). Alpha features that are not accessed via an alpha API
+group should define an `enableFeatureName` flag and use it to toggle
+activation of the feature in each system component that the feature
+uses.
+
+## Suggested conventions
+
+This proposal only covers adding a mechanism to toggle features in
+system components. Implementation details will still depend on the alpha
+feature's owner(s). The following are suggested conventions:
+
+- Naming for feature config entries should follow the pattern
+  "enable<FeatureName>=true".
+- Features that touch multiple components should reserve the same key
+  in each component to toggle on/off.
+- Alpha features should be disabled by default. Beta features may
+  be enabled by default. Refer to docs/devel/api_changes.md#alpha-beta-and-stable-versions
+  for more detailed guidance on alpha vs beta.
+
+## Upgrade support
+
+As the primary motivation for cluster config is toggling alpha
+features, upgrade support is not in scope. Enabling or disabling
+a feature is necessarily a breaking change, so config should
+not be altered in a running cluster.
+
+## Future work
+
+1. The eventual plan is for component config to be managed by versioned
+APIs and not flags (#12245). When that is added, toggling of features
+could be handled by versioned component config and the component flags
+deprecated.
+
+<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
+[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/runtimeconfig.md?pixel)]()
+<!-- END MUNGE: GENERATED_ANALYTICS -->