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> |
||
|---|---|---|
| .. | ||
| apis | ||
| cmd | ||
| componentconfigs | ||
| constants | ||
| discovery | ||
| features | ||
| images | ||
| phases | ||
| preflight | ||
| util | ||
| BUILD | ||
| kubeadm.go | ||