-
Notifications
You must be signed in to change notification settings - Fork 834
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
Seems to be a bad fit for a multi-tenant cluster. #308
Comments
The only kube-system part is the optional Spartakus anonymous metrics. By default this is not applied. We have two parts to the present system.
So our intention is definitely to be a system that can be run just in a single namespace apart from the setup of the Custom Resource Definition. Hope that clarifys things. |
It does, thanks. So you contend that if i use the switch |
It is false by default so you do not need even to set it explicitly to false. seldon-core/helm-charts/seldon-core-crd/values.yaml Lines 1 to 2 in 48d2bbb
|
Answered. Please reopen if more clarification is needed. |
Hey contributors.
I'm an administrator of several large mutli-tennant k8s clusters running for our enterprise. We give teams namespaces and bindings to do whatever they would like inside their namespaces.
Occasionally a team wants to use a tool that requires some cluster level resources, often crds, which we generally grant. A team has recently come to me with your tool. However after reviewing the output of your "core" helm chart I find that you go further and create a deployment in kube-system. That makes your system seem like a total non-starter for me. It seems like an anti-pattern.
Can you explain your architecture around this decision. I assume that is your crd controller component? Generally these crd/controller deployments allow their controller to be deployed at a cluster level with cluster scoped permissions OR in a namespaced fashion all running within a certain namespace.
The text was updated successfully, but these errors were encountered: