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

Make interceptor Cluster bound instead of namespace bound #240

Closed
nilesh93 opened this issue Aug 25, 2021 · 4 comments · Fixed by #269
Closed

Make interceptor Cluster bound instead of namespace bound #240

nilesh93 opened this issue Aug 25, 2021 · 4 comments · Fixed by #269
Assignees
Labels

Comments

@nilesh93
Copy link

Interceptor should be able to run in an admin namespace (eg: keda-http) and should be able to forward traffic to multiple services in multiple namespaces

Use-Case

In a scenario where, there are multiple services in multiple namespaces in a given cluster, sometimes it could be costly to add a keda http interceptor per namespace. Rather, just like how ingress controller works, it would be best if the interceptor can reside in an admin namespace and forward traffic to multiple services in multiple namespaces.

@tomkerkhove
Copy link
Member

This will be done through #183 where it will become multi-tenant.

@arschles
Copy link
Collaborator

@tomkerkhove actually, the interceptor after #183 (associated PR is #206) only works in the same namespace it's running in. that's because it forwards requests to http://<app_service>:<app_port>.

@nilesh93 we can make fairly simple changes to interceptor, scaler and HTTP Addon operator to respect a WATCH_NAMESPACE configuration parameter (like what the KEDA operator already respects) so that components are loosely coupled from their own namespace, but still single tenant.

the result would be that interceptor, scaler, addon operator and keda operator would still only work with one namespace at a time, but you could run many of them all in the same admin namespace, and configure each with a different target namespace (the same would go for scaler, addon operator, and keda operator). would that solution be workable for you?

@arschles
Copy link
Collaborator

arschles commented Aug 25, 2021

note that this interacts with #241. if the operator were to create new interceptors and scalers on submission of a new HTTPScalingComponents CRD, then it would be responsible for setting up the WATCH_NAMESPACE environment variable. we'll need to consider that when finalizing a design here (and vice versa). ideally, I'd like a single solution to solve both concerns at once

@stale
Copy link

stale bot commented Dec 7, 2021

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale All issues that are marked as stale due to inactivity label Dec 7, 2021
@stale stale bot removed the stale All issues that are marked as stale due to inactivity label Dec 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants