Skip to content
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

Closed
SleepyBrett opened this issue Nov 20, 2018 · 4 comments
Closed

Seems to be a bad fit for a multi-tenant cluster. #308

SleepyBrett opened this issue Nov 20, 2018 · 4 comments

Comments

@SleepyBrett
Copy link

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.

@ukclivecox
Copy link
Contributor

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.

  1. The CRD which is cluster wide as expected. This would need to be created by the sys-admin. This is available in the seldon-core-crd Helm chart.
  2. The core "operator" which presently runs in a particular namespace. The present helm chart for this does have a cluster Role so it can try to create the CRD if it doesn't exist but we plan to provide a setting to remove this so just namespaced Roles are all that is needed.

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.

@SleepyBrett
Copy link
Author

It does, thanks. So you contend that if i use the switch --usage_metrics.enabled=false it will stop attempting to deploy the kube-system service.

@ukclivecox
Copy link
Contributor

It is false by default so you do not need even to set it explicitly to false.

usage_metrics:
enabled: false

@ukclivecox
Copy link
Contributor

Answered. Please reopen if more clarification is needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants