From 09f67a02b08d7be2c9e133e8668df84b1db1f30b Mon Sep 17 00:00:00 2001 From: AdamDang Date: Mon, 5 Mar 2018 23:33:51 +0800 Subject: [PATCH] Typo fix some "pod to schedule on"->"pod to be scheduled on" (#7637) Pod is the object to be scheduled, So "pod to schedule onto a node " and "pod to schedule on" are not suitable in the doc. "pod to be scheduled onto a node" is better. --- docs/concepts/configuration/assign-pod-node.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/concepts/configuration/assign-pod-node.md b/docs/concepts/configuration/assign-pod-node.md index b1291efc45..a99896a2ac 100644 --- a/docs/concepts/configuration/assign-pod-node.md +++ b/docs/concepts/configuration/assign-pod-node.md @@ -100,11 +100,11 @@ everything that `nodeSelector` can express. Node affinity was introduced as alpha in Kubernetes 1.2. Node affinity is conceptually similar to `nodeSelector` -- it allows you to constrain which nodes your -pod is eligible to schedule on, based on labels on the node. +pod is eligible to be scheduled on, based on labels on the node. There are currently two types of node affinity, called `requiredDuringSchedulingIgnoredDuringExecution` and `preferredDuringSchedulingIgnoredDuringExecution`. You can think of them as "hard" and "soft" respectively, -in the sense that the former specifies rules that *must* be met for a pod to schedule onto a node (just like +in the sense that the former specifies rules that *must* be met for a pod to be scheduled onto a node (just like `nodeSelector` but using a more expressive syntax), while the latter specifies *preferences* that the scheduler will try to enforce but will not guarantee. The "IgnoredDuringExecution" part of the names means that, similar to how `nodeSelector` works, if labels on a node change at runtime such that the affinity rules on a pod are no longer @@ -177,14 +177,14 @@ And inter-pod anti-affinity is specified as field `podAntiAffinity` of field `af The affinity on this pod defines one pod affinity rule and one pod anti-affinity rule. In this example, the `podAffinity` is `requiredDuringSchedulingIgnoredDuringExecution` while the `podAntiAffinity` is `preferredDuringSchedulingIgnoredDuringExecution`. The -pod affinity rule says that the pod can schedule onto a node only if that node is in the same zone +pod affinity rule says that the pod can be scheduled onto a node only if that node is in the same zone as at least one already-running pod that has a label with key "security" and value "S1". (More precisely, the pod is eligible to run on node N if node N has a label with key `failure-domain.beta.kubernetes.io/zone` and some value V such that there is at least one node in the cluster with key `failure-domain.beta.kubernetes.io/zone` and value V that is running a pod that has a label with key "security" and value "S1".) The pod anti-affinity -rule says that the pod prefers to not schedule onto a node if that node is already running a pod with label +rule says that the pod prefers not to be scheduled onto a node if that node is already running a pod with label having key "security" and value "S2". (If the `topologyKey` were `failure-domain.beta.kubernetes.io/zone` then -it would mean that the pod cannot schedule onto a node if that node is in the same zone as a pod with +it would mean that the pod cannot be scheduled onto a node if that node is in the same zone as a pod with label having key "security" and value "S2".) See the [design doc](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md). For many more examples of pod affinity and anti-affinity, both the `requiredDuringSchedulingIgnoredDuringExecution` flavor and the `preferredDuringSchedulingIgnoredDuringExecution` flavor. @@ -206,7 +206,7 @@ If omitted, it defaults to the namespace of the pod where the affinity/anti-affi If defined but empty, it means "all namespaces." All `matchExpressions` associated with `requiredDuringSchedulingIgnoredDuringExecution` affinity and anti-affinity -must be satisfied for the pod to schedule onto a node. +must be satisfied for the pod to be scheduled onto a node. #### More Practical Use-cases