-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce new time-window trigger #3566
Comments
thanks Tom, i think it's a useful feature. Maybe we should keep desiredReplicas or some other way to specify the target behavior
In terms of user / customer scenarios, I understand this "time window" trigger / scaler should be used as the only scaler for the ScaledObject/Job (not in multiple triggers scenario, as of now) |
How would you compare that to the already existing |
perhaps something like:
what I couldn't see, is how to tell the difference between when to scale In Or Out, during this window |
Hm so during a given time window, you might want to scale in instead of out then? Why not invert the window then? To me it feels more natural to always scale to max during window and min outside of window. |
makes sens, as long as we define the rule (what you just did). I was seeing it as a time window where I could do both |
We can do it, but I think it just makes it more confusing/redundant with the existing configuration already available |
+1 to this approach. I'd extend cron scaler to do this |
@zroubalik The proposal is actually to introduce a new scaler and deprecate the cron-scaler. |
okay, good to me as well. |
new scaler is a good idea to me, but I'd use cron expressions to start and end because it's more flexible |
What scenario would you need that does not fit the above? Specify the exact second? Hour? Minute? or? |
During X time every hour for instance. A real user case (from my previous work): |
Then I'd argue that we should not deprecate the cron scaler and just add it next to it, no? |
The cron trigger seems to be more flexible, both because of the use of cron format and the ability to set |
I don't have any strong opinion about both solutions. Maybe we could extend cron trigger or create another one. I'm not sure about the implementation because right now scalers don't have access to min/max values from SO/SJ and I'm not sure if they should know that info, but in any case it's more related with the implementation than with having or not other scaler |
@amirschw I'm curious about this remark because this creates a lot of confusion for the majority of people. Why would you want to specify desiredReplicas and how do you see it relate to min/max replicas which is redundant? |
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. |
This is still confusing people :) I think we should think about this again @zroubalik @JorTurFer |
About introducing it or about the scaler itself? |
thanks Tom for adding this. I think this is a useful feature. It will be good to support NCRONTAB for the schedule and have the ability to set min/max replicas of target workload deployments. |
@JorTurFer The new scaler because our cron scaler is confusing as people want to do CronJob-like things while all we do is scale based on defined time windows.. |
I meant, we agreed with the new scaler, but nobody has tackled it yet. |
I don't think we have a agreement on how it relates to cron scaler and plan going forward though |
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. |
This issue has been automatically closed due to inactivity. |
Cron scaler reads as follows "not gonna work as a reoccuring schedule" ? It's a REALLY REALLY common pattern that you have day/night or weekends or holidays that have lower traffic and it would make sense to scale down during this period. Many workloads are predictable. Any plans to add this scaler ? I would like to scale based on metrics between 9to5 and scale in to min (or even min-X) between 5to9 ? What options I currently have when using KEDA ? |
I don't know what they used who added the comment meant, but using cron scaler you can achieve that behaviour. You could set a cron scaler which starts at 5 and ends at 9 with a desired value of X, and during that period you will have at least X. Something that you cannot achieve is to use the cron scaler for scaling to X replicas if there is any other scaler requiring more replicas because the HPA controller does a MAX between all the metrics |
@JorTurFer please assign after reviewing the conversation on issue #4677 if everything looks good. |
nice @sbdtu5498 ❤️ |
@krishna-kariya PTAL. |
This is a much needed feature. There are usecases where a feature like this would be useful eg. during planned spiky events, where the a deployment (or multiple) need to be scaled to maximum or a desired number. Instead of dotting the scaledobjects with many cron scalers which is cumbersome for the individual managing the scaledobject and error prone IMO, this can be implemented as a different scaler coupled with #4459 . Further these planned events can have a widespread effect across multiple deployments (eg: an ecommerce company where a sale is scheduled and all the workloads need to scale to their maximum footprint) so expecting every dev to manage the time schedules for their workload is not desirable. At our company we have implemented this on a fork of KEDA and has been in production since almost a year. If it seems relevant to most of the users we can work on the proposal. |
We are planning to introduce a new timer external scaler to check for NCRONTAB schedule and scale the pods from 0 to 1 and back to 0. |
It is important to mention, however, that this new timer external scaler will have a dependency on Azure Storage and is for Azure Functions; no @raorugan? :) |
Hi I wanted to share a more concrete use case where this would be useful: Basically: ^-- This would Also, I know you can't currently add metric counters like that (#2440 has a feature req for that, but even without 2440), you can do the equivalent of the above [desired = A + B] by defining both triggers and letting the built-in OR logic take place.
Here's a more concrete explanation of why reoccuring cron to set dynamicly changing min value could be useful: A business might have a regular traffic spike during certain business hours. |
I think we need to prioritize this one and kill CRON scaler, @zroubalik / @JorTurFer. It is confusing too many people as CRON is not a CRON |
Proposal
Introduce new time-window trigger which allows you to scale based on a defined time window.
We could use inspiration from the kube-green project:
The
cron
scaler usesdesiredReplicas
but I believe it should just rely on min/max replica defined on the ScaledObject/ScaledJob.This trigger should replace the
cron
scaler which is confusing in how it scales as end-users tend to think it behaves like jobs.Use-Case
Scale workloads based on a time window.
Anything else?
No response
The text was updated successfully, but these errors were encountered: