Open tomkerkhove opened 2 years ago
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.
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).
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?
I've never written a single line of go in my life but I would be happy to help in any way I can.
+1, If this is something getting prioritized, Will be happy to contribute
Definately open to contributions, @nagesh-salunke!
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:
Or even more advanced by using multiple triggers:
The important aspects here are:
OR
orAND
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.