-
Notifications
You must be signed in to change notification settings - Fork 715
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Define upgrade path for ComponentConfig #1681
Comments
I was actually raising this exact question in the past few weeks with WG Component Standard, but so far no concrete decisions have been taken. |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
/lifecycle frozen |
like what we discussed in #1582 |
yes, unless the component start exposing a conversion path for their managed ComponentConfig API / types. |
/cc @wangyysde |
the kube-proxy v1alpha2 is planned for release in 1.31. kube-proxy has enabled the following as a migration plan, which is good:
since kubeadm runs kube-proxy as a container / DS we might have to jump a couple of additional hoops, but up-converting the already-in-cluster kube-proxy config to v1alpha2 seems doable.
i will experiment with this and provide a PR or if there are complications this can be a google doc first. |
looks like both kube-proxy and kube-scheduler support the --write-config-to flag. the kubelet does not yet |
in terms of the ticket here, IMO the upgrade path is:
|
kubeadm allow usage of component config for defining settings for kubelet and kube-proxy; component configs are stored in ConfigMaps and reused when joining nodes or doing upgrades.
However, as of today kubeadm does not yet define a procedure for upgrading component configs in the case such API change format e.g. change from
kube-proxy/config/v1alpha1
tokube-proxy/config/v1alpha2
.As an initial step, we should evaluate if this is the scope of kubeadm because it requires a certain degree of coordination across nodes (there should not be old components referring to a new/not supported component config), and this can't be achieved by kubeadm alone.
If this is the case, it should be documented what is the expected procedure higher-level tools/user's should take care of.
It is also important to keep in mind nuances of component config management for kubelet (1CM per version, copied locally) and kube-proxy (1CM, linked by all instances).
k/e issue + KEP:
kubernetes/enhancements#1381
/cc @rosti
The text was updated successfully, but these errors were encountered: