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

Fix inconsistency in pod anti-affinity example.

Browse Source 
It looks like a previous version of the anti-affinity code in this example had `topologyKey: node`.
This commit is contained in:
muldoon2007
2020-05-22 18:40:46 -07:00
committed by GitHub
parent 486d8f5304
commit 5ca114cb85
1 changed files with 2 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/concepts/scheduling-eviction/assign-pod-node.md
+2 -4
View File
@@ -213,10 +213,8 @@ as at least one already-running pod that has a label with key "security" and val
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 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 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
rule says 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.