mirror of https://github.com/k3s-io/k3s
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 -->pull/6/head
Kubernetes Submit Queue
GitHub
commit
019b4c0e8f
|
|
@ -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 -->
|
||||||
|
[]()
|
||||||
|
<!-- END MUNGE: GENERATED_ANALYTICS -->
|
||||||
Loading…
Reference in New Issue