What is the problem you're trying to solve
/kind feature
Volcano has supported network topology aware scheduling in the member cluster: https://volcano.sh/en/docs/network_topology_aware_scheduling/. However, in multi-cluster systems like Karmada, the Karmada scheduler lacks network topology awareness during scheduling. This can lead to a situation where the Karmada scheduler determines the workload can be successfully dispatched, but in the member clusters, the Volcano scheduler fails to schedule the workload due to network topology constraints, leaving the workload still pending. Therefore, we need the upper-layer control cluster to be aware of this. In the Karmada ecosystem, this would likely involve adding a component called the Volcano estimator.
Describe the solution you'd like
Currently, we only support Karmada as the multi-cluster system, we can add a Volcano estimator, to support network topology aware scheduling in the control cluster
Additional context
No response
What is the problem you're trying to solve
/kind feature
Volcano has supported network topology aware scheduling in the member cluster: https://volcano.sh/en/docs/network_topology_aware_scheduling/. However, in multi-cluster systems like Karmada, the Karmada scheduler lacks network topology awareness during scheduling. This can lead to a situation where the Karmada scheduler determines the workload can be successfully dispatched, but in the member clusters, the Volcano scheduler fails to schedule the workload due to network topology constraints, leaving the workload still pending. Therefore, we need the upper-layer control cluster to be aware of this. In the Karmada ecosystem, this would likely involve adding a component called the Volcano estimator.
Describe the solution you'd like
Currently, we only support Karmada as the multi-cluster system, we can add a Volcano estimator, to support network topology aware scheduling in the control cluster
Additional context
No response