Comments (8)
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
from cluster-api.
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.
from cluster-api.
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.
from cluster-api.
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.
from cluster-api.
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.
from cluster-api.
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
from cluster-api.
Kamino closed and cloned this issue to kubernetes-sigs/cluster-api
from cluster-api.
/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
from cluster-api.
Related Issues (20)
- Improve `Generate weekly PR updates to post in Slack` docs/process HOT 4
- error with helm parsing double curly braces within 3 strings in `cluster-api-components.yaml` HOT 4
- Provide metadata to ClusterClass variables HOT 13
- Bump release-1.6 & release-1.5 to Go 1.21 HOT 2
- Tasks to bump to Kubernetes v1.30 HOT 2
- Rolling update on machine delition HOT 5
- Follow-up Tasks for MachinePool support in ClusterClass HOT 12
- CRD upgrade race condition HOT 7
- github.com/docker/docker from 24.0.7 to 25.0.0 HOT 3
- Improve Cluster Validation webhooks for .spec.topology.version HOT 2
- Kubeadm feature flags should be mutable HOT 12
- SSA failure after removal of old API versions HOT 17
- Add more descriptive Message to DrainingFailedReason and DrainingReason HOT 5
- MachinePool observedGeneration is updated without changing conditions on upgrades HOT 7
- Restructure ProwJobs HOT 2
- Incorporate additional patch release into next release cycle planning (v1.8) HOT 3
- Automated weekly release updates HOT 9
- test framework does not help investigating daemonset pods HOT 5
- Add a way to refresh one machine only (with scale out) HOT 7
- Add support for consuming nightly release manifests in clusterctl HOT 10
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cluster-api.