影響K8S Pod分配和調(diào)度策略的兩大關(guān)鍵特性

在Kubernetes中有一個最復(fù)雜的調(diào)度器可以處理pod的分配策略?；谠趐od規(guī)范中所提及的資源需求，Kubernetes調(diào)度器會自動選擇最合適的節(jié)點來運行pod。

 
但在許多實際場景下，我們必須干預(yù)調(diào)度過程才能在pod和一個節(jié)點或兩個特定pod之間進行匹配。因此，Kubernetes中有一種十分強大的機制來管理及控制pod的分配邏輯。

那么，本文將探索影響Kubernetes中默認調(diào)度決定的關(guān)鍵特性。
 

節(jié)點親和性/反親和性

Kubernetes一向以來都是依賴label和selector來對資源進行分組。例如，某服務(wù)使用selector來過濾具有特定label的pod，這些label可以選擇性地接收流量。Label和selector可以使用簡單的基于等式的條件（=and!=）來評估規(guī)則。通過nodeSelector的特性（即強制將pod調(diào)度到特定節(jié)點上），可以將這一技術(shù)擴展到節(jié)點中。
 

 
此外，label和selector開始支持基于集合的query，它帶來了基于in、notin和exist運算符的高級過濾技術(shù)。與基于等式的需求相結(jié)合，基于集合的需求提供了復(fù)雜的技術(shù)來過濾Kubernetes中的資源。

節(jié)點親和性/反親和性使用label和annotation的基于表達集的過濾技術(shù)來定義特定節(jié)點上的pod的分配邏輯。Annotation可以提供不會暴露到selector的其他元數(shù)據(jù)，這意味著用于annotation的鍵不會包含在query和過濾資源中。但是節(jié)點親和性可以在表達式中使用annotation。反親和性可以確保pod不會被強制調(diào)度到與規(guī)則匹配的節(jié)點上。

除了能夠在query中使用復(fù)雜的邏輯之外，節(jié)點親和性/反親和性能夠為分配邏輯強制施加硬性和軟性規(guī)則。硬性規(guī)則將會執(zhí)行嚴格的策略，可能會阻止將pod分配到不符合條件的節(jié)點上。而軟性規(guī)則則會首先確認節(jié)點是否與特定的條件相匹配，如果它們不匹配，它將使用默認的調(diào)度模式來分配Pod。表達式requiredDuringSchedulingIgnoredDuringExecution和preferredDuringSchedulingIgnoredDuringExecution將會分別執(zhí)行硬性規(guī)則和軟性規(guī)則。

以下是在硬性和軟性規(guī)則下使用節(jié)點親和性/反親和性的示例：
 

affinity:
  nodeAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
        - matchExpressions:
          - key: "failure-domain.beta.kubernetes.io/zone"
            operator: In
            values: ["asia-south2-a"]

 
以上規(guī)則將指示Kubernetes調(diào)度器嘗試將Pod分配到在GKE集群的asia-south2-a區(qū)域中運行的節(jié)點上。如果沒有可用的節(jié)點，則調(diào)度器將會直接應(yīng)用標(biāo)準(zhǔn)的分配邏輯。
 

affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
        - matchExpressions:
          - key: "failure-domain.beta.kubernetes.io/zone"
            operator: NotIn
            values: ["asia-south2-a"]

 
以上規(guī)則通過使用NotIn運算符來強制執(zhí)行反親和性。這是一個硬性規(guī)則，它能夠確保沒有pod被分配到運行在asia-south2-a空間中的GKE節(jié)點。
 

Pod親和性/反親和性

盡管節(jié)點親和性/反親和性能夠處理pod和節(jié)點之間的匹配，但是有些場景下我們需要確保pod在一起運行或在相同的節(jié)點上不運行2個pod。Pod親和性/反親和性將幫助我們應(yīng)用強制實施粒度分配邏輯。

與節(jié)點親和性/反親和性中的表達式類似，pod親和性/反親和性也能夠通過requiredDuringSchedulingIgnoredDuringExecution和preferredDuringSchedulingIgnoredDuringExecution強制實施硬性以及軟性規(guī)則。還可以將節(jié)點親和性與pod親和性進行混合和匹配，以定義復(fù)雜的分配邏輯。

 
為了能夠更好地理解概念，想象一下我們有一個web和緩存deployment，其中三個副本在一個3節(jié)點的集群中運行。為了確保在web和緩存pod之間低延遲，我們想要在用一個節(jié)點上運行它們。與此同時，我們不想在相同的節(jié)點上運行超過1個緩存pod?；诖饲闆r，我們需要實施以下策略：每個節(jié)點僅運行1個且只有1個緩存Pod的web pod。

首先，我們將使用反親和性規(guī)則來部署緩存，它將阻止超過1個pod運行在1個節(jié)點上：
 

      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - redis
            topologyKey: "kubernetes.io/hostname"

 
topoloyKey使用附加到節(jié)點的默認label動態(tài)過濾節(jié)點的名稱。請注意，我們使用podAntiAffinity表達式和in運算符來應(yīng)用規(guī)則的方式。
 

假設(shè)在集群的某個節(jié)點上安排了3個pod緩存，那么現(xiàn)在我們想要在與緩存Pod相同的節(jié)點上部署web pod。我們將使用podAffinity來實施這一邏輯：
 

        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - redis
            topologyKey: "kubernetes.io/hostname"

 
以上代碼表明Kubernetes調(diào)度器要尋找有緩存Pod的節(jié)點并部署web pod。

 
除了節(jié)點和pod的親和性/反親和性之外，我們還能使用taints和tolerations來定義自定義分配邏輯。此外，我們還能寫自定義調(diào)度程序，它可以從默認的調(diào)度程序中接管調(diào)度邏輯。