There is currently a race-condition when diffing, where we get the
object and then run a server-side dry-run patch and compare the two
results. If something changes the object on the server between the get
and the patch, the diff is going to show unrelated changes. We can now
specify the exact revisionversion that we want to patch, and that will
return a conflict, and we can retry multiple times to get a
non-conflicting diff. Eventually (after 3 times), we diff without
checking the version and throw a warning that the diff might be
partially wrong.
Give a new "ResourceVersion" option to the patch so that the patch can
be forced against a specific version. Also there is no way to customize
how many retries the patcher should do on conflicts, so also add a
"Retries" option that let's one customize it.
'kubeadm join' silently ignores --node-name and --cri-socket
command line options if --config option is specified.
In some cases it's much easier for users to override these parameters
from the command line instead of updating config, especially for
multi-node automatic deployments where only node name should be changed.
Implemented setting 'name' and 'criSocket' options from the command
line even if --config command line option is used.
Bump MinimumControlPlaneVersion and MinimumKubeletVersion to v1.12 and update
any related tests.
Signed-off-by: Rostislav M. Georgiev <rostislavg@vmware.com>
- make the whole config example actually pass strict verification
(i.e. make the config work with --config)
- add print init-defaults/join defaults
- other small fixes
Expose both a Stop() method (for cleanup) and a method to force
cert rotation, but only expose Stop() on the interface.
Verify that we choose the correct client.
Ensure that bootstrap+clientcert-rotation in the Kubelet can:
1. happen in the background so that static pods aren't blocked by bootstrap
2. collapse down to a single call path for requesting a CSR
3. reorganize the code to allow future flexibility in retrieving bootstrap creds
Fetching the first certificate and later certificates when the kubelet
is using client rotation and bootstrapping should share the same code
path. We also want to start the Kubelet static pod loop before
bootstrapping completes. Finally, we want to take an incremental step
towards improving how the bootstrap credentials are loaded from disk
(potentially allowing for a CLI call to get credentials, or a remote
plugin that better integrates with cloud providers or KSMs).
Reorganize how the kubelet client config is determined. If rotation is
off, simplify the code path. If rotation is on, load the config
from disk, and then pass that into the cert manager. The cert manager
creates a client each time it tries to request a new cert.
Preserve existing behavior where:
1. bootstrap kubeconfig is used if the current kubeconfig is invalid/expired
2. we create the kubeconfig file based on the bootstrap kubeconfig, pointing to
the location that new client certs will be placed
3. the newest client cert is used once it has been loaded
k8s-ci-robot