whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Fix typos in Kube Scheduler (#17667)

Browse Source
This commit is contained in:
Pablo Castellano
2019-11-21 11:09:28 +01:00
committed by Kubernetes Prow Robot
parent 9afc68d402
commit ace8401e2d
1 changed files with 6 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/concepts/scheduling/kube-scheduler.md
+6 -6
View File
@@ -88,7 +88,7 @@ kube-scheduler has a default set of scheduling policies.
- `PodFitsHostPorts`: Checks if a Node has free ports (the network protocol kind) - `PodFitsHostPorts`: Checks if a Node has free ports (the network protocol kind)
for the Pod ports the Pod is requesting. for the Pod ports the Pod is requesting.
- `PodFitsHost`: Checks if a Pod specifies a specific Node by it hostname. - `PodFitsHost`: Checks if a Pod specifies a specific Node by its hostname.
- `PodFitsResources`: Checks if the Node has free resources (eg, CPU and Memory) - `PodFitsResources`: Checks if the Node has free resources (eg, CPU and Memory)
to meet the requirement of the Pod. to meet the requirement of the Pod.
@@ -126,12 +126,12 @@ kube-scheduler has a default set of scheduling policies.
- `CheckVolumeBinding`: Evaluates if a Pod can fit due to the volumes it requests. - `CheckVolumeBinding`: Evaluates if a Pod can fit due to the volumes it requests.
This applies for both bound and unbound This applies for both bound and unbound
{{< glossary_tooltip text="PVCs" term_id="persistent-volume-claim" >}} {{< glossary_tooltip text="PVCs" term_id="persistent-volume-claim" >}}.
### Scoring ### Scoring
- `SelectorSpreadPriority`: Spreads Pods across hosts, considering Pods that - `SelectorSpreadPriority`: Spreads Pods across hosts, considering Pods that
belonging to the same {{< glossary_tooltip text="Service" term_id="service" >}}, belong to the same {{< glossary_tooltip text="Service" term_id="service" >}},
{{< glossary_tooltip term_id="statefulset" >}} or {{< glossary_tooltip term_id="statefulset" >}} or
{{< glossary_tooltip term_id="replica-set" >}}. {{< glossary_tooltip term_id="replica-set" >}}.
@@ -152,13 +152,13 @@ kube-scheduler has a default set of scheduling policies.
- `BalancedResourceAllocation`: Favors nodes with balanced resource usage. - `BalancedResourceAllocation`: Favors nodes with balanced resource usage.
- `NodePreferAvoidPodsPriority`: Priorities nodes according to the node annotation - `NodePreferAvoidPodsPriority`: Prioritizes nodes according to the node annotation
`scheduler.alpha.kubernetes.io/preferAvoidPods`. You can use this to hint that `scheduler.alpha.kubernetes.io/preferAvoidPods`. You can use this to hint that
two different Pods shouldn't run on the same Node. two different Pods shouldn't run on the same Node.
- `NodeAffinityPriority`: Prioritizes nodes according to node affinity scheduling - `NodeAffinityPriority`: Prioritizes nodes according to node affinity scheduling
preferences indicated in PreferredDuringSchedulingIgnoredDuringExecution. preferences indicated in PreferredDuringSchedulingIgnoredDuringExecution.
You can read more about this in [Assigning Pods to Nodes](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/) You can read more about this in [Assigning Pods to Nodes](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/).
- `TaintTolerationPriority`: Prepares the priority list for all the nodes, based on - `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 the number of intolerable taints on the node. This policy adjusts a node's rank
@@ -169,7 +169,7 @@ kube-scheduler has a default set of scheduling policies.
Pod cached locally. Pod cached locally.
- `ServiceSpreadingPriority`: For a given Service, this policy aims to make sure that - `ServiceSpreadingPriority`: For a given Service, this policy aims to make sure that
the Pods for the Service run on different nodes. It favouring scheduling onto nodes 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 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. that the Service becomes more resilient to a single Node failure.