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 <rostislavg@vmware.com>
* Migrate a single node_authorizer.go klog.Infof call to klog.InfoS
We are starting with the log lines that show up most often.
Signed-off-by: Andrew Keesler <akeesler@vmware.com>
* Remove quotes from error for readability
Signed-off-by: Andrew Keesler <akeesler@vmware.com>
* node_authorizer.go: use %s for node names for log uniformity
Signed-off-by: Andrew Keesler <akeesler@vmware.com>
* node_authorizer.go: single-quote node name for readability++
This is good because:
1) the node name is clear in the log line
2) the node names shows up the same in {un-,}structured logs
Signed-off-by: Andrew Keesler <akeesler@vmware.com>
Under the feature gate DefaultPodTopologySpread, which will disable the legacy DefaultPodTopologySpread plugin from the default algorithm providers.
Signed-off-by: Aldo Culquicondor <acondor@google.com>
`getK8sVersionFromUserInput` would attempt to load the config from a user
specified YAML file (via the `--config` option of `kubeadm upgrade plan` or
`kubeadm upgrade apply`). This is done in order to fetch the `KubernetesVersion`
field of the `ClusterConfiguration`. The complete config is then immediately
discarded. The actual config that is used during the upgrade process is fetched
from within `enforceRequirements`.
This, along with the fact that `getK8sVersionFromUserInput` is always called
immediately after `enforceRequirements` makes it possible to merge the two.
Merging them would help us simplify things and avoid future problems in
component config related patches.
Signed-off-by: Rostislav M. Georgiev <rostislavg@vmware.com>
Windows does not support partially qualified domain names, which is why the test can fail.
Additionally, because nslookup may return 0 on Windows, even if the given DNS name was not
found, this issue was not observed until recently. We're now checking stderr as well.
The current message for rejecting defaulting is fairly unclear -- I wasn't
sure why it was happening till I read the kubernetes source code.
That's probably not something we want our users to have to do, so this
adds more reasons for rejecting the defaulting to the message given to the
user. We previously added reasons in certain cases, but did not in the
common cases of using apiextensions/v1beta1 or having defaulting
disabled in a feature gate. Now we have reasons for all cases.
