<p>// I'm almost certain this must be a dup or at least a solved problem, but I could not find what I was after through searching the many k8 communities.</p>

<p>We have jobs that run for between a minute and many hours. Given that we assign them resource values that afford them QOS Guaranteed status, how could we minimize resource waste across the nodes?</p>

<p>The problem is that downscaling rarely happens, because each node eventually gets assigned one of the long running jobs. They are not common, but the keep all of the nodes running, even when we do not have need for them.</p>

<p>The dumb strategy that seems to avoid this would be a depth first scheduling algorithm, wherein among nodes that have capacity, the one most filled already will be assigned. In other words, if we have two total nodes running at 90% cpu/memory usage and 10% cpu/memory assigned, the 90% would always be assigned first provided it has sufficient capacity.</p>

<p>Open to any input here and/or ideas. Thanks kindly.</p>

A D
<p>As of now there seems to be this <a href="https://kubernetes.io/docs/reference/scheduling/profiles/#scheduling-plugins" rel="nofollow noreferrer">kube-sheduler profile plugin</a>:</p>

<blockquote>
  <p><strong>NodeResourcesMostAllocated</strong>: Favors nodes that have a high allocation of resources. </p>
</blockquote>

<p>But it is in alpha stage since k8s v1.18+, so probably not safe to use it for produciton.</p>

<hr>

<p>There is also this parameter you can set for kube-scheduler that I have found <a href="https://kubernetes.io/docs/reference/scheduling/#priorities" rel="nofollow noreferrer">here</a>:</p>

<blockquote>
  <p><strong>MostRequestedPriority</strong>: Favors nodes with most requested resources. This policy will fit the scheduled Pods onto the smallest number of Nodes needed to run your overall set of workloads.</p>
</blockquote>

<p>and <a href="https://version.cs.vt.edu/aakashg/jupyterhub/blob/7e14c702626c64e61a78ac1e90a2e510684a5a77/jupyterhub/templates/scheduling/user-scheduler/configmap.yaml" rel="nofollow noreferrer">here is an example</a> on how to configure it.</p>

<hr>

<p>One last thing that comes to my mind is using <a href="https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity" rel="nofollow noreferrer">node affinity</a>.
Using nodeAffinity on long running pods, (more specificaly with <code>preferredDuringSchedulingIgnoredDuringExecution</code>), will prefer to schedule these pods on the nodes that run all the time, and prefer to not schedule them on nodes that are being autoscaled. This approach requires excluding some nodes from autoscaling and labeling approprietly so that scheduler can make use of node-affinity.</p>
