親和性和反親和性 污點與污點容忍度

查看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