[trimaran.targetloadpacking]: Hot Issues in continuous scheduling

[ShyunnY]

Background:
I am currently using the trimaran.targetloadpacking scheduler plugin. Because my current scenario will encounter multiple Pods being scheduled continuously at a certain point in time. The targetloadpacking plugin uses metricsWatch + eventHandler to avoid hot spots, but this seems to have limitations.
In the case of large-scale pod continuous scheduling, perhaps the previous pod has just experienced the SchedulerCycle and is still waiting for the Bind operation in the background. At this time, EventHandler cannot observe and draw conclusions (because the Pod is not actually bound to the node).

Idea:
Can we introduce a simple flag in targetloadpacking to identify the NodeName bound to the previous round of Pods? When calculating the Node score, if the current Node is the Node that was scheduled in the previous round, we will appropriately reduce the score.

Tasks

Beta Give feedback

No tasks being tracked yet.

[binacs]

/cc

In fact, the root of the problem is that "plugins are not aware of scheduling decisions based on memory operations."

More precisely: after the scheduler completes the scheduling algorithm and before handle the binding event, all Assume behaviors cannot have their due impact on the execution logic of the plugins (not just trimaran.targetloadpacking).

We should provide plug-in-granular universal storage in the scheduler's cache to eliminate such problems.

[ShyunnY]

@binacs SGTM, if possible, I would like to work on this together