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

Changed inter-pod affinity section (#15427)

Browse Source 
Clarified pod affinity section as it was confusing to understand whether or not a list of namespaces was optional or needed with LabelSelectors.
This commit is contained in:
Saish Dharvotkar
2019-07-18 20:34:11 +10:00
committed by Kubernetes Prow Robot
parent 96922f3b73
commit b14752b288
1 changed files with 1 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/concepts/configuration/assign-pod-node.md
+1 -1
View File
@@ -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