search

kedacore / http-add-on

Add-on for KEDA to scale HTTP workloads
https://kedacore.github.io/http-add-on/
Apache License 2.0
373 stars 97 forks source link

Multiple deployments per httpso #1053

Closed Varun-Mehrotra closed 5 months ago

Varun-Mehrotra commented 6 months ago

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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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.