Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
[WIP] kubeadm: v1beta3 addons #84991
What type of PR is this?
What this PR does / why we need it:
This change introduces a list of addons to the ClusterConfiguration.
It is required for a couple of reasons:
If omitted the list is initialized by default with kube-proxy and CoreDNS with
Which issue(s) this PR fixes:
Special notes for your reviewer:
The PR is a WIP as it needs some tests reenabled and a couple of new ones written. It is also a quick solution, given the fact, that kubeadm does not have an internal addon manager. Hence changes were necessary throughout kubeadm's code base.
Please, review the last commit only.
Does this PR introduce a user-facing change?:
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:
[APPROVALNOTIFIER] This PR is NOT APPROVED
The full list of commands accepted by this bot can be found here.
fabriziopandini left a comment
@rosti Thanks for trying to push this effort forward. Really appreciated.
My major concert is not around the current PR, but the overall story about the Addon project integration.
There are still so many open questions around the UX on the KEP Install Addons via kubeadm, that is almost impossible for me to understand if this PR is going in the right direction or not. Therefore I'm personally inclined to a "hold" until there is more clarity around this topic. But of course, I'm open to discussing this and to align with the majority.
Some other components (like Cluster API) embed kubeadm types in their configs. This causes some problems as the API server would perform strict type checking and would complain about missing mandatory fields, that are in fact optional. Previously, optional fields in kubeadm types were identified by the `omitempty` JSON tag. With this patch, all such fields are getting the `+optional` annotation. Signed-off-by: Rostislav M. Georgiev <firstname.lastname@example.org>
Up until now, kubeadm's config types lacked ObjectMeta. This began to cause some compatibility issues mostly with Kustomize and projects using it (such as kind). However, using a full blown `metav1.ObjectMeta` proves problematic too. It contains way too many fields, that are not relevant to kubeadm, it clobbers the structs in which it's embedded with unnecessary fields and it generates a lot of unnecessary output when marshalling types to YAML (such as always nil `DeletionTimestamp`). Some tests (such as the fuzzer) are also broken and need unwieldy patches to get them fixed. As the only needed field out of `metav1.ObjectMeta` is `Name`, we introduce and leverage on a reduced kubeadm v1beta3 local stripped down version of ObjectMeta, that has only a `Name` field. The new type is embedded in InitConfiguration, JoinConfiguration and ClusterConfiguration. Most notably, it's not embedded in ClusterStatus as this type should not be used by anything else, other than kubeadm. The InitConfiguration and JoinConfiguration fields do nothing with ObjectMeta and don't store it anywhere. In the ClusterConfiguration, `metadata.name` replaces the `clusterName` field. The latter is therefore removed. Hence, the following v1beta2 ClusterConfiguration is upgraded to v1beta3 as such: ```yaml apiVersion: kubeadm.k8s.io/v1beta2 kind: ClusterConfiguration clusterName: LeCluster ``` ```yaml apiVersion: kubeadm.k8s.io/v1beta3 kind: ClusterConfiguration metadata: name: LeCluster ``` Signed-off-by: Rostislav M. Georgiev <email@example.com>
This change introduces a list of addons to the ClusterConfiguration. It is required for a couple of reasons: - Users want to opt out of any of the kubeadm default addons. So far this has proven difficult and unreliable even with the help of phases. - kubeadm has to advance its config closer to what is expected to be required by the cluster addons project. If omitted the list is initialized by default with kube-proxy and CoreDNS with automatically selected tags and repositories. Possible addons to install are kube-proxy, kube-dns and CoreDNS. The latter two can also have their image repository and image tag overwritten. If no addons are to be installed, a user can simply initialize the addon list as an empty array. The existing DNS fields in the ClusterConfiguration of older configs are superseded by the more general addons field and not present in v1beta3. Signed-off-by: Rostislav M. Georgiev <firstname.lastname@example.org>
@rosti: The following test failed, say