Volcano scheduling involves node filtering and scoring, which is used to filter the nodes meeting scheduling conditions and score the filtered nodes to find the one with the highest score for scheduling. Volcano provides multiple scheduling policies for node scoring. The weight of each scheduling policy can be adjusted based on service scenarios to enhance or reduce the impact of the policy on node scoring.
The following table lists the scheduling policies supported by Volcano for node scoring.
Scheduling Policy |
Parameter |
Description |
Reference |
|---|---|---|---|
Bin packing |
binpack.weight |
After this function is enabled, the parameter defaults to 10. |
|
kube-scheduler node sorting (nodeorder) |
nodeaffinity.weight |
Pods are scheduled based on node affinity. The parameter defaults to 2. |
By default, this function is enabled. |
podaffinity.weight |
Pods are scheduled based on pod affinity. The parameter defaults to 2. |
||
leastrequested.weight |
Pods are scheduled to the node with the least requested resources. The parameter defaults to 1. |
||
balancedresource.weight |
Pods are scheduled to the node with balanced resource allocation. The parameter defaults to 1. |
||
mostrequested.weight |
Pods are scheduled to the node with the most requested resources. The parameter defaults to 0. |
||
tainttoleration.weight |
Pods are scheduled to the node with a high taint tolerance. The parameter defaults to 3. |
||
imagelocality.weight |
Pods are scheduled to the node where the required images exist. The parameter defaults to 1. |
||
selectorspread.weight |
Pods are evenly scheduled to different nodes. The parameter defaults to 0. |
||
podtopologyspread.weight |
Pods are scheduled based on the pod topology. The parameter defaults to 2. |
||
NUMA affinity scheduling (numa-aware) |
weight |
After this function is enabled, the parameter defaults to 1. |
|
Load-aware scheduling (usage) |
weight |
After this function is enabled, the parameter defaults to 5. |
|
Node pool affinity scheduling (nodepoolaffinity) |
nodepoolaffinity.weight |
After this function is enabled, the parameter defaults to 10000. |
There are both heavy- and low-resource jobs running in a cluster. It is hoped that the low-resource job preferentially uses resource fragments on each node so that idle nodes can be allocated to the high-resource job. This prevents job scheduling failures caused by insufficient node resources.
To resolve the preceding issue, enable bin packing and use the default policy weight 10. For details, see Bin Packing.
Recommended configurations:
When a workload is running, the CPU and memory resources used may differ greatly from what was initially requested. To avoid any issues caused by overloading a single node, it is hoped that the scheduler preferentially schedules pods to the nodes with lighter loads based on nodes' CPU and memory usage in the cluster. This balances loads between nodes and ensures the stability of both applications and nodes.
Configuration case 1
Recommended configurations:
Configuration case 2
The status, workload traffic, and requests of a cluster change dynamically, and the resource usage of nodes changes in real time. Node imbalancing may recur after pod scheduling. Use both load-aware scheduling and descheduling for the optimal load balancing of cluster nodes. For details about hotspot descheduling, see Descheduling.
Recommended configurations: