Allow other CNI providers to be installed

[kubernetes-sigs]

Allow other CNI providers to be installed

[rsdcastro]

From @mrIncompetent on March 5, 2018 5:55

Do we really want to have this in the API?
The User could deploy whatever CNI provider he wants via a Daemonset

[rsdcastro]

For a fully functional cluster, we need to have a CNI provider installed, right? This is being done in the current GCP provider code and it's also in the kubeadm documentation.

My idea is that if we'll deliver a fully functional cluster to the cluster and will install a CNI provider as part of that, then we should allow the customer to specify a different one (as the hard-coded one might not work).

Let me know your thoughts and please feel free to correct me.

[rsdcastro]

From @mrIncompetent on March 5, 2018 18:43

Maybe something like an add-on manager might be suitable here?
@chrislovecnm I never actually had the time to play around with the Kops add-on manager, you see options implementing it here?

As i assume by now most/every CNI provider nowadays can be installed using a Daemonset.
Kubedns/coredns could be installed the same way.

[rsdcastro]

That is fair. CNI would be technically one of the "essential add-ons" that are needed to have a fully functional cluster. Some of the essential add-ons (kube-dns and kube-proxy) are installed by kubeadm, but the remaining (at least CNI provider) could be installed via cluster API.

We're starting to do work on what a long-term add-ons management solution would look like and even picked @justinsb's brain last week on that.

If we don't do anything special in the cluster API for CNI (which is reasonable after this discussion), we may need to accelerate that work to have more CNIs available to customers as part of the cluster API.

[rsdcastro]

From @roberthbailey on March 7, 2018 18:48

We will want to install kube-proxy and kube-dns as addons as well (the current kube-proxy mechanism is a bit of a hack) and CNI should fit into that model. In the mean time, I think it's ok to say that the provider can dictate the CNI provider installed into the cluster, and if we want to make it configurable we can do so inside of the provider config.

[rsdcastro]

From @chrislovecnm on March 7, 2018 19:33

Kinda concerned that we are wandering into addons land. Are these addons? Maybe I am missing something but how is stuff like kube-dns part of the machine api?

If those those components are addons, which IMO is part of the installers responsibility. Eventually I hope we have an addon manager.

The only component that has to be installed is cni or kubenet, but I think that is the installer as well not the machine API

[rsdcastro]

Kamino closed and cloned this issue to kubernetes-sigs/cluster-api

[roberthbailey]

/cc @errordeveloper

We discussed this a bit during the meeting last week and my proposal was to start with provider specific fields since the network configuration is probably very closely related to the environment in which the cluster is deployed. If/when w see patterns emerge, we can decide on whether it makes sense to promote something to the common cluster api spec.

/close