-
Notifications
You must be signed in to change notification settings - Fork 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
Add Eager mode for ScaledJobs #5114
Comments
Which scaler do you use? I think set the para queueLength on queue scaler can shorten the time. |
@SpiritZhou Thanks for your reply. We configured the scaler as above. |
What is your ScaledJob config? What do you set as a maxReplicaCount? |
---
apiVersion: keda.sh/v1alpha1
kind: ScaledJob
metadata:
name: worker
spec:
jobTargetRef:
template:
metadata:
labels:
app: worker
spec:
containers:
- name: worker
image: worker-image
imagePullPolicy: Always
resources:
requests:
memory: "4Gi"
cpu: "1"
env:
- name: WORKER_TYPE
value: pilot
- name: RB_USERNAME
valueFrom:
secretKeyRef:
name: rabbitmq-instance-default-user
key: username
- name: RB_PASSWORD
valueFrom:
secretKeyRef:
name: rabbitmq-instance-default-user
key: password
- name: RABBITMQ_URL
value: amqp://$(RB_USERNAME):$(RB_PASSWORD)@rabbitmq-instance.arc:5672
restartPolicy: Never
backoffLimit: 1
pollingInterval: 10 # Optional. Default: 30 seconds
maxReplicaCount: 10 # Optional. Default: 100
successfulJobsHistoryLimit: 0 # Optional. Default: 100. How many completed jobs should be kept.
failedJobsHistoryLimit: 5 # Optional. Default: 100. How many failed jobs should be kept.
triggers:
- type: rabbitmq
metadata:
queueName: woker_queue
hostFromEnv: RABBITMQ_URL
mode: QueueLength
value: "1" @zroubalik Basically like this. |
I have a question, if you want to process as much as possible, and then finish, doesn't ScaledObject fit better with your use case? You can set queueLength: 1 and all the instances will be removed at the end if you set |
@JorTurFer Because these workers are long-running inherently, I preferred ScaledJob to ScaledObject naturally. This section concerned me as pods can be terminated unexpectedly in terms of ScaledObject. Getting back to ScaledJob, let's imagine a case with 3 running pods and another 3 messages standing in line, and each of them takes 3 hours or even longer to run. Does it sound better if we empty the queue and run 6 pods in parallel within our affordable limit which is 10 replicas? |
You are right, ScaledJob is the best fit for your use case. |
@JorTurFer You are correct. Thanks for the solution. I will try it out. |
We should revisit the scaling behavior for ScaledJob as that ^ is something that should be doable. |
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. |
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 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. |
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. |
Proposal
KEDA doesn't scale up job number to the max according to this piece of description and information around. But in our case, we want to launch as many jobs as possible and keep the queue as empty. So, can we have an Eager mode in addition so users like me can shorten the waiting time in general?
Use-Case
We want to launch as many jobs as possible and keep the queue as empty.
Is this a feature you are interested in implementing yourself?
Maybe
Anything else?
No response
The text was updated successfully, but these errors were encountered: