Trimaran TargetLoadPacking: PredictUtilisation based on CPU requests

[Moscagus]

The PredictUtilisation function does not respect the documentation:

Algorithm
2. Calculate the current pod's total CPU requests and overhead. Call it B.
...
Bad Metrics
i. Short inter-arrival times of pods: In this case, we predict utilization for the recent pods that got scheduled on the node based on its request values and a multiplier, and add it to the current utilization. If the pods belong to best-effort QoS, i.e. don't have requests, we assume a number like 1 milicore which is configurable.

Function PredictUtilisation
https://github.com/kubernetes-sigs/scheduler-plugins/blob/master/pkg/trimaran/targetloadpacking/targetloadpacking.go#L199

func PredictUtilisation(container *v1.Container) int64 {
        if _, ok := container.Resources.Limits[v1.ResourceCPU]; ok {
		return container.Resources.Limits.Cpu().MilliValue()
	} else if _, ok := container.Resources.Requests[v1.ResourceCPU]; ok {
		return int64(math.Round(float64(container.Resources.Requests.Cpu().MilliValue()) * requestsMultiplier))
	}
	return requestsMilliCores
}

Background:
"PredictUtilisation" uses the CPU limit and not the CPU request as the first alternative. This means that if pods have high CPU limits due to generic LimitRanges resources and there are short inter-arrival times of pods, the node almost always returns framework.MinNodeScore.
It would be good to add a flag that indicates which value to use, CPU request or CPU limit, the default being CPU limit to respect the current code.
With this change, what is in the plugin documentation would also be respected.

For example in pseudocode:

func PredictUtilisation(container *v1.Container) int64 {
      if useResourcesLimitsCpu == true 
         if _, ok := container.Resources.Limits[v1.ResourceCPU]; ok {
            return container.Resources.Limits.Cpu().MilliValue()
	 } else if _, ok := container.Resources.Requests[v1.ResourceCPU]; ok {
	    return int64(math.Round(float64(container.Resources.Requests.Cpu().MilliValue()) * requestsMultiplier))
	 }
      else
	 if _, ok := container.Resources.Requests[v1.ResourceCPU]; ok {
	    return int64(math.Round(float64(container.Resources.Requests.Cpu().MilliValue()) * requestsMultiplier))
         } else if _, ok := container.Resources.Limits[v1.ResourceCPU]; ok {
	    return container.Resources.Limits.Cpu().MilliValue()
	 }
     endif

     return requestsMilliCores
}

[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