Autoscale in different namespaces

[cambyn]

Can we use http-add-on to scale pods to 0 in different namespaces? If the answer is yes, then what will be a suitable way to so. Thanks

[tomkerkhove]

As far as I know, yes. However, all traffic needs to be intercepted by KEDA HTTP add-on.

[HongboFei]

I would say absolutely yes, that's why we use http-add on.

[ishallbethat]

@brondum i didn't solve it.
@danielamar101 Can you pls be more specific how I can use scaleobject to achieve this

[danielamar101]

So the http-add-on helm chart installs three deployments:

1. The controller-manager
2. external scaler
3. interceptor

And a few services:

1. http-controller-manager-metrics-service
2. external scaler
3. interceptor-admin
4. interceptor-proxy
5. operator-admin

In order to route external traffic to the deployment, I use an ingress and specify my own service that will route to the deployment, however for the add-on to work, we have to route the ingress to the interceptor-proxy service.

Typically this interceptor-proxy service lives in a namespace like keda-http while my ingress would be in another namespace. It is currently impossible to have an ingress route to a service in another namespace without super hacky stuff. So instead I put my ingress in the same namespace as the interceptor-proxy service (in my case keda-http). The HttpScaledObject then tells the interceptor which deployment to route the traffic to, as this is no longer implied by having an ingress route to my own service which is selected by my app deployment.

[MohamadTahir]

This is not a clean solution, I prefer keeping all the resources that are related to a named project in their own namespace, there is no need for me to put the ingress in the add-on namespace while keeping the rest of the components in a different namespace. this can get messy.

[HongboFei]

@tomkerkhove, let me see if i can find a better example. But i agree with @ishallbethat and @MohamadTahir we have to put the ingress object in the namespace same with the http-addon installed for now.

[danielamar101]

@MohamadTahir I agree with you, but in the current architecture I don’t see any another way.

@HongboFei are you referring to the ingress for a deployment? Because thats what I’m implying in my comment above, when saying the deployment ingresses need to be in the same namespace as the addon, due to k8s limitations.

[sudermanjr]

I wonder if it would be possible to deploy multiple interceptor proxies in multiple namespaces? This would allow the ingress for each service to live in the namespace for the service, as well as spread the interceptor load across multiple interceptors in large deployments.

[cldfzn]

Yeah, this is essential for multi-tenant environments where tenants are limited to isolated namespaces. Without this we'll need to create a CRD and operator to create ingresses in the desired namespace from their tenant namespace.