-
Notifications
You must be signed in to change notification settings - Fork 39k
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
to add a feasible nodes cache for same type of pods in same workload #124949
Comments
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the The Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
/sig node |
Which component do you want to implement this functionality in, is it the schdeuler? And If podAffinity is present, the distribution of pods in the deployment will be affected. |
even through same type of pods in same workload, if set |
/sig scheduling I think I can understand some of what you're trying to do. However, the maintaining of this cache will also increase the burden on the scheduler, and brings additional complexity to the framework. |
all pods in a deployment have same predicate condition, include podAffinity, right? |
|
Yes, it is a heavy work. I just throw out this question and we can discuss it.
Some other schedulers based on kubernetes have this feature. |
Can you paste a reference here? :) |
Does this feature look like |
such as the godel-scheduler in bytedance's recent paper described. |
What would you like to be added?
A cached feasible nodes list for a worklode, eg, deployment.
Why is this needed?
As predicating is a time consume step, especially in a large cluster.
And as we know, same type of pods in a workload have same constraint, such as deployment's pod, Job's replicas.
So the first pod's feasible nodes list is aslo available for the other pods in a workload.
Choose one from the cached nodes will save much time than re-run a predicating for next pod.
The same does the cache with a node list predicating failed.
Maybe it is more significant when scheduling a batch pods with gang-scheduling or co-scheduling policy.
The text was updated successfully, but these errors were encountered: