k8s默認調度器調度策略是什么意思

這篇文章主要講解了“k8s默認調度器調度策略是什么意思”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“k8s默認調度器調度策略是什么意思”吧！

Predicates

首先，我們一起看看 Predicates。

Predicates 在調度過程中的作用，可以理解為 Filter，即：它按照調度策略，從當前集群的所有節點中，“過濾”出一系列符合條件的節點。這些節點，都是可以運行待調度 Pod 的宿主機。

而在 Kubernetes 中，默認的調度策略有如下三種。

第一種類型，叫作 GeneralPredicates。

顧名思義，這一組過濾規則，負責的是最基礎的調度策略。

PodFitsResources

PodFitsResources 計算的就是宿主機的 CPU 和內存資源等是否夠用。

當然，我在前面已經提到過，PodFitsResources 檢查的只是 Pod 的 requests 字段。需要注意的是，Kubernetes 的調度器并沒有為 GPU 等硬件資源定義具體的資源類型，而是統一用一種名叫 Extended Resource 的、Key-Value 格式的擴展字段來描述的。比如下面這個例子：

apiVersion: v1
kind: Pod
metadata:
  name: extended-resource-demo
spec:
  containers:
  - name: extended-resource-demo-ctr
    image: nginx
    resources:
      requests:
        alpha.kubernetes.io/nvidia-gpu: 2
      limits:
        alpha.kubernetes.io/nvidia-gpu: 2

可以看到，我們這個 Pod 通過alpha.kubernetes.io/nvidia-gpu=2這樣的定義方式，聲明使用了兩個 NVIDIA 類型的 GPU。

而在 PodFitsResources 里面，調度器其實并不知道這個字段 Key 的含義是 GPU，而是直接使用后面的 Value 進行計算。當然，在 Node 的 Capacity 字段里，你也得相應地加上這臺宿主機上 GPU 的總數，比如：alpha.kubernetes.io/nvidia-gpu=4。這些流程，我在后面講解 Device Plugin 的時候會詳細介紹到。

PodFitsHost

而 PodFitsHost 檢查的是，宿主機的名字是否跟 Pod 的 spec.nodeName 一致。

PodFitsHostPorts

PodFitsHostPorts 檢查的是，Pod 申請的宿主機端口（spec.nodePort）是不是跟已經被使用的端口有沖突。

PodMatchNodeSelector

PodMatchNodeSelector 檢查的是，Pod 的 nodeSelector 或者 nodeAffinity 指定的節點，是否與待考察節點匹配，等等。

可以看到，像上面這樣一組 GeneralPredicates，正是 Kubernetes 考察一個 Pod 能不能運行在一個 Node 上最基本的過濾條件。所以，GeneralPredicates 也會被其他組件（比如 kubelet）直接調用。

我在上一篇文章中已經提到過，kubelet 在啟動 Pod 前，會執行一個 Admit 操作來進行二次確認。這里二次確認的規則，就是執行一遍 GeneralPredicates。

第二種類型，是與 Volume 相關的過濾規則

這一組過濾規則，負責的是跟容器持久化 Volume 相關的調度策略。

其中，NoDiskConflict 檢查的條件，是多個 Pod 聲明掛載的持久化 Volume 是否有沖突。比如，AWS EBS 類型的 Volume，是不允許被兩個 Pod 同時使用的。所以，當一個名叫 A 的 EBS Volume 已經被掛載在了某個節點上時，另一個同樣聲明使用這個 A Volume 的 Pod，就不能被調度到這個節點上了。

而 MaxPDVolumeCountPredicate 檢查的條件，則是一個節點上某種類型的持久化 Volume 是不是已經超過了一定數目，如果是的話，那么聲明使用該類型持久化 Volume 的 Pod 就不能再調度到這個節點了。

而 VolumeZonePredicate，則是檢查持久化 Volume 的 Zone（高可用域）標簽，是否與待考察節點的 Zone 標簽相匹配。

此外，這里還有一個叫作 VolumeBindingPredicate 的規則。它負責檢查的，是該 Pod 對應的 PV 的 nodeAffinity 字段，是否跟某個節點的標簽相匹配。

