Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
kubeadm upgrade plan: print a component config state table #88124
What type of PR is this?
What this PR does / why we need it:
This change enables
Which issue(s) this PR fixes:
Special notes for your reviewer:
This PR is part of the implementation of the new kubeadm component config management scheme KEP (see link below). It also depends on #86070 . Please, review the last 2 commits only!
Does this PR introduce a user-facing change?:
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:
kubelet.DownloadConfig is an old utility function which takes a client set and a kubelet version, uses them to fetch the kubelet component config from a config map, and places it in a local file. This function is simple to use, but it is dangerous and unnecessary. Practically, in all cases the kubelet configuration is present locally and does not need to be fetched from a config map on the cluster (it just needs to be stored in a file). Furthermore, kubelet.DownloadConfig does not use the kubeadm component configs module in any way. Hence, a kubelet configuration fetched using it may not be patched, validated, or otherwise, processed in any way by kubeadm other than piping it to a file. This patch replaces all but a single kubelet.DownloadConfig invocation with equivalents that get the local copy of the kubelet component config and just store it in a file. The sole remaining invocation covers the `kubeadm upgrade node --kubelet-version` case. In addition to that, a possible panic is fixed in kubelet.DownloadConfig and it now takes the kubelet version parameter as string. Signed-off-by: Rostislav M. Georgiev <firstname.lastname@example.org>
…nfigs Until now, users were always asked to manually convert a component config to a version supported by kubeadm, if kubeadm is not supporting its version. This is true even for configs generated with older kubeadm versions, hence getting users to make manual conversions on kubeadm generated configs. This is not appropriate and user friendly, although, it tends to be the most common case. Hence, we sign kubeadm generated component configs stored in config maps with a SHA256 checksum. If a configs is loaded by kubeadm from a config map and has a valid signature it's considered "kubeadm generated" and if a version migration is required, this config is automatically discarded and a new one is generated. If there is no checksum or the checksum is not matching, the config is considered as "user supplied" and, if a version migration is required, kubeadm will bail out with an error, requiring manual config migration (as it's today). The behavior when supplying component configs on the kubeadm command line does not change. Kubeadm would still bail out with an error requiring migration if it can recognize their groups but not versions. Signed-off-by: Rostislav M. Georgiev <email@example.com>
Component configs are used by kubeadm upgrade plan at the moment. However, they can prevent kubeadm upgrade plan from functioning if loading of an unsupported version of a component config is attempted. For that matter it's best to just stop loading component configs as part of the kubeadm config load process. Signed-off-by: Rostislav M. Georgiev <firstname.lastname@example.org>
This change enables kubeadm upgrade plan to print a state table with information regarding known component config API groups. Most importantly this information includes current and preferred version for each group and an indication if a manual user upgrade is required. Signed-off-by: Rostislav M. Georgiev <email@example.com>
[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: rosti
The full list of commands accepted by this bot can be found here.
The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing
@rosti: The following tests failed, say