b881f19c8b
kubeadm's current implementation of component config support is "kind" centric. This has its downsides. Namely: - Kind names and numbers can change between config versions. Newer kinds can be ignored. Therefore, detection of a version change is considerably harder. - A component config can have only one kind that is managed by kubeadm. Thus a more appropriate way to identify component configs is required. Probably the best solution identified so far is a config group. A group name is unlikely to change between versions, while the kind names and structure can. Tracking component configs by group name allows us to: - Spot more easily config version changes and manage alternate versions. - Support more than one kind in a config group/version. - Abstract component configs by hiding their exact structure. Hence, this change rips off the old kind based support for component configs and replaces it with a group name based one. This also has the following extra benefits: - More tests were added. - kubeadm now errors out if an unsupported version of a known component group is used. Signed-off-by: Rostislav M. Georgiev <rostislavg@vmware.com> |
||
|---|---|---|
| .. | ||
| addons | ||
| bootstraptoken | ||
| certs | ||
| controlplane | ||
| copycerts | ||
| etcd | ||
| kubeconfig | ||
| kubelet | ||
| markcontrolplane | ||
| patchnode | ||
| selfhosting | ||
| upgrade | ||
| uploadconfig | ||