亲和性和反亲和性 污点与污点容忍度

查看node的label命令

$ kubectl get nodes --show-labels

 给随便一个节点增加标签

$ kubectl label nodes ydzs-node2 com=youdianzhishi
node/ydzs-node2 labeled  (结果)

 亲和性和反亲和性：

pod亲和性和反亲和性表示pod部署到或不部署到满足某些label的pod所在的node上

默认的调度器在使用的时候，经过了筛选(predicate)和优选(priorities)两个阶段，但是在实际的生产环境中，会用到nodeAffinity(节点亲和性)、
podAffinity(pod 亲和性) 以及 podAntiAffinity(pod 反亲和性)

亲和性调度可以分成软策略和硬策略两种方式

软策略就是如果现在没有满足调度要求的节点的话，pod就会忽略这条规则，继续完成调度的过程，说白了就是满足条件最好了，没有的话也无所谓
硬策略就比较强硬了，是如果没有满足条件的节点的话，就不断重试直到满足条件为止，简单说就是你必须满足我的要求，不然就不干了

对于亲和性和反亲和性都有这两种规则可以设置：preferredDuringSchedulingIgnoredDuringExecution 和requiredDuringSchedulingIgnoredDuringExecution，前面的就是软策略，后面的就是硬策略

 节点亲和性

节点亲和性(nodeAffinity)主要是用来控制 Pod 要部署在哪些节点上，以及不能部署在哪些节点上的，它可以进行一些简单的逻辑组合了，不只是简单的相等匹配。
比如现在我们用一个 Deployment 来管理8个 Pod 副本，现在我们来控制下这些 Pod 的调度，如下例子：(node-affinity-demo.yaml)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: node-affinity
  labels:
    app: node-affinity
spec:
  replicas: 8
  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下面的节点里面进行调度
                values:
                - ydzs-node3
          preferredDuringSchedulingIgnoredDuringExecution:  # 软策略
          - weight: 1
            preference:
              matchExpressions:
              - key: com
                operator: In
                values:
                - youdianzhishi

label 的值可选的操作符有：

• In：label 的值在某个列表中
• NotIn：label 的值不在某个列表中
• Exists：某个 label 存在
• DoesNotExist: 某个 label 不存在
• Gt：label 的值大于某个值(字符串比较)
• Lt：label 的值小于某个值(字符串比较

pod反亲和性硬策略,实现相同lable pod一定不能调度到同一节点

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - nginx
            topologyKey: "kubernetes.io/hostname"
      containers:
      - name: nginx-server
        image: nginx:latest

• podAntiAffinity 表示pod的非亲和性策略
• matchExpressions 表示符合label条件的pod
• topologyKey 表示作用域key,这里使用 kubernetes.io/hostname表示所有的节点,因为所有的节点默认都会打上这个标签

污点和容忍

对于 nodeAffinity 无论是硬策略还是软策略方式，都是调度 Pod 到预期节点上，而污点(Taints)恰好与之相反，如果一个节点标记为 Taints ，除非 Pod 也被标识为可以容忍污点节点，否则该 Taints 节点不会被调度 Pod。 比如用户希望把 Master 节点保留给 Kubernetes 系统组件使用，或者把一组具有特殊资源预留给某些 Pod，则污点就很有用了，Pod 不会再被调度到 taint 标记过的节点。我们使用 kubeadm 搭建的集群默认就给 master 节点添加了一个污点标记，所以我们看到我们平时的 Pod 都没有被调度到 master 上去。

 查看节点污点

$ kubectl describe node master | grep  Taints
Taints:        node-role.kubernetes.io/master:NoSchedule

我们可以使用上面的命令查看 master 节点的信息，其中有一条关于 Taints 的信息：node-role.kubernetes.io/master:NoSchedule，
就表示master 节点打了一个污点的标记，其中影响的参数是 NoSchedule，表示 Pod 不会被调度到标记为 taints 的节点，
除了 NoSchedule 外，还有另外两个选项：
PreferNoSchedule：NoSchedule 的软策略版本，表示尽量不调度到污点节点上去 
NoExecute：该选项意味着一旦 Taint 生效，如该节点内正在运行的 Pod 没有对应容忍(Tolerate)设置，则会直接被逐出

 节点添加污点

kubectl taint nodes node1 key=value:NoSchedule
kubectl taint nodes node1 key=value:NoExecute
kubectl taint nodes node1 key=value:PreferNoSchedule

NoSchedule:        K8S node添加这个effecf类型污点，新的不能容忍的pod不能再调度过来，但是老的运行在node上不受影响
NoExecute：        K8S node添加这个effecf类型污点，新的不能容忍的pod不能调度过来，老的pod也会被驱逐
PreferNoSchedule： pod会尝试将pod分配到该节点

 节点删除污点

kubectl taint nodes kube11 key:NoSchedule-
kubectl taint nodes kube11 key:-

 pod设置容忍度yaml如下

apiVersion: apps/v1 
kind: Deployment 
metadata: 
  name: taint 
  labels:  
    app: taint 
spec: 
  replicas: 3 
  selector: 
    matchLabels: 
      app: taint 
  template: 
    metadata: 
      labels: 
        app: taint 
    spec: 
      containers: 
      - name: nginx 
        image: nginx 
        ports: 
        - name: http 
          containerPort: 80 
      tolerations: 
      - key: "node-role.kubernetes.io/master" 
        operator: "Exists" 
        effect: "NoSchedule" 
由于 master 节点被标记为了污点，所以我们这里要想 Pod 能够调度到改节点去，就需要增加容忍的声明：
tolerations: 
- key: "node-role.kubernetes.io/master" 
  operator: "Exists" 
  effect: "NoSchedule"

apiVersion: apps/v1Beta1
kind: Deployment
metadata:
  name: nginx-deploy
spec:
  replicas: 1
    selector:
      matchLabels:
        app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        images: nginx:laste
        ports:
        - containerPort: 80       
    tolerations:  #containers同级
    - key: "key1"          #能容忍的污点key
      operator: "Equal"    #Equal等于表示key=value ， Exists不等于，表示当值不等于下面value正常
      value: "value1"      #值
      effect: "NoExecute"  #effect策略，见上面
      tolerationSeconds: 3600  #原始的pod多久驱逐，注意只有effect: "NoExecute"才能设置，不然报错

 然后创建上面的资源，查看结果：

$ kubectl apply -f taint-demo.yaml
deployment.apps "taint" created
$ kubectl get pods -o wide
NAME                                      READY     STATUS             RESTARTS   AGE       IP             NODE
......
taint-845d8bb4fb-57mhm                    1/1       Running            0          1m        10.244.4.247   ydzs-node2
taint-845d8bb4fb-bbvmp                    1/1       Running            0          1m        10.244.0.33    ydzs-master
taint-845d8bb4fb-zb78x                    1/1       Running            0          1m        10.244.4.246   ydzs-node2
......

我们可以看到有一个 Pod 副本被调度到了 master 节点，这就是容忍的使用方法。 对于 tolerations 属性的写法，其中的 key、value、effect 与 Node 的 Taint 设置需保持一致， 还有以下几点说明： 如果 operator 的值是 Exists，则 value 属性可省略 如果 operator 的值是 Equal，则表示其 key 与 value 之间的关系是 equal(等于) 如果不指定 operator 属性，则默认值为 Equal 另外，还有两个特殊值： 空的 key 如果再配合 Exists 就能匹配所有的 key 与 value，也就是是能容忍所有节点的所有 Taints 空的 effect 匹配所有的 effect