Multiple deployments per httpso

[Varun-Mehrotra]

Proposal

Currently, the http-add-on scales one deployment for each HTTPScaledObeject. This makes it difficult to scale multiple deployments based on traffic for one service. If you attempt to do this right now (as in creating multiple HTTPScaledObjects that point to the same service, but different deployments) not all deployments are scaled, only one is at a time, and seemingly random at that.

There's two ways I see it that this can be implemented:

1. Handle how requests should map to multiple HTTPScaledObjects
2. Change the HTTPScaledObject schema to support an array of objects rather than a single deployment/daemon set.

Use-Case

The use case I'm looking at specifically is for something like a development environment, or something else that doesn't need to necessarily be up immediately. I'd like to scale down all deployments that I'm running in a namespace dependant on the traffic to one service.

Is this a feature you are interested in implementing yourself?

Yes

Anything else?

No response

[JorTurFer]

Hello,
This is something that should be done directly in the main project as it's who manages the HPA generation. In any case, I'm not totally sure about the management complexity from KEDA's pov if we support this.

@tomkerkhove @zroubalik @wozniakjan ?

[wozniakjan]

I'd like to scale down all deployments that I'm running in a namespace dependant on the traffic to one service.

hi @Varun-Mehrotra, that is an interesting scenario where I would consider a different approach potentially

1. Handle how requests should map to multiple HTTPScaledObjects
2. Change the HTTPScaledObject schema to support an array of objects rather than a single deployment/daemon set.

HTTPScaledObject serves two purposes, one is to configure and create ScaledObject which KEDA and HPA uses for scaling, and second is to configure interceptor which tells it where to route the traffic for certain hostnames.

I think it should be possible to create first HTTPScaledObject for the main Service and Deployment and then you could create just plain ScaledObjects for the other Deployments. With http-add-on's scaler as a trigger without HTTPScaledObject.

That way there is a single metric related to the network traffic for the main Deployment but other Deployments get scaled based on this too.

[zroubalik]

I think it should be possible to create first HTTPScaledObject for the main Service and Deployment and then you could create just plain ScaledObjects for the other Deployments. With http-add-on's scaler as a trigger without HTTPScaledObject.

I am also inclined towards this solution.

I wouldn't like to modify ScaledObjects in KEDA to support array of targets. We discussed this many times and decided to stick to the current solution.

[Varun-Mehrotra]

Hey @wozniakjan, totally makes sense, thanks for the suggestion. I was actually able to already try that out and it works really well.

I setup one HTTPScaledObject and I scale all my other deployments depending on that one using a ScaledObject kubernetes-workload trigger type cause my use case was really just 1 or 0 replicas so it was pretty easy.

Now that environment is down most of the time and comes up within a minute or two whenever someone tries to access it, and scales back down to 0 after an hour of no use. Works super well for some ephemeral environments I've got setup that are used maybe once or twice a day while they are alive.

Now I'm just trying to figure out how to get this working without an externalName service cause Amazon's ingress doesn't work with it.

[wozniakjan]

I was actually able to already try that out and it works really well.

nice, glad it works with your setup :)

Now I'm just trying to figure out how to get this working without an externalName service cause Amazon's ingress doesn't work with it.

yeah, sadly that appears to be the case for alb but if you are willing to explore GatewayAPI, there might be easy path forward with ReferenceGrants. I have tried only the Envoy Gateway but looks like there is AWS native implementation available too.

[Varun-Mehrotra]

Hm gotcha. I was also thinking of just setting up an nginx deployment to route the traffic but that seemed like too many proxies in the mix lol. Thanks for the advice!

[wozniakjan]

I think we reached a conclusion on this topic, I will close it but feel free to reopen it in case you'd like to continue the discussion.