* LocalTrafficDetector construction and test improvements
* Reorder getLocalDetector unit test fields so "input" args come before "output" args
* Don't pass DetectLocalMode as a separate arg to getLocalDetector
It's already part of `config`
* Clarify test names in preparation for merging
* Merge single-stack/dual-stack LocalTrafficDetector construction
Also, only warn if the *primary* IP family is not correctly configured
(since we don't actually know if the cluster is really dual-stack or
not), and pass the pair of detectors to the proxiers as a map rather
than an array.
* Remove the rest of Test_getDualStackLocalDetectorTuple
The constructors only return an error if you pass them invalid data,
but we only ever pass them data which has already been validated,
making the error checking just annoying. Just make them return garbage
output if you give them garbage input.
Windows proxy metric registration was in a separate file, which had
led to some metrics (eg the new ProxyHealthzTotal and ProxyLivezTotal)
not being registered for Windows even though they were implemented by
platform-generic code.
(A few other metrics were neither registered on, nor implemented on
Windows, and that's probably a bug.)
Also, beyond linux-vs-windows, make it clearer which metrics are
specific to individual backends.
Instead of erroring during the preflight check 'CreateJob'
from "upgrade" commands when there are no schedulable nodes,
show a warning.
This can happen in single node clusters.
Also increase the Job TTL after completion to 20 seconds
to make sure it's more than the timeout what waits
for the Job to complete.
There is no point to track more than 3 etcd versions at a time
where each etcd versions maps to a k8s CP version.
It's 3 instead of 2 (k8s CP / kubeadm version skew size) because
there is a period of time where the 3rd version (newest) will
be WIP at k/k master - e.g. at the time of this commit it's 1.31.
Add a unit test to block on this.
Also fixate the min etcd version to 3.5.11.
During upgrade apply we had logic to download the kubelet and
kubeproxy configs from the cluster as part of the call to:
FetchInitConfigurationFromCluster()
With the introduction of UpgradeConfiguration there was
some refactor in this area and the function no longer
had the argument skipComponentConfigs set to false.
It is set to 'true', an InitConfiguration is downloaded
but it would contain empty / defaulted component configs.
- Set the argument to 'false'
- Perform minor cleanup of STDOUT messages and comments.
that were missed in 1.30.
- Mark the phase 'init kubelet-finilize experimental-cert-rotation'
as deprecated and print a warning if its used directly. It should be
removed in 1.32.
- Add a replacement phase 'enable-client-cert-rotation'.
(!!) We should stop using the 'experimental' and 'alpha' names for
phases, clI flags and k8s object names as this complicates
the graduation and users will use the feature in production regardless.
Having a 'DEPRECATED' or 'EXPERIMENTAL' text in descriptions is
sufficient to indicate a status of a feature that should not be used
in production.
The function KubernetesReleaseVersion is being called in
a number of locations during unit tests but by default it
uses a "fetch version from URL" approach.
- Update the function to return a placeholder version
during unit tests.
- Update unit tests for this function.
- Update strings / comments in other version_tests.go
locations.
The improvement is significant:
time go test k8s.io/kubernetes/cmd/kubeadm/app/... -count=1
before:
real 2m47.733s
after:
real 0m10.234s
If users don't pass any --nodeport-addresses, suggest they should pass
`--nodeport-addresses primary`, to avoid accepting NodePort
connections on all interfaces.
If users pass a single-stack --nodeport-addresses in what looks like a
dual-stack cluster, warn them that they probably ought to be passing a
dual-stack --nodeport-addresses.
The behavior when you specify no --nodeport-addresses value in a
dual-stack cluster is terrible and we can't fix it, for
backward-compatibility reasons. Actually, the behavior when you
specify no --nodeport-addresses value in a single-stack cluster isn't
exactly awesome either...
Allow specifying `--nodeport-addresses primary` to get the
previously-nftables-backend-specific behavior of listening on only the
node's primary IP or IPs.
