Kubernetes關於Affinity和nodeSelector以及Taints與容忍的理解

   

    大多數狀況下kubernetes的調度程序能將pod調度到集羣中合適的節點上。但有些狀況下用戶須要對pod調度到那個節點上施加更多控制，好比將pod部署到擁有SSD存儲節點、將同一個服務的多個後端部署在不一樣的機架上提升安全性、將通訊頻繁的服務部署在同一個可用區域下降通訊鏈路長度。用戶對pod部署的節點施加控制都與"label selector"有關。

 nodeSelector(節點選擇器)

nodeSelector也是標籤選擇器，是最簡單、最直接控制pod部署node的方法，在daemonset用nodeSelector過濾可部署節點，如下是其普通的應用示例。

步驟1：爲節點添加標籤

kubectl get nodes -o wide 獲取全部node信息

一、kubectl label nodes daily-k8s-n01 node=node01  二、kubectl label nodes daily-k8s-n01 disktype=ssd

爲節點添加node標籤node01，或者是disk類型爲ssd

  nodeSelector只能基於節點標籤控制pod部署node，而且選擇器只支持「與」邏輯操做。親和與反親和特性目前處於測試階段，相比於節點選擇器，其更靈活，功能更強大，體如今如下三點：

一、不只僅是「與」，支持更多的邏輯表達式。

二、nodeSelector是硬性要求，親和與反親和支持軟硬兩種要求。

三、除了節點標籤，親和與反親和支持根據節點上已經部署的pod進行節點選擇，這一點很重要。好比不想將兩種計算密集類型的pod部署在同一節點上，後部署pod可選擇過濾。

細分紅兩種類型的選擇器："節點親和"與"內部pod親和、反親和"。

節點親和與nodeSelector類似，具有上述一、2兩條優勢。  內部pod親和依賴的是節點上已有pod的標籤而不是節點標籤，兼俱上述三個優勢。由於節點親和能完成nodeSelector所工做而且具有額外的優勢，所以nodeSelector雖然還能用，但已經再也不維護，而且未來可能刪除。

       

      NodeAffinity節點親和性，是Pod上定義的一種屬性，使Pod可以按咱們的要求調度到某個Node上，而Taints則偏偏相反，它可讓Node拒絕運行Pod，甚至驅逐Pod。

 Taints(污點)是Node的一個屬性，設置了Taints(污點)後，由於有了污點，因此Kubernetes是不會將Pod調度到這個Node上的， 因而Kubernetes就給Pod設置了個屬性Tolerations(容忍)，只要Pod可以容忍Node上的污點，那麼Kubernetes就會忽略Node上的污點，就可以(不是必須)把Pod調度過去。所以 Taints(污點)一般與Tolerations(容忍)配合使用。

設置污點：

      kubectl taint node [node] key=value[effect]   

      其中[effect] 可取值： [ NoSchedule | PreferNoSchedule | NoExecute ]

       NoSchedule ：必定不能被調度。

       PreferNoSchedule：儘可能不要調度。

       NoExecute：不只不會調度，還會驅逐Node上已有的Pod。

       示例：kubectl taint node 10.10.0.111 node=111:NoSchedule

 好比設置污點：

     kubectl taint node 10.10.0.111 node=111:NoSchedule

     kubectl taint node 10.10.0.111 node=111:NoExecute

 去除指定key及其effect：

     kubectl taint nodes node_name key:[effect]-    #(這裏的key不用指定value)              

 去除指定key全部的effect: 

     kubectl taint nodes node_name key- 

 示例：

     kubectl taint node 10.10.0.111 node:NoSchedule-

     kubectl taint node 10.10.0.111 node:NoExecute-

     kubectl taint node 10.10.0.111 node-

對於 tolerations 屬性的寫法，其中的 key、value、effect 與 Node 的 Taint 設置需保持一致， 還有如下幾點說明：

1. 若是 operator 的值是 Exists，則 value 屬性可省略

2. 若是 operator 的值是 Equal，則表示其 key 與 value 之間的關係是 equal(等於)

3. 若是不指定 operator 屬性，則默認值爲 Equal

另外，還有兩個特殊值：

1. 空的 key 若是再配合 Exists 就能匹配全部的 key 與 value，也是是能容忍全部 node 的全部 Taints

2. 空的 effect 匹配全部的 effect

      tolerations:    
        - key: "node-role.kubernetes.io/master"        
          operator: "Exists"        
          effect: "NoSchedule"
          
          
    或者：
spec:
  tolerations: #設置容忍性
  - key: "test" 
   operator: "Equal"  #若是操做符爲Exists，那麼value屬性可省略,若是不指定operator，則默認爲Equal
   value: "16"
   effect: "NoSchedule"
  #意思是這個Pod要容忍的有污點的Node的key是test Equal 16,效果是NoSchedule，
  #tolerations屬性下各值必須使用引號，容忍的值都是設置Node的taints時給的值。
  containers:
   - name: pod-tains
   image: 10.3.1.15:5000/ubuntu:16.04

 經過對Taints和Tolerations的瞭解，能夠知道，經過它們可讓某些特定應用，獨佔一個Node：

給特定的Node設置一個Taint，只讓某些特定的應用來容忍這些污點，容忍後就有可能會被調度到此特定Node，

可是也不必定會調度給此特定Node，設置容忍並不阻止調度器調度給其它Node，那麼如何讓特定應用的Node

只能被調度到此特定的Node呢，這就要結合NodeAffinity節點親和性（也可使用nodeSelector去給node達標籤的方式），而後在Pod屬性裏

設置NodeAffinity到Node。如此就能達到要求了。

 總結：讓特定的服務跑到專屬的node節點上，經過給node節點打上taints，肯定不調度，而後給pod設置容忍，這樣其餘pod不會調度到此節點，在經過node

Selector或者NodeAffinity的方式讓改pod指定調度到此節點便可