[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

Preview 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

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten