Document using multiple scheduler profiles (#19172)
* Add instructions for using multiple scheduling profiles. Signed-off-by: Aldo Culquicondor <acondor@google.com> * Move scheduling policies and profiles to Reference Signed-off-by: Aldo Culquicondor <acondor@google.com> * Renames and nits Signed-off-by: Aldo Culquicondor <acondor@google.com> * Fix links and grammar Signed-off-by: Aldo Culquicondor <acondor@google.com> * Fix link and flag usage Signed-off-by: Aldo Culquicondor <acondor@google.com>
This commit is contained in:
Aldo Culquicondor
committed by
GitHub
GitHub
parent
615c7f619f
commit
d1056364e2
@@ -0,0 +1,125 @@
|
||||
---
|
||||
title: Scheduling Policies
|
||||
content_template: templates/concept
|
||||
weight: 10
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
A scheduling Policy can be used to specify the *predicates* and *priorities*
|
||||
that the {{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}
|
||||
runs to [filter and score nodes](/docs/concepts/scheduling/kube-scheduler/#kube-scheduler-implementation),
|
||||
respectively.
|
||||
|
||||
You can set a scheduling policy by running
|
||||
`kube-scheduler --policy-config-file <filename>` or
|
||||
`kube-scheduler --policy-configmap <ConfigMap>`
|
||||
and using the [Policy type](https://pkg.go.dev/k8s.io/kube-scheduler@v0.18.0/config/v1?tab=doc#Policy).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## Predicates
|
||||
|
||||
The following *predicates* implement filtering:
|
||||
|
||||
- `PodFitsHostPorts`: Checks if a Node has free ports (the network protocol kind)
|
||||
for the Pod ports the Pod is requesting.
|
||||
|
||||
- `PodFitsHost`: Checks if a Pod specifies a specific Node by its hostname.
|
||||
|
||||
- `PodFitsResources`: Checks if the Node has free resources (eg, CPU and Memory)
|
||||
to meet the requirement of the Pod.
|
||||
|
||||
- `PodMatchNodeSelector`: Checks if a Pod's Node {{< glossary_tooltip term_id="selector" >}}
|
||||
matches the Node's {{< glossary_tooltip text="label(s)" term_id="label" >}}.
|
||||
|
||||
- `NoVolumeZoneConflict`: Evaluate if the {{< glossary_tooltip text="Volumes" term_id="volume" >}}
|
||||
that a Pod requests are available on the Node, given the failure zone restrictions for
|
||||
that storage.
|
||||
|
||||
- `NoDiskConflict`: Evaluates if a Pod can fit on a Node due to the volumes it requests,
|
||||
and those that are already mounted.
|
||||
|
||||
- `MaxCSIVolumeCount`: Decides how many {{< glossary_tooltip text="CSI" term_id="csi" >}}
|
||||
volumes should be attached, and whether that's over a configured limit.
|
||||
|
||||
- `CheckNodeMemoryPressure`: If a Node is reporting memory pressure, and there's no
|
||||
configured exception, the Pod won't be scheduled there.
|
||||
|
||||
- `CheckNodePIDPressure`: If a Node is reporting that process IDs are scarce, and
|
||||
there's no configured exception, the Pod won't be scheduled there.
|
||||
|
||||
- `CheckNodeDiskPressure`: If a Node is reporting storage pressure (a filesystem that
|
||||
is full or nearly full), and there's no configured exception, the Pod won't be
|
||||
scheduled there.
|
||||
|
||||
- `CheckNodeCondition`: Nodes can report that they have a completely full filesystem,
|
||||
that networking isn't available or that kubelet is otherwise not ready to run Pods.
|
||||
If such a condition is set for a Node, and there's no configured exception, the Pod
|
||||
won't be scheduled there.
|
||||
|
||||
- `PodToleratesNodeTaints`: checks if a Pod's {{< glossary_tooltip text="tolerations" term_id="toleration" >}}
|
||||
can tolerate the Node's {{< glossary_tooltip text="taints" term_id="taint" >}}.
|
||||
|
||||
- `CheckVolumeBinding`: Evaluates if a Pod can fit due to the volumes it requests.
|
||||
This applies for both bound and unbound
|
||||
{{< glossary_tooltip text="PVCs" term_id="persistent-volume-claim" >}}.
|
||||
|
||||
## Priorities
|
||||
|
||||
The following *priorities* implement scoring:
|
||||
|
||||
- `SelectorSpreadPriority`: Spreads Pods across hosts, considering Pods that
|
||||
belong to the same {{< glossary_tooltip text="Service" term_id="service" >}},
|
||||
{{< glossary_tooltip term_id="statefulset" >}} or
|
||||
{{< glossary_tooltip term_id="replica-set" >}}.
|
||||
|
||||
- `InterPodAffinityPriority`: Implements preferred
|
||||
[inter pod affininity and antiaffinity](/docs/concepts/configuration/assign-pod-node/#inter-pod-affinity-and-anti-affinity).
|
||||
|
||||
- `LeastRequestedPriority`: 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.
|
||||
|
||||
- `MostRequestedPriority`: 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.
|
||||
|
||||
- `RequestedToCapacityRatioPriority`: Creates a requestedToCapacity based ResourceAllocationPriority using default resource scoring function shape.
|
||||
|
||||
- `BalancedResourceAllocation`: Favors nodes with balanced resource usage.
|
||||
|
||||
- `NodePreferAvoidPodsPriority`: Prioritizes nodes according to the node annotation
|
||||
`scheduler.alpha.kubernetes.io/preferAvoidPods`. You can use this to hint that
|
||||
two different Pods shouldn't run on the same Node.
|
||||
|
||||
- `NodeAffinityPriority`: Prioritizes nodes according to node affinity scheduling
|
||||
preferences indicated in PreferredDuringSchedulingIgnoredDuringExecution.
|
||||
You can read more about this in [Assigning Pods to Nodes](/docs/concepts/configuration/assign-pod-node/).
|
||||
|
||||
- `TaintTolerationPriority`: 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.
|
||||
|
||||
- `ImageLocalityPriority`: Favors nodes that already have the
|
||||
{{< glossary_tooltip text="container images" term_id="image" >}} for that
|
||||
Pod cached locally.
|
||||
|
||||
- `ServiceSpreadingPriority`: 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.
|
||||
|
||||
- `EqualPriority`: Gives an equal weight of one to all nodes.
|
||||
|
||||
- `EvenPodsSpreadPriority`: Implements preferred
|
||||
[pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
* Learn about [scheduling](/docs/concepts/scheduling/kube-scheduler/)
|
||||
* Learn about [kube-scheduler profiles](/docs/reference/scheduling/profiles/)
|
||||
{{% /capture %}}
|
||||
Reference in New Issue
Block a user