You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What would you like to be added:
Support scheduling based on node load. Nodes with low load are allocated first, and when the load reaches a safe threshold, consideration should be given not to continue allocation.
We can also consider supporting the ability of portraits to describe the resource usage of different workloads, and to guide the scheduler to achieve finer load balancing through portrait data.
By the way, in the actual production environment, the load of the node will not increase quickly and can be quickly perceived by the scheduler. In the case of no portrait, we should consider providing a mechanism to deal with this scenario.
Why is this needed:
Koordinator allowing for resource overcommitments to achieve high resource utilizations. We must reduce the impact of co-location on latency-sensitive applications and improve runtime reliability.
The text was updated successfully, but these errors were encountered:
The scheduling plugin filters abnormal nodes and scores them according
to resource usage. The plugin extends the Filter/Score/Reserve/Unreserve
extension points defined in the Kubernetes scheduling framework.
FYI: docs/proposals/scheduling/20220510-load-aware-scheduling.md
Fixkoordinator-sh#95
Signed-off-by: Tao Li <joseph.t.lee@outlook.com>
The scheduling plugin filters abnormal nodes and scores them according
to resource usage. The plugin extends the Filter/Score/Reserve/Unreserve
extension points defined in the Kubernetes scheduling framework.
FYI: docs/proposals/scheduling/20220510-load-aware-scheduling.md
Fix#95
Signed-off-by: Tao Li <joseph.t.lee@outlook.com>
What would you like to be added:
Support scheduling based on node load. Nodes with low load are allocated first, and when the load reaches a safe threshold, consideration should be given not to continue allocation.
We can also consider supporting the ability of portraits to describe the resource usage of different workloads, and to guide the scheduler to achieve finer load balancing through portrait data.
By the way, in the actual production environment, the load of the node will not increase quickly and can be quickly perceived by the scheduler. In the case of no portrait, we should consider providing a mechanism to deal with this scenario.
Why is this needed:
Koordinator allowing for resource overcommitments to achieve high resource utilizations. We must reduce the impact of co-location on latency-sensitive applications and improve runtime reliability.
The text was updated successfully, but these errors were encountered: