在Kubernetes中有一個最復雜的調度器可以處理pod的分配策略。基于在pod規范中所提及的資源需求，Kubernetes調度器會自動選擇最合適的節點來運行pod。

創新互聯建站-專業網站定制、快速模板網站建設、高性價比澤庫網站開發、企業建站全套包干低至880元,成熟完善的模板庫,直接使用。一站式澤庫網站制作公司更省心,省錢,快速模板網站建設找我們，業務覆蓋澤庫地區。費用合理售后完善，十余年實體公司更值得信賴。

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

 

那么，本文將探索影響Kubernetes中默認調度決定的關鍵特性。
 

節點親和性/反親和性

 

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

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

 

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

 

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

 

以下是在硬性和軟性規則下使用節點親和性/反親和性的示例：
 

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

 
以上規則將指示Kubernetes調度器嘗試將Pod分配到在GKE集群的asia-south2-a區域中運行的節點上。如果沒有可用的節點，則調度器將會直接應用標準的分配邏輯。
 

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

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

Pod親和性/反親和性

 

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

 

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

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

 

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

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

 
topoloyKey使用附加到節點的默認label動態過濾節點的名稱。請注意，我們使用podAntiAffinity表達式和in運算符來應用規則的方式。
 

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

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

 
以上代碼表明Kubernetes調度器要尋找有緩存Pod的節點并部署web pod。

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

名稱欄目：影響K8SPod分配和調度策略的兩大關鍵特性
本文鏈接：http://m.newbst.com/article6/gcioog.html

成都網站建設公司_創新互聯，為您提供面包屑導航、品牌網站設計、Google、建站公司、電子商務、外貿網站建設

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