Kubernetes实战（四）-亲和性调度（NodeAffinity）

NodeAffinity 就是节点亲和性，相对应的是 Anti-Affinity，就是反亲和性，这种方法比上面的nodeSelector更加灵活，它可以进行一些简单的逻辑组合了，不只是简单的相等匹配。 目前有两种节点亲和性表达。

• requiredDuringSchedulingIgnoredDuringExecution：必须满足指定的规则才可以调度 Pod 到 Node 上（功能与 NodeSelector 很像，但是使用的是不同的语法），相当于硬限制。
• preferredDuringSchedulingIgnoredDuringExecution：强调优先满足指定规则，调度器会尝试调度 Pod 到 Node 上，但并不强求，相当于软限制。多个优先级规则还可以设置权重（weight）值，以定义执行的先后顺序。

下面有一个使用node affinity的例子：

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: gcr.io/google_containers/pause:2.0

这条规则表示，pod可以被调度到key为“kubernetes.io/e2e-az-name”，值为“e2e-az1”或“e2e-az2”的节点。另外，在满足该条件的节点中，优先使用具有“another-node-label-key”标签，且值为“another-node-label-value”的节点。

上面的例子使用了“In”操作符，node affinity语法支持以下集中操作符：In， NotIn， Exists， DoesNotExist，Gt，Lt。没有明确的“node anti-affinity”概念，但是NotIn和DoesNotExist可以表示该含义。

如果同时指定了nodeSelector和nodeAffinity，要调度的节点必须同时满足这两点规则。

如果指定了与多条与nodeSelector相关的表达式，pod将会被调度到同时满足这几条表达式的节点。