-
Notifications
You must be signed in to change notification settings - Fork 198
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
Support Scheduling Priority and Preemption #763
Comments
@abstractmj Nice proposal. This is exactly what we've planned to do.
|
Thank you for your suggestion. As you mentioned, the second design indeed seems more like a rebalance process. I haven't learned much about FailOver before, so I will study it to see if it can replace the descheduler logic I implemented previously. Following the idea of the first design, the priority scheduling is relatively simple. I think it can be divided into the following two tasks: (1) add a priority field in the subscription, and (2) add a priority queue in the scheduler. On this basis, we can further extend the priority queue and scheduler plugin to implement preemptive scheduling logic. If possible, I can provide a more detailed design of the preemptive scheduling logic. |
@abstractmj Looks good to me. Please go ahead. |
What would you like to be added:
Support Scheduling Priority and Preemption
Why is this needed:
To further improve the packing rate and resource utilization of the cluster, we usually divide tasks into high-priority tasks and low-priority tasks, and deploy them in a mixed manner. When the cluster is idle, low-priority tasks can make full use of cluster resources, while high-priority tasks can preempt low-priority task resources to meet the needs of high-priority tasks. In a single Kubernetes cluster, the community provides the pod priority feature to implement the scheduling priority of pods, and also implements preemptive scheduling of pods in the kube-scheduler based on priority.
When we move the application deployment process to a multi-cluster level, such scenarios still exist. However, in the current Clusternet multi-cluster application management mechanism, no similar capabilities are provided.
The entire requirement can be divided into two parts: "scheduling priority" and "preemptive scheduling".
"Scheduling Priority" implementation:
Add a scheduling priority field in the subscription
Add a priority queue in the scheduler. After the scheduler listens to the subscription changes, it puts them into the priority queue and dequeues them according to priority.
"preemptive scheduling"
There are two implementation ideas for "preemptive scheduling":
Idea 1: Implement subscription preemption;
Idea 2: Rely on single-cluster preemption logic;
btw: I prefer idea 1
The text was updated successfully, but these errors were encountered: