kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Clarify that node anti-affinity can be achieved using node taints (#8117) 

* Clarify that node anti-affinity can be achieved using node taints

The current text may have pre-dated the node taints feature, so it says that no such concept exists, when it actually does now.

* add "to"
pull/8200/head
Adrian Otto 2018-04-26 12:21:26 -07:00 committed by k8s-ci-robot
parent 1cd6d00bc6
commit c7ab858d7e
1 changed files with 2 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
docs/concepts/configuration/assign-pod-node.md
View File

@ -133,7 +133,8 @@ among nodes that meet that criteria, nodes with a label whose key is `another-no
value is `another-node-label-value` should be preferred.
You can see the operator `In` being used in the example. The new node affinity syntax supports the following operators: `In`, `NotIn`, `Exists`, `DoesNotExist`, `Gt`, `Lt`.
There is no explicit "node anti-affinity" concept, but `NotIn` and `DoesNotExist` give that behavior.
You can use `NotIn` and `DoesNotExist` to achieve node anti-affinity behavior, or use
[node taints](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) to repel pods from specific nodes.
If you specify both `nodeSelector` and `nodeAffinity`, *both* must be satisfied for the pod
to be scheduled onto a candidate node.