This has been replaced by `//build:...` for a long time now.
Removal of the old build tag was automated with:
for i in $(git grep -l '^// +build' | grep -v -e '^vendor/'); do if ! grep -q '^// Code generated' "$i"; then sed -i -e '/^\/\/ +build/d' "$i"; fi; done
The PatchNodeOnce function has historically exited early
in scanarious when we Get a Node object, but the next Patch
API call on the same Node object fails. This can happen
in setups that are under a lot of resource pressure
or different network timeout scenarious.
Instead of exiting early and allow listing certain errors,
always retry on any Patch error. This aligns with the
general idea that kubeadm retries *all* API calls.
In local.go there are a couple of flags that changed their
format for etcd > 3.6.0. kubeadm 1.36 no longer supports
deploying a k8s version that maps to etcd < 3.6.0, thus
the branching and the deprecated flags can be removed.
The introduction of dynamic keys in the etcd version
map in constants.go introduced a couple of problems:
1. The size of the map could no longer be unit tested
because at UT runtime there was only one key "0".
2. Once a new k8s release branch is cut the version map
has mismatched versions. The latest k8s version mapped to the
future prerelease alpha (placeholder), the previous was the current
WIP release version and the oldest version in the map is the
current stable. This introduces a undesider shift of versions
where we are applying the wrong version to the current WIP
release unless an contrubutor PRs it.
The old static approach on the other hand is safer because
it hardcodes the versions, and the utility function
EtcdSupportedVersion() ensures that we get a relevant etcd
version even if the input k8s MINOR key is out of bonds for the map.
- Revert to using static version in the map.
- Revert the unit test TestEtcdSupportedVersionLength.
- Add additional comments over the map.
If the user has provided extraArgs with an order that has
significance (e.g. --service-account-issuer for kube-apiserver),
kubeadm will correctly override any base args, but will end up
sorting the entire resulting list, which is not desired.
Instead, only sort the base arguments and preserve the order
of overrides provided by the user.
The command can have this additional flag so that a warning
is printed or not printed when a deprecated API is validated.
Additionally, this commit fixes missing UpgradeConfiguration
validation and strict errors. By default we call:
documentMapToUpgradeConfiguration(gvkmap, false, false, false)
so there is no change in behavior outside of
'config migrate/validate'.
For historic reasons kubeadm kept track of a skew of 2+
etcd version in a map in the constants.go file.
This is really not required because kubeadm supports only
2 version of etcd mapped to two Kubernetes versions,
which are essentially the control plane versions.
Refactor the constants.go map to only include 2 versions.
Make sure that's reflected in a unit test.
Instead of pinning the versions as literal numbers,
start using the version we get on build time.
Adapt various unit tests and functions to allow this change
to work, since during unit tests we need actual values
and the build versions are not populated. This is achieved
by requiring the functions to accept a map[uint8]string
used for testing.
By using k8s.io/system-validators v1.12.1 a KubeletVersion
can be passed to the CgroupsValidator. The library
can then decide if to throw an error or a warning.
An error is thrown if the version is >= 1.35.
During upgrade pass a KubeletVersion that is with MINOR+1
to account for the target upgrade version. That is just
an assumption that the user will upgrade the kubelet too,
but it is better to throw an error for this
common use case instead of just a warning that is seen
after the upgrade command has finished.
When retrieving the cluster-info CM, ensure the cluster pointed
out by the current context in the kubeconfig is validated.
Add unit test for the above.
Make the function GetClusterFromKubeConfig() to return various
errors. Handle the errors on call sites. Add unit tests
for the update.
The above changes prevent panics when the users has manually
edited and malformed the kubeconfig in the cluster-info CM.
