Currently kubeadm supports a couple of configuration versions - v1alpha3 and
v1beta1. The former is deprecated, but still supported.
To discourage users from using it and to speedup conversion to newer versions,
we disable the loading of deprecated configurations by all kubeadm
sub-commands, but "kubeadm config migrate".
v1alpha3 is still present and supported at source level, but cannot be used
directly with kubeadm and some of its internal APIs.
The added benefit to this is, that users won't need to lookup for an old
kubeadm binary after upgrade, just because they were stuck with a deprecated
config version for too long.
To achieve this, the following was done:
- ValidateSupportedVersion now has an allowDeprecated boolean parameter, that
controls if the function should return an error upon detecting deprecated
config version. Currently the only deprecated version is v1alpha3.
- ValidateSupportedVersion is made package private, because it's not used
outside of the package anyway.
- BytesToInitConfiguration and LoadJoinConfigurationFromFile are modified to
disallow loading of deprecated kubeadm config versions. An error message,
that points users to kubeadm config migrate is returned.
- MigrateOldConfig is still allowed to load deprecated kubeadm config versions.
- A bunch of tests were fixed to not expect success if v1alpha3 config is
supplied.
Signed-off-by: Rostislav M. Georgiev <rostislavg@vmware.com>
In the past the discovery configuration expected, that we can support multiple
API server endpoints. In practice, we always end up with a single API server
endpoint, because, even in HA setups, we use a load balancer scheme for API
servers.
Therefore, to reduce complexity and improve readability of the config, the
multiple API server endpoints support is removed from the bootstrap token
discovery join method and configuration.
Signed-off-by: Rostislav M. Georgiev <rostislavg@vmware.com>
This change splits out discovery fields from JoinConfiguration by performing
the following changes:
- Introduce a BootstrapTokenDiscovery structure, that houses configuration
options needed for bootstrap token based discovery.
- Introduce a FileDiscovery structure, that houses configuration options
(currently only a single option) needed for KubeConfig based discovery.
- Introduce a Discovery structure, that houses common options (such as
discovery timeout and TLS bootstrap token) as well as pointer to an instance
of either BootstrapTokenDiscovery or FileDiscovery structures.
- Replace the old discovery related JoinConfiguration members with a single
Discovery member.
This change is required in order to cleanup the code of unnecessary logic and
make the serialized JoinConfiguration more structured (and therefore, more
intuitive).
Signed-off-by: Rostislav M. Georgiev <rostislavg@vmware.com>