Provide capability to define autoscaling rules

[tomkerkhove]

Proposal

Allow end-users to specify how many instances they want to add/remove when one of the trigger criteria have been met. This allows them to have better control over the aggressiveness of their platform.

In terms of logic, the idea is to define the following:

• When queue count is > 1000, add 2 instances and wait for 15 min to scale out more
• When queue count is < 100, remove 1 instance and wait 5 min to scale in more

Or even more advanced by using multiple triggers:

• When queue count is > 1000 (trigger 1) and DB CPU is <60 (trigger 2), add 2 instances
• When queue count is < 100 (trigger 1) or DB CPU > 80 (trigger2), remove 1 instance

The important aspects here are:

• Scale in/out can have different amount of replicas to add/remove
• End-users can define cooldown periods during which no further scaler is added
• Combination of triggers can be used, either with an OR or AND fashion.

This would work similarly to traditional autoscalers such as Azure Monitor Autoscale:

Use-Case

While today end-users can already define the triggers for scaling in/out, sometimes this can be confusing and people want to have more control about when scaling will happen and how many instances will be added.

For example, they might want to scale out more aggressively than KEDA does or scale in less aggressively.

Anything else?

I believe these 2 "scaling flavors" should be offered next to each other and am not sure if we should mix it with the current approach.

The current way of scaling definitely still has its place and should not be removed.

[stale]

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.

[JonasSamuelsson]

Is this something anyone is working on?
It would be a great addition to avoid flapping (https://learn.microsoft.com/en-us/azure/azure-monitor/autoscale/autoscale-flapping).

[tomkerkhove]

Not at the moment because we need to spec it out and probably will face issues since we rely on the HPA but I agree this would be a good one to have because of flapping indeed.

If it would be specced out, would you be interested to contributing to this?

@zroubalik We are blocked because of HPA, right?

[JonasSamuelsson]

I've never written a single line of go in my life but I would be happy to help in any way I can.

[nagesh-salunke]

+1, If this is something getting prioritized, Will be happy to contribute

[tomkerkhove]

Definately open to contributions, @nagesh-salunke!

[klinakuf]

+1, would be also happy to contribute, at the University of Stuttgart, Software Quality and Architecture group, we have developed a language for simulation purposes of elastic software architecture called Scaling Policy Definitions.

https://www.palladio-simulator.com/Palladio-Documentation-Slingshot/spd/

Now we are thinking to build an autosaler around this language, would be interesting to integrate Scaling Policy Definitions within KEDA. Would also resolve #3567