From c7ab858d7e36f6550a2534f7d659644ea0cba6d2 Mon Sep 17 00:00:00 2001 From: Adrian Otto Date: Thu, 26 Apr 2018 12:21:26 -0700 Subject: [PATCH] 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" --- docs/concepts/configuration/assign-pod-node.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/concepts/configuration/assign-pod-node.md b/docs/concepts/configuration/assign-pod-node.md index 310564813f..c48c01ee11 100644 --- a/docs/concepts/configuration/assign-pod-node.md +++ b/docs/concepts/configuration/assign-pod-node.md @@ -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.