<p>Does the Kubernetes scheduler place the pods on the nodes only based on their requested resources and nodes' available resources at the current snapshot of the server or it also takes into account the node's historical resource utilization?</p>

Saeid Ghafouri
<p>In the official <a href="https://kubernetes.io/docs/concepts/scheduling-eviction/kube-scheduler/" rel="nofollow noreferrer">Kubernetes documentation</a> we can find process and metrics used by <code>kube-scheduler</code> for choosing node for pod.</p>
<p>Basically this is 2-step process:</p>
<blockquote>
<p>kube-scheduler selects a node for the pod in a 2-step operation:</p>
<ol>
<li>Filtering</li>
<li>Scoring</li>
</ol>
</blockquote>
<p><em>Filtering</em> step is responsible for getting list of nodes which actually are able to run a pod:</p>
<blockquote>
<p>The <em>filtering</em> step finds the set of Nodes where it's feasible to schedule the Pod. For example, the PodFitsResources filter checks whether a candidate Node has enough available resource to meet a Pod's specific resource requests. After this step, the node list contains any suitable Nodes; often, there will be more than one. If the list is empty, that Pod isn't (yet) schedulable.</p>
</blockquote>
<p><em>Scoring</em> step is responsible for choosing the best node from the list generated by the <em>filtering</em> step:</p>
<blockquote>
<p>In the  <em>scoring</em>  step, the scheduler ranks the remaining nodes to choose the most suitable Pod placement. The scheduler assigns a score to each Node that survived filtering, basing this score on the active scoring rules.</p>
</blockquote>
<blockquote>
<p>Finally, kube-scheduler assigns the Pod to the Node with the highest ranking. If there is more than one node with equal scores, kube-scheduler selects one of these at random.</p>
</blockquote>
<p>When the node with the highest score is chosen, scheduler notifies the API server:</p>
<blockquote>
<p>...picks a Node with the highest score among the feasible ones to run the Pod. The scheduler then notifies the API server about this decision in a process called <em>binding</em>.</p>
</blockquote>
<p><a href="https://kubernetes.io/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler" rel="nofollow noreferrer">Factors that are taken into consideration for scheduling</a>:</p>
<ul>
<li>Individual and collective resource requirements</li>
<li>Hardware</li>
<li>Policy constraints</li>
<li>Affinity and anti-affinity specifications</li>
<li>Data locality</li>
<li>Inter-workload interference</li>
<li>Others...</li>
</ul>
<p>More detailed information about parameters be found <a href="https://kubernetes.io/docs/reference/scheduling/policies/" rel="nofollow noreferrer">here</a>:</p>
<blockquote>
<p>The following  <em>predicates</em>  implement filtering:</p>
<ul>
<li><code>PodFitsHostPorts</code>: Checks if a Node has free ports (the network protocol kind) for the Pod ports the Pod is requesting.</li>
<li><code>PodFitsHost</code>: Checks if a Pod specifies a specific Node by its hostname.</li>
<li><code>PodFitsResources</code>: Checks if the Node has free resources (eg, CPU and Memory) to meet the requirement of the Pod.</li>
<li><code>MatchNodeSelector</code>: Checks if a Pod's Node  <a href="https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/" rel="nofollow noreferrer">Selector</a>  matches the Node's  <a href="https://kubernetes.io/docs/concepts/overview/working-with-objects/labels" rel="nofollow noreferrer">label(s)</a>.</li>
<li><code>NoVolumeZoneConflict</code>: Evaluate if the  <a href="https://kubernetes.io/docs/concepts/storage/volumes/" rel="nofollow noreferrer">Volumes</a>  that a Pod requests are available on the Node, given the failure zone restrictions for that storage.</li>
<li><code>NoDiskConflict</code>: Evaluates if a Pod can fit on a Node due to the volumes it requests, and those that are already mounted.</li>
<li><code>MaxCSIVolumeCount</code>: Decides how many  <a href="https://kubernetes.io/docs/concepts/storage/volumes/#csi" rel="nofollow noreferrer">CSI</a>  volumes should be attached, and whether that's over a configured limit.</li>
<li><code>PodToleratesNodeTaints</code>: checks if a Pod's  <a href="https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/" rel="nofollow noreferrer">tolerations</a>  can tolerate the Node's  <a href="https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/" rel="nofollow noreferrer">taints</a>.</li>
<li><code>CheckVolumeBinding</code>: Evaluates if a Pod can fit due to the volumes it requests. This applies for both bound and unbound  <a href="https://kubernetes.io/docs/concepts/storage/persistent-volumes/" rel="nofollow noreferrer">PVCs</a>.</li>
</ul>
</blockquote>
<blockquote>
<p>The following  <em>priorities</em>  implement scoring:</p>
<ul>
<li><code>SelectorSpreadPriority</code>: Spreads Pods across hosts, considering Pods that belong to the same  <a href="https://kubernetes.io/docs/concepts/services-networking/service/" rel="nofollow noreferrer">Service</a>,  <a href="https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/" rel="nofollow noreferrer">StatefulSet</a>  or  <a href="https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/" rel="nofollow noreferrer">ReplicaSet</a>.</li>
<li><code>InterPodAffinityPriority</code>: Implements preferred  <a href="https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity" rel="nofollow noreferrer">inter pod affininity and antiaffinity</a>.</li>
<li><code>LeastRequestedPriority</code>: Favors nodes with fewer requested resources. In other words, the more Pods that are placed on a Node, and the more resources those Pods use, the lower the ranking this policy will give.</li>
<li><code>MostRequestedPriority</code>: 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.</li>
<li><code>RequestedToCapacityRatioPriority</code>: Creates a requestedToCapacity based ResourceAllocationPriority using default resource scoring function shape.</li>
<li><code>BalancedResourceAllocation</code>: Favors nodes with balanced resource usage.</li>
<li><code>NodePreferAvoidPodsPriority</code>: Prioritizes nodes according to the node annotation  <code>scheduler.alpha.kubernetes.io/preferAvoidPods</code>. You can use this to hint that two different Pods shouldn't run on the same Node.</li>
<li><code>NodeAffinityPriority</code>: Prioritizes nodes according to node affinity scheduling preferences indicated in PreferredDuringSchedulingIgnoredDuringExecution. You can read more about this in  <a href="https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/" rel="nofollow noreferrer">Assigning Pods to Nodes</a>.</li>
<li><code>TaintTolerationPriority</code>: Prepares the priority list for all the nodes, based on the number of intolerable taints on the node. This policy adjusts a node's rank taking that list into account.</li>
<li><code>ImageLocalityPriority</code>: Favors nodes that already have the  <a href="https://kubernetes.io/docs/reference/glossary/?all=true#term-image" rel="nofollow noreferrer">container images</a>  for that Pod cached locally.</li>
<li><code>ServiceSpreadingPriority</code>: For a given Service, this policy aims to make sure that the Pods for the Service run on different nodes. It favours scheduling onto nodes that don't have Pods for the service already assigned there. The overall outcome is that the Service becomes more resilient to a single Node failure.</li>
<li><code>EqualPriority</code>: Gives an equal weight of one to all nodes.</li>
<li><code>EvenPodsSpreadPriority</code>: Implements preferred  <a href="https://kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/" rel="nofollow noreferrer">pod topology spread constraints</a>.</li>
</ul>
</blockquote>
<p>Answering your question:</p>
<blockquote>
<p>Does it take into account the node's historical resource utilization?</p>
</blockquote>
<p>As can see, on the above list there are no parameters related to the historical resource utilization. Also, I did research and I didn't find any information about it.</p>
