调度之nodeAffinity

1.简介

我们知道默认的调度器在使用的时候，经过了 predicates 和 priorities 两个阶段，但是在实际的生产环境中，往往我们需要根据自己的一些实际需求来控制 Pod 的调度，这就需要用到 nodeAffinity(节点亲和性)、podAffinity(pod 亲和性) 以及 podAntiAffinity(pod 反亲和性)。
亲和性调度可以分成软策略和硬策略两种方式:

软策略就是如果现在没有满足调度要求的节点的话，Pod 就会忽略这条规则，继续完成调度过程，说白了就是满足条件最好了，没有的话也无所谓
硬策略就比较强硬了，如果没有满足条件的节点的话，就不断重试直到满足条件为止，简单说就是你必须满足我的要求，不然就不干了
对于亲和性和反亲和性都有这两种规则可以设置： preferredDuringSchedulingIgnoredDuringExecution 和requiredDuringSchedulingIgnoredDuringExecution，前面的就是软策略，后面的就是硬策略。

2.节点亲和性

节点亲和性（nodeAffinity）主要是用来控制 Pod 要部署在哪些节点上，以及不能部署在哪些节点上的，它可以进行一些简单的逻辑组合了，不只是简单的相等匹配。

比如现在我们用一个 Deployment 来管理3个 Pod 副本，现在我们来控制下这些 Pod 的调度，如下例子：（node-affinity-demo.yaml）

apiVersion: apps/v1
kind: Deployment
metadata:
  name: node-affinity
  labels:
    app: node-affinity
spec:
  replicas: 3
  selector:
    matchLabels:
      app: node-affinity
  template:
    metadata:
      labels:
        app: node-affinity
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80
          name: nginxweb
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:  # 硬策略
            nodeSelectorTerms:
            - matchExpressions:
              - key: kubernetes.io/hostname
                operator: NotIn
                values:
                - k8s-node3
          preferredDuringSchedulingIgnoredDuringExecution:  # 软策略
          - weight: 1
            preference:
              matchExpressions:
              - key: cm
                operator: In
                values:
                - test

上面这个 Pod 首先是要求不能运行在 k8s-node3 这个节点上，如果有个节点满足 cm=test 的话就优先调度到这个节点上。

由于上面 k8s-node02 节点我们打上了 cm=test 这样的 label 标签，所以按要求会优先调度到这个节点来的，现在我们来创建这个 Pod，然后查看具体的调度情况是否满足我们的要求。

[root@k8s-master01 ~]# kubectl create -f node-affinity-demo.yaml 
deployment.apps/node-affinity created
[root@k8s-master01 ~]# kubectl get pod -owide
NAME                             READY   STATUS    RESTARTS   AGE     IP               NODE           NOMINATED NODE   READINESS GATES
busybox                          1/1     Running   261        11d     172.17.125.9     k8s-node01     <none>           <none>
nginx-68db656dd8-qjhs9           1/1     Running   1          11d     172.25.244.200   k8s-master01   <none>           <none>
nginx-68db656dd8-znwgp           1/1     Running   1          11d     172.18.195.11    k8s-master03   <none>           <none>
node-affinity-7fc9bdc65c-8nzmk   1/1     Running   0          6s      172.27.14.229    k8s-node02     <none>           <none>
node-affinity-7fc9bdc65c-gchtc   1/1     Running   0          6s      172.27.14.231    k8s-node02     <none>           <none>
node-affinity-7fc9bdc65c-gzqsx   1/1     Running   0          7s      172.27.14.230    k8s-node02     <none>           <none>
test-busybox                     1/1     Running   0          15m     172.27.14.216    k8s-node02     <none>           <none>
web                              2/2     Running   0          3d17h   172.18.195.14    k8s-master03   <none>           <none>
[root@k8s-master01 ~]# kubectl get deployment
NAME            READY   UP-TO-DATE   AVAILABLE   AGE
nginx           2/2     2            2           11d
node-affinity   3/3     3            3           56s

从结果可以看出有4个 Pod 被部署到了 ydzs-node2 节点上，但是可以看到并没有一个 Pod 被部署到 node3 这个节点上，因为我们的硬策略就是不允许部署到该节点上，而 node2 是软策略，所以会尽量满足。这里的匹配逻辑是 label 标签的值在某个列表中，现在 Kubernetes 提供的操作符有下面的几种：

In：label 的值在某个列表中
NotIn：label 的值不在某个列表中
Gt：label 的值大于某个值
Lt：label 的值小于某个值
Exists：某个 label 存在
DoesNotExist：某个 label 不存在
但是需要注意的是如果 nodeSelectorTerms 下面有多个选项的话，满足任何一个条件就可以了；如果 matchExpressions有多个选项的话，则必须同时满足这些条件才能正常调度 Pod。