From b14752b2888271e1605510afc28d44644de1fd00 Mon Sep 17 00:00:00 2001 From: Saish Dharvotkar Date: Thu, 18 Jul 2019 20:34:11 +1000 Subject: [PATCH] Changed inter-pod affinity section (#15427) Clarified pod affinity section as it was confusing to understand whether or not a list of namespaces was optional or needed with LabelSelectors. --- content/en/docs/concepts/configuration/assign-pod-node.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/configuration/assign-pod-node.md b/content/en/docs/concepts/configuration/assign-pod-node.md index 2fc54d772a..f5ddccc080 100644 --- a/content/en/docs/concepts/configuration/assign-pod-node.md +++ b/content/en/docs/concepts/configuration/assign-pod-node.md @@ -173,7 +173,7 @@ The `weight` field in `preferredDuringSchedulingIgnoredDuringExecution` is in th Inter-pod affinity and anti-affinity allow you to constrain which nodes your pod is eligible to be scheduled *based on labels on pods that are already running on the node* rather than based on labels on nodes. The rules are of the form "this pod should (or, in the case of anti-affinity, should not) run in an X if that X is already running one or more pods that meet rule Y". -Y is expressed as a LabelSelector with an associated list of namespaces; unlike nodes, because pods are namespaced +Y is expressed as a LabelSelector with an optional associated list of namespaces; unlike nodes, because pods are namespaced (and therefore the labels on pods are implicitly namespaced), a label selector over pod labels must specify which namespaces the selector should apply to. Conceptually X is a topology domain like node, rack, cloud provider zone, cloud provider region, etc. You express it using a `topologyKey` which is the