-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support cluster and machine in multiple namespaces in clusterctl create #252
Comments
Note that since this was opened we added MachineSets and MachineDeployments which should also be supported. |
I can work on this. |
@ashish-amarnath: GitHub didn't allow me to assign the following users: ashish-amarnath. Note that only kubernetes-sigs members and repo collaborators can be assigned. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Need to clarify:
|
IMO there isn't much value in allowing the creation of |
My understanding about what the community decided regarding namespaces and clusters is that cluster objects will be in different namespaces and there will only be one cluster object per namespace. Any machine objects in the same namespace as a cluster object belong to that cluster (this specific point about how machines link to clusters might change). kubernetes-retired/kube-deploy#463 I think we should stick with the community-agreed model. Feel free to counter propose in the community meeting and get community consensus if you feel strongly that we should be keeping all cluster objects in one namespace. |
There were folks that wanted to put multiple clusters into a single namespace so that they could share things like credentials for a cloud provider. At that point it would be similar (conceptually) to having two GKE clusters in the same GCP project -- the namespace is like the project and you want the same access to developers to both clusters.
There is an open issue (and maybe PR) to make a tighter link to support the above use case.
I don't think anyone was advocating for having them all in a single namespace, but having the flexibility of having more than one per namespace. |
Also see #41. |
Issue #41 was discussed during the meeting on June 20th (notes). @mvladev had an AI to add some comments to the issue but it looks like they weren't extracted from the conversation and put into github (to be more easily found). The summary is that we agreed to add an optional reference from Machine -> Cluster so that you could have multiple clusters in the same namespace and be able to identify which machines belong to which cluster. |
https://github.com/kubernetes-sigs/cluster-api/blob/master/clusterctl/clusterdeployer/clusterclient.go After gathering thoughts from other folks I have evaluated 3 approaches to solve this: Approach 1: One namespace for all clusters objects:
Cons:
Approach 2: Namespace per cluster
Cons:
Approach 3: Allow cluster deployer to accept the namespace where the cluster-api objects will need to be created
Cons:
Based on the above evaluation Approach 3 is better. Feel free to correct me if I've gotten something wrong or I am missing anything. |
In the current Cluster API architecture, the common controller code must be changed to support the different approaches listed above. If a provider's use case is not supported, the provider must choose between merging its changes to the Cluster API, or forking. In light of that, I think it's important to keep potential use cases in mind. For example, an enterprise could run a permanent external cluster with the Cluster API. It could give internal organizations broad permissions within different namespaces in that cluster. To support this use case, the Cluster API common controllers would have to reconcile multiple Cluster objects in the same namespace--and, as a consequence, be able to associate Machine objects to some Cluster object. |
I wonder if we can split the backend work from the UX design. I think these are the pieces of the backend design:
FWIW, for our SSH we are assuming one cluster per namespace (no need for strong refs) and one controller per cluster (better isolation). |
@davidewatson In the change that I am working on atm, for the cluster |
Fair, that's a good point. |
/assign |
@ashish-amarnath: GitHub didn't allow me to assign the following users: ashish-amarnath. Note that only kubernetes-sigs members and repo collaborators can be assigned. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Support cluster and machine in multiple namespaces in clusterctl create as it currently assumes default namespace.
The text was updated successfully, but these errors were encountered: