1. 亲缘性调度

通过给节点设置污点，可以让Pod选择容忍或者远离这些节点，那么通过设置节点亲缘性（node affinity），可以让Pod调度到特点的节点上，就像我住酒店会选择无烟房一样。在前面的课程我们使用Node Selector将Pod 运行在有制定标签的Node上，那么亲缘性调度可以理解为新一代的Node Selector，业务未来Node Selector会被完全弃用，因为亲缘性调度更加的强大，当然也更加的复杂。

1.1. Node 亲和性

Node亲和性在概念上类似于nodeSelector – 它能够基于node标签约束哪些pod能够被分配到node上。

目前有两种类型的node亲和性，叫做 requiredDuringSchedulingIgnoredDuringExecution 和 preferredDuringSchedulingIgnoredDuringExecution。您可以认为它们分别是 “硬性” 和 “软性” 的，即前者要求 pod 必须满足指定的规则才能调度到 node 上（就像 nodeSelector，但使用更具表达性的语法），后者指定 偏向，即让 scheduler 尝试但是不保证完全满足规则。

与 nodeSelector 工作方式类似，名称中的 “IgnoredDuringExecution” 部分意味着，如果一个 node 的标签在运行时发生改变，从而导致pod的亲和性规则不再被满足时，pod 也仍然会继续运行在 node 上。以后我们计划提供 requiredDuringSchedulingRequiredDuringExecution，这类似于 requiredDuringSchedulingIgnoredDuringExecution，但是它会从不再满足 pod 的 node 亲和性的 node 上驱逐 Pod。

因此 requiredDuringSchedulingIgnoredDuringExecution 的一个例子是 “只能在有 Intel CPU 的 node 上运行 pod”，preferredDuringSchedulingIgnoredDuringExecution 的例子是 “尝试在可用域 XYZ 的范围内运行 pod，但是如果不满足，那么也允许在其它地方运行 pod”。

没错，上面这段描述如果让你有点晕了，再次证明了Node 亲和性是真的比Node Selector复杂太多了！！！

apiVersion: v1
kind: Pod
metadata:
  name: with-node-affinity
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/e2e-az-name
            operator: In
            values:
            - e2e-az1
            - e2e-az2
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: another-node-label-key
            operator: In
            values:
            - another-node-label-value
  containers:
  - name: with-node-affinity
    image: k8s.gcr.io/pause:2.0

这个 node 亲和性规则意思是，pod 只能被调度在标签满足 key 为 kubernetes.io/e2e-az-name 并且 value 为 e2e-az1 或者 e2e-az2 的 node 上。另外，在满足条件的所有 node 中，更倾向于拥有 key 为 another-node-label-key 并且 value 为 another-node-label-value 的标签的 node。

您可以在例子中看到 In 运算符。新的 node 亲和性语法支持以下运算符：In、NotIn、Exists、DoesNotExist、Gt 和 Lt。 实际上并没有明确的 “node 反亲和性” 概念，不过 NotIn 和 DoesNotExist 提供了这种行为。

如果您指定了 nodeSelector 和 nodeAffinity，那么 pod 必须满足这 两个 规则才能调度到候选节点上。

如果您在 nodeAffinity 类型中指定了多个 nodeSelectorTerms，那么 pod 将会被调度到 只要满足其中一个 nodeSelectorTerms 的 node 上。

如果您在 nodeSelectorTerms 中指定了多个 matchExpressions，那么 pod 将会被调度到 满足所有 matchExpressions 的 node 上。