-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Add Keda autoscaling for ballista in k8s #586
Conversation
cc @andygrove |
What's the policy here? This file comes from the Keda repo |
Codecov Report
@@ Coverage Diff @@
## master #586 +/- ##
==========================================
- Coverage 76.02% 75.96% -0.06%
==========================================
Files 156 156
Lines 27063 27086 +23
==========================================
+ Hits 20575 20577 +2
- Misses 6488 6509 +21
Continue to review full report at Codecov.
|
3rd party work should have their original license and copyright maintained, see https://www.apache.org/legal/src-headers.html#3party. I think adding a header like below should be good enough:
Copied from the bottom of https://github.com/kedacore/keda/blob/main/LICENSE. |
merge conflicts resovled |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. I haven't used keda before and haven't tested these changes but they look reasonable.
Hi @edrevo could you rebase this one when you get a chance. |
merge conflicts resolved |
Which issue does this PR close?
Closes #585.
What changes are included in this PR?
This PR provides very primitive support for auto-scaling: it works like an on-off switch. If there are no active tasks, the number of executors drops to 0. If there are active tasks, the number of executors will increase to the maximum number of allowed executors configured in Keda.
Further work could refine this so that the number of executors is proportional to the amount of outstanding tasks or something like that, but it is not trivial since we may end up killing executors that hold valuable shuffle data even if the aren't processing anything.
Changes in this PR:
I have tested this manually and seen it scale to 0 and back up when there is a query.
Are there any user-facing changes?
No