曾經講解過，Local Persistent Volume（本地持久化卷），必須使用 nodeAffinity 來跟某個具體的節點綁定。這其實也就意味著，在 Predicates 階段，Kubernetes 就必須能夠根據 Pod 的 Volume 屬性來進行調度。

此外，如果該 Pod 的 PVC 還沒有跟具體的 PV 綁定的話，調度器還要負責檢查所有待綁定 PV，當有可用的 PV 存在并且該 PV 的 nodeAffinity 與待考察節點一致時，這條規則才會返回“成功”。比如下面這個例子：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: example-local-pv
spec:
  capacity:
    storage: 500Gi
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: local-storage
  local:
    path: /mnt/disks/vol1
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - my-node

可以看到，這個 PV 對應的持久化目錄，只會出現在名叫 my-node 的宿主機上。所以，任何一個通過 PVC 使用這個 PV 的 Pod，都必須被調度到 my-node 上才可以正常工作。VolumeBindingPredicate，正是調度器里完成這個決策的位置。

第三種類型，是宿主機相關的過濾規則。

這一組規則，主要考察待調度 Pod 是否滿足 Node 本身的某些條件。

比如，PodToleratesNodeTaints，負責檢查的就是我們前面經常用到的 Node 的“污點”機制。只有當 Pod 的 Toleration 字段與 Node 的 Taint 字段能夠匹配的時候，這個 Pod 才能被調度到該節點上。

而 NodeMemoryPressurePredicate，檢查的是當前節點的內存是不是已經不夠充足，如果是的話，那么待調度 Pod 就不能被調度到該節點上。<

第四種類型，是 Pod 相關的過濾規則

這一組規則，跟 GeneralPredicates 大多數是重合的。而比較特殊的，是 PodAffinityPredicate。這個規則的作用，是檢查待調度 Pod 與 Node 上的已有 Pod 之間的親密（affinity）和反親密（anti-affinity）關系。比如下面這個例子：

apiVersion: v1
kind: Pod
metadata:
  name: with-pod-antiaffinity
spec:
  affinity:
    podAntiAffinity: 
      requiredDuringSchedulingIgnoredDuringExecution: 
      - weight: 100  
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: security 
              operator: In 
              values:
              - S2
          topologyKey: kubernetes.io/hostname
  containers:
  - name: with-pod-affinity
    image: docker.io/ocpqe/hello-pod

這個例子里的 podAntiAffinity 規則，就指定了這個 Pod 不希望跟任何攜帶了 security=S2 標簽的 Pod 存在于同一個 Node 上。需要注意的是，PodAffinityPredicate 是有作用域的，比如上面這條規則，就僅對攜帶了 Key 是kubernetes.io/hostname標簽的 Node 有效。這正是 topologyKey 這個關鍵詞的作用。

而與 podAntiAffinity 相反的，就是 podAffinity，比如下面這個例子：

apiVersion: v1
kind: Pod
metadata:
  name: with-pod-affinity
spec:
  affinity:
    podAffinity: 
      requiredDuringSchedulingIgnoredDuringExecution: 
      - labelSelector:
          matchExpressions:
          - key: security 
            operator: In 
            values:
            - S1 
        topologyKey: failure-domain.beta.kubernetes.io/zone
  containers:
  - name: with-pod-affinity
    image: docker.io/ocpqe/hello-pod

這個例子里的 Pod，就只會被調度到已經有攜帶了 security=S1 標簽的 Pod 運行的 Node 上。而這條規則的作用域，則是所有攜帶 Key 是failure-domain.beta.kubernetes.io/zone標簽的 Node。

此外，上面這兩個例子里的 requiredDuringSchedulingIgnoredDuringExecution 字段的含義是：這條規則必須在 Pod 調度時進行檢查（requiredDuringScheduling）；但是如果是已經在運行的 Pod 發生變化，比如 Label 被修改，造成了該 Pod 不再適合運行在這個 Node 上的時候，Kubernetes 不會進行主動修正（IgnoredDuringExecution）。

上面這四種類型的 Predicates，就構成了調度器確定一個 Node 可以運行待調度 Pod 的基本策略。

在具體執行的時候， 當開始調度一個 Pod 時，Kubernetes 調度器會同時啟動 16 個 Goroutine，來并發地為集群里的所有 Node 計算 Predicates，最后返回可以運行這個 Pod 的宿主機列表。

