Kubernetes中的親和性與反親和性

一般狀況下，Pod分配到哪些Node是不須要管理員操心的，這個過程會由scheduler自動實現。但有時，咱們須要指定一些調度的限制，例如某些應用應該跑在具備SSD存儲的節點上，有些應用應該跑在同一個節點上等等。

nodeSelector：
首先咱們爲Node規劃標籤，而後在建立部署的時候，經過使用nodeSelector標籤來指定Pod運行在哪些節點上。

親和性（Affinity ）與反親和性（AntiAffinity）：

• 親和性：應用A與應用B兩個應用頻繁交互，因此有必要利用親和性讓兩個應用的儘量的靠近，甚至在一個node上，以減小因網絡通訊而帶來的性能損耗。
• 反親和性：當應用的採用多副本部署時，有必要採用反親和性讓各個應用實例打散分佈在各個node上，以提升HA。

包含：nodeAffinity（主機親和性），podAffinity（POD親和性）以及podAntiAffinity（POD反親和性）

策略名稱	匹配目標	支持的操做符	支持拓撲域	設計目標
nodeAffinity	主機標籤	In,NotIn,Exists,DoesNotExist,Gt,Lt	不支持	決定Pod能夠部署在哪些主機上
podAffinity	Pod標籤	In，NotIn，Exists，DoesNotExist	支持	決定Pod能夠和哪些Pod部署在同一拓撲域
PodAntiAffinity	Pod標籤	In，NotIn，Exists，DoesNotExist	支持	決定Pod不能夠和哪些Pod部署在同一拓

nodeAffinity使用場景 ：

• 將S1服務的全部Pod部署到指定的符合標籤規則的主機上。
• 將S1服務的全部Pod部署到除部分主機外的其餘主機上。
  podAffinity使用場景 ：
  
• 將某一特定服務的pod部署在同一拓撲域中，不用指定具體的拓撲域。

• 若是S1服務使用S2服務，爲了減小它們之間的網絡延遲（或其它緣由），把S1服務的POD和S2服務的pod部署在同一拓撲域中。
  podAntiAffinity使用場景：

• 將一個服務的POD分散在不一樣的主機或者拓撲域中，提升服務自己的穩定性。
• 給POD對於一個節點的獨佔訪問權限來保證資源隔離，保證不會有其它pod來分享節點資源。
• 把可能會相互影響的服務的POD分散在不一樣的主機上。

運算符關係：

• In：label的值在某個列表中
• NotIn：label的值不在某個列表中
• Gt：label的值大於某個值
• Lt：label的值小於某個值
• Exists：某個label存在
• DoesNotExist：某個label不存在

nodeSelector的調度方式略顯簡單，經過親和和反親和配置，可以爲調度提供更靈活的策略，主要有如下幾點加強：

• 更多的表達式支持，不單單是ADD和精確匹配了
• 能夠設置soft/preference的調度策略，而不是剛性的要求
• 能夠經過Pod的標籤進行調度約束，不單單是Node的標籤

親和性特性包含兩種方式:

• requiredDuringSchedulingIgnoredDuringExecution: hard，嚴格執行，知足規則調度，不然不調度，在預選階段執行，因此違反hard約定必定不會調度到
• preferredDuringSchedulingIgnoredDuringExecution：soft，盡力執行，優先知足規則調度，在優選階段執行
• requiredDuringSchedulingRequiredDuringExecution，相似 requiredDuringSchedulingIgnoredDuringExecution。不一樣之處就是pod運行過程當中若是節點再也不知足pod的親和性，則pod會在該節點中逐出。

IgnoreDuringExecution表示若是在Pod運行期間Node的標籤發生變化，致使親和性策略不能知足，則繼續運行當前的Pod。

限制
topologyKey:

• 對於親和性和軟反親和性，不容許空topologyKey;
• 對於硬反親和性，LimitPodHardAntiAffinityTopology控制器用於限制topologyKey只能是kubernetes.io/hostname;
• 對於軟反親和性，空topologyKey被解讀成kubernetes.io/hostname, failure-domain.beta.kubernetes.io/zone and failure-domain.beta.kubernetes.io/region的組合；

例子：

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

上面的例子中，建立了一個具備三個實例的部署，採用了Pod間的反親和策略，限制建立的實例的時候，若是節點上已經存在具備相同標籤的實例，則不進行部署，避免了一個節點上部署多個相同的實例。

基於上面的例子：

再建立3個Web服務的實例，同上面Redis的配置，首先確保兩個Web不會部署到相同的節點，而後在應用Pod間親和策略，優先在有Redis服務的節點上部署Web。

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

⚠️注意事項：

• Pod間的親和性策略要求可觀的計算量可能顯著下降集羣的性能，不建議在超過100臺節點的範圍內使用。
• Pod間的反親和策略要求全部的Node都有一致的標籤，例如集羣中全部節點都應有匹配topologyKey的標籤，若是一些節點缺失這些標籤可能致使異常行爲。
• 若是同時指定nodeSelector和nodeAffinity，則必須知足兩個條件，才能將Pod調度到候選節點上。
• 若是pod已經調度在該節點，當咱們刪除或修該節點的標籤時，pod不會被移除。換句話說，親和性選擇只有在pod調度期間有效。
• 在key下的values只要有一個知足條件，那麼當前的key就知足條件
• 若是在matchExpressions下有多個key列表，那麼只有當全部key知足時，才能將pod調度到某個節點【針對硬親和】。