koord-scheduler: NodeNUMAResource supports filtering/scoring with node-level amplification ratios #1677
Conversation
…e-level amplification ratios Signed-off-by: Joseph <[email protected]>
eahydra
requested review from
hormes,
FillZpp,
ZiMengSheng,
saintube and
jasonliu747
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #1677 +/- ##
==========================================
+ Coverage 66.05% 66.11% +0.05%
==========================================
Files 384 384
Lines 41454 41519 +65
==========================================
+ Hits 27384 27451 +67
+ Misses 12059 12046 -13
- Partials 2011 2022 +11
Flags with carried forward coverage won't be shown. Click here to find out more.
☔ View full report in Codecov by Sentry. |
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: hormes The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
| } | ||
|
|
||
| node := nodeInfo.Node() | ||
| ratios, err := extension.GetNodeResourceAmplificationRatios(node.Annotations) |
There was a problem hiding this comment.
Nit: We can call the convenience method cpuAmplificationRatio, err := extension.GetNodeResourceAmplificationRatio(node.Annotations, corev1.ResourceCPU) here
| func (p *Plugin) scoreWithAmplifiedCPUs(cycleState *framework.CycleState, state *preFilterState, pod *corev1.Pod, nodeInfo *framework.NodeInfo, topologyOptions TopologyOptions) (int64, *framework.Status) { | ||
| quantity := state.requests[corev1.ResourceCPU] | ||
| if quantity.IsZero() { | ||
| return 0, nil |
There was a problem hiding this comment.
I think we should call the default scorer here rather than return 0 to keep the same behavior as the NodeResourceFit plugin.
Ⅰ. Describe what this PR does
Based on #1602, implement amplified CPU filtering/scoring in plugin NodeNUMAResource.
After a detailed discussion with @zqzten, the author of #1602, the core goal of #1602 is to consider that if there is a LSE/LSR Pod on a node with a CPU amplification ratio, the corresponding CPU requests must be amplified to ensure the runtime QoS of the LSE/LSR Pod. Of course, it can also work to implement a new plugin separately, but it is more reasonable to implement it in the NodeNUMAResource plugin, because the NodeNUMAResource plugin supports allocating CPU cores to LSE/LSR Pods. Therefore, in the Filter stage, the requested amount and the allocated amount are amplified (prerequisite is LSE/LSR Pod) to ensure that the capacity is legal; the situation is similar in the scoring stage.
Ⅱ. Does this pull request fix one issue?
part of #1539
Ⅲ. Describe how to verify it
Ⅳ. Special notes for reviews
V. Checklist
make test