需要注意的是，在為每個 Node 執行 Predicates 時，調度器會按照固定的順序來進行檢查。這個順序，是按照 Predicates 本身的含義來確定的。比如，宿主機相關的 Predicates 會被放在相對靠前的位置進行檢查。要不然的話，在一臺資源已經嚴重不足的宿主機上，上來就開始計算 PodAffinityPredicate，是沒有實際意義的。

Priorities

接下來，我們再來看一下 Priorities。

在 Predicates 階段完成了節點的“過濾”之后，Priorities 階段的工作就是為這些節點打分。這里打分的范圍是 0-10 分，得分最高的節點就是最后被 Pod 綁定的最佳節點。

Priorities 里最常用到的一個打分規則，是 LeastRequestedPriority。它的計算方法，可以簡單地總結為如下所示的公式：

score = (cpu((capacity-sum(requested))10/capacity) + memory((capacity-sum(requested))10/capacity))/2

可以看到，這個算法實際上就是在選擇空閑資源（CPU 和 Memory）最多的宿主機。

而與 LeastRequestedPriority 一起發揮作用的，還有 BalancedResourceAllocation。它的計算公式如下所示：

score = 10 - variance(cpuFraction,memoryFraction,volumeFraction)*10

其中，每種資源的 Fraction 的定義是 ：Pod 請求的資源 / 節點上的可用資源。而 variance 算法的作用，則是計算每兩種資源 Fraction 之間的“距離”。而最后選擇的，則是資源 Fraction 差距最小的節點。

所以說，BalancedResourceAllocation 選擇的，其實是調度完成后，所有節點里各種資源分配最均衡的那個節點，從而避免一個節點上 CPU 被大量分配、而 Memory 大量剩余的情況。

此外，還有 NodeAffinityPriority、TaintTolerationPriority 和 InterPodAffinityPriority 這三種 Priority。顧名思義，它們與前面的 PodMatchNodeSelector、PodToleratesNodeTaints 和 PodAffinityPredicate 這三個 Predicate 的含義和計算方法是類似的。但是作為 Priority，一個 Node 滿足上述規則的字段數目越多，它的得分就會越高。

在默認 Priorities 里，還有一個叫作 ImageLocalityPriority 的策略。它是在 Kubernetes v1.12 里新開啟的調度規則，即：如果待調度 Pod 需要使用的鏡像很大，并且已經存在于某些 Node 上，那么這些 Node 的得分就會比較高。

當然，為了避免這個算法引發調度堆疊，調度器在計算得分的時候還會根據鏡像的分布進行優化，即：如果大鏡像分布的節點數目很少，那么這些節點的權重就會被調低，從而“對沖”掉引起調度堆疊的風險。

以上，就是 Kubernetes 調度器的 Predicates 和 Priorities 里默認調度規則的主要工作原理了。

在實際的執行過程中，調度器里關于集群和 Pod 的信息都已經緩存化，所以這些算法的執行過程還是比較快的。

此外，對于比較復雜的調度算法來說，比如 PodAffinityPredicate，它們在計算的時候不只關注待調度 Pod 和待考察 Node，還需要關注整個集群的信息，比如，遍歷所有節點，讀取它們的 Labels。這時候，Kubernetes 調度器會在為每個待調度 Pod 執行該調度算法之前，先將算法需要的集群信息初步計算一遍，然后緩存起來。這樣，在真正執行該算法的時候，調度器只需要讀取緩存信息進行計算即可，從而避免了為每個 Node 計算 Predicates 的時候反復獲取和計算整個集群的信息。

需要注意的是，除了本篇講述的這些規則，Kubernetes 調度器里其實還有一些默認不會開啟的策略。你可以通過為 kube-scheduler 指定一個配置文件或者創建一個 ConfigMap ，來配置哪些規則需要開啟、哪些規則需要關閉。并且，你可以通過為 Priorities 設置權重，來控制調度器的調度行為。

感謝各位的閱讀，以上就是“k8s默認調度器調度策略是什么意思”的內容了，經過本文的學習后，相信大家對k8s默認調度器調度策略是什么意思這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！