從零開始入門 K8s | Kubernetes 調度和資源管理

做者 | 子譽  螞蟻金服高級技術專家

關注「阿里巴巴雲原生」公衆號，回覆關鍵詞「入門」，便可下載從零入門 K8s 系列文章 PPT。

Kubernetes 調度過程

首先來看第一部分 - Kubernetes 的調度過程。以下圖所示，畫了一個很簡單的 Kubernetes 集羣架構，它包括了一個 kube-ApiServer，一組 Web-hook Controllers，以及一個默認的調度器 kube-Scheduler，還有兩臺物理機節點 Node1 和 Node2，分別在上面部署了兩個 kubelet。

咱們來看一下，假如要向這個 Kubernetes 集羣提交一個 pod，它的調度過程是什麼樣的一個流程？

假設咱們已經寫好了一個 yaml 文件，就是下圖中的橙色圓圈 pod1，而後往 kube-ApiServer 裏提交這個 yaml 文件。

此時 ApiServer 會先把這個待建立的請求路由給咱們的 webhook Controllers 進行校驗。

經過校驗以後，ApiServer 會在集羣裏面生成一個 pod，此時生成的 pod，它的 nodeName 是空的，而且它的 phase 是 Pending 狀態。在生成了這個 pod 以後，kube-Scheduler 以及 kubelet 都能 watch 到這個 pod 的生成事件，kube-Scheduler 發現這個 pod 的 nodeName 是空的以後，會認爲這個 pod 是處於未調度狀態。

接下來，它會把這個 pod 拿到本身裏面進行調度，經過一系列的調度算法，包括一系列的過濾和打分的算法後，Schedule 會選出一臺最合適的節點，而且把這一臺節點的名稱綁定在這個 pod 的 spec 上，完成一次調度的過程。

此時咱們發現，pod 的 spec 上，nodeName 已經更新成了 Node1 這個 node，更新完 nodeName 以後，在 Node1 上的這臺 kubelet 會 watch 到這個 pod 是屬於本身節點上的一個 pod。

而後它會把這個 pod 拿到節點上進行操做，包括建立一些容器 storage 以及 network，最後等全部的資源都準備完成，kubelet 會把狀態更新爲 Running，這樣一個完整的調度過程就結束了。

經過剛剛一個調度過程的演示，咱們用一句話來歸納一下調度過程：它其實就是在作一件事情，即把 pod 放到合適的 node 上。

這裏有個關鍵字「合適」，什麼是合適呢？下面給出幾點合適定義的特色：

• 首先要知足 pod 的資源要求；
• 其次要知足 pod 的一些特殊關係的要求；
• 再次要知足 node 的一些限制條件的要求；
• 最後還要作到整個集羣資源的合理利用。

作到以上的要求後，能夠認爲咱們把 pod 放到了一個合適的節點上了。

接下來我會爲你們介紹 Kubernetes 是怎麼作到知足這些 pod 和 node 的要求的。

Kubernetes 基礎調度力

下面爲你們介紹一下 Kubernetes 的基礎調度能力，Kubernetes 的基礎調度能力會以兩部分來展開介紹：

1. 第一部分是資源調度——介紹一下 Kubernetes 基本的一些 Resources 的配置方式，還有 Qos 的概念，以及 Resource Quota 的概念和使用方式；

2. 第二部分是關係調度——在關係調度上，介紹兩種關係場景：

   1. pod 和 pod 之間的關係場景，包括怎麼去親和一個 pod，怎麼去互斥一個 pod？
   2. pod 和 node 之間的關係場景，包括怎麼去親和一個 node，以及有一些 node 怎麼去限制 pod 調度上來。

如何知足 Pod 資源要求

pod 的資源配置方法

上圖是 pod spec 的一個 demo，咱們的資源實際上是填在 pod spec 中，具體在 containers 的 resources 裏。

resources 包含兩個部分：

• 第一部分是 requests；
• 第二部分是 limits。

這兩部分裏面的內容是如出一轍的，可是它表明的含義有所不一樣：request 表明的是對這個 pod 基本保底的一些資源要求；limit 表明的是對這個 pod 可用能力上限的一種限制。request、limit 的實現是一個 map 結構，它裏面能夠填不一樣的資源的 key/value。

咱們能夠大概分紅四大類的基礎資源：

• 第一類是 CPU 資源；
• 第二類是 memory；
• 第三類是 ephemeral-storage，是一種臨時存儲；
• 第四類是通用的擴展資源，好比說像 GPU。

CPU 資源，好比說上面的例子填的是2，申請的是兩個 CPU，也能夠寫成 2000m 這種十進制的轉換方式，來表達有些時候可能對 CPU 多是一個小數的需求，好比說像 0.2 個CPU，能夠填 200m。而這種方式在 memory 和 storage 之上，它是一個二進制的表達方式，如上圖右側所示，申請的是 1GB 的 memory，一樣也能夠填成一個 1024mi 的表達方式，這樣能夠更清楚地表達咱們對 memory 的需求。

在擴展資源上，Kubernetes 有一個要求，即擴展資源必須是整數的，因此咱們無法申請到 0.5 的 GPU 這樣的資源，只能申請 1 個 GPU 或者 2 個 GPU。

這裏爲你們介紹完了基礎資源的申請方式。

接下來，我會詳細給你們介紹一下 request 和 limit 到底有什麼區別，以及如何經過 request/limit 來表示 QoS。

Pod QoS 類型

K8S 在 pod resources 裏面提供了兩種填寫方式：第一種是 request，第二種是 limit。

它實際上是爲用戶提供了對 Pod 一種彈性能力的定義。好比說咱們能夠對 request 填 2 個 CPU，對 limit 填 4 個 CPU，這樣表明了我但願是有 2 個 CPU 的保底能力，但其實在閒置的時候，可使用 4 個 GPU。

說到這個彈性能力，咱們不得不提到一個概念：QoS 的概念。什麼是 QoS呢？QoS 全稱是 Quality of Service，它是 Kubernetes 用來表達一個 pod 在資源能力上的服務質量的標準，Kubernetes 提供了三類 QoS Class:

1. 第一類是 Guaranteed，它是一類高 QoS Class，通常拿 Guaranteed 配置給一些須要資源保障能力的 pods；
2. 第二類是 Burstable，它是中等的一個 QoS label，通常會爲一些但願有彈性能力的 pod 來配置 Burstable；
3. 第三類是 BestEffort，它是低QoS Class，經過名字咱們也知道，它是一種盡力而爲式的服務質量，K8S不承諾保障這類Pods服務質量。

K8s 其實有一個不太好的地方，就是用戶無法直接指定本身的 pod 是屬於哪一類 QoS，而是經過 request 和 limit 的組合來自動地映射上 QoS Class。

經過上圖的例子，你們能夠看到：假如我提交的是上面的一個 spec，在 spec 提交成功以後，Kubernetes 會自動給補上一個 status，裏面是 qosClass: Guaranteed，用戶本身提交的時候，是無法定義本身的 QoS 等級。因此將這種方式稱之爲隱性的 QoS class 用法。

Pod QoS 配置

接下來介紹一下，咱們怎麼經過 request 和 limit 的組合來肯定咱們想要的 QoS level。

Guaranteed Pod

首先咱們如何建立出來一個 Guaranteed Pod？

Kubernetes 裏面有一個要求：若是你要建立出一個 Guaranteed Pod，那麼你的基礎資源（包括 CPU 和 memory），必須它的 request==limit，其餘的資源能夠不相等。只有在這種條件下，它建立出來的 pod 纔是一種 Guaranteed Pod，不然它會屬於 Burstable，或者是 BestEffort Pod。

Burstable Pod

而後看一下，咱們怎麼建立出來一個 Burstable Pod，Burstable Pod 的範圍比較寬泛，它只要知足 CPU/Memory  的 request 和 limit 不相等，它就是一種 Burstable Pod。

好比說上面的例子，能夠不用填寫 memory 的資源，只要填寫 CPU 的資源，它就是一種 Burstable Pod。

BestEffort Pod

第三類 BestEffort Pod，它也是條件比較死的一種使用方式。它必須是全部資源的 request/limit 都不填，纔是一種 BestEffort Pod。

因此這裏能夠看到，經過 request 和 limit 不一樣的用法，能夠組合出不一樣的 Pod QoS。

不一樣的 QoS 表現

接下來，爲你們介紹一下：不一樣的 QoS 在調度和底層表現有什麼樣的不一樣？不一樣的 QoS，它其實在調度和底層表現上都有一些不同。好比說調度表現，調度器只會使用 request 進行調度，也就是說無論你配了多大的 limit，它都不會進行調度使用。

在底層上，不一樣的 Qos 表現更不相同。好比說 CPU，它是按 request 來劃分權重的，不一樣的 QoS，它的 request 是徹底不同的，好比說像 Burstable 和 BestEffort，它可能 request 能夠填很小的數字或者不填，這樣的話，它的時間片權重實際上是很是低的。像 BestEffort，它的權重可能只有 2，而 Burstable 或 Guaranteed，它的權重能夠多到幾千。

另外，當咱們開啓了 kubelet 的一個特性，叫 cpu-manager-policy=static 的時候，咱們 Guaranteed Qos，若是它的 request 是一個整數的話，好比說配了 2，它會對 Guaranteed Pod 進行綁核。具體的像下面這個例子，它分配 CPU0 和 CPU1 給 Guaranteed Pod。

非整數的 Guaranteed/Burstable/BestEffort，它們的 CPU 會放在一塊，組成一個 CPU share pool，好比說像上面這個例子，這臺節點假如說有 8 個核，已經分配了 2 個核給整數的 Guaranteed 綁核，那麼剩下的 6 個核 CPU2~CPU7，它會被非整數的 Guaranteed/Burstable/BestEffort 共享，而後它們會根據不一樣的權重劃分時間片來使用 6 個核的 CPU。

另外在 memory 上也會按照不一樣的 QoS 進行劃分 OOMScore。好比說 Guaranteed Pod，會固定配置默認的 -998 的 OOMScore；而 Burstable Pod 會根據 Pod 內存設計的大小和節點內存的比例來分配 2-999 的 OOMScore；BestEffort Pod 會固定分配 1000 的 OOMScore，OOMScore 得分越高的話，在物理機出現 OOM 的時候會優先被 kill 掉。

另外在節點上的 eviction 動做上，不一樣的 QoS 行爲也是不同的，好比說發生 eviction 的時候，會優先考慮驅逐 BestEffort 的 pod。因此不一樣的 QoS 在底層的表現是大相徑庭的。這反過來也要求咱們在生產過程當中，根據不一樣業務的要求和屬性來配置資源的 Limits 和 Requests，作到合理的規劃 QoS Class。

資源 Quota

在生產中咱們還會遇到一個場景：假如集羣是由多我的同時提交的，或者是多個業務同時在使用，咱們確定要限制某個業務或某我的提交的總量，防止整個集羣的資源都會被一個業務使用掉，致使另外一個業務沒有資源使用。

Kubernetes 給咱們提供了一個能力叫 ResourceQuota。它能夠作到限制 namespace 資源用量。

具體的作法如上圖右側的 yaml 所示，能夠看到它的 spec 包括了一個 hard 和 scopeSelector。hard 內容其實和 Resource 很像，這裏能夠填一些基礎的資源。可是它比 Resource list 更豐富一點，還能夠填寫一些 Pod，這樣能夠限制 Pod 數量。另外，scopeSelector 還爲這個 ResourceQuota 提供了更豐富的索引能力。

好比上面的例子中，索引出非 BestEffort 的 pod，限制的 cpu 是 1000 個，memory 是 200G，Pod 是 10 個。

ScopeName 除了提供 NotBestEffort，它還提供了更豐富的索引範圍，包括 Terminating/Not Terminating，BestEffort/NotBestEffort，PriorityClass。

當咱們建立了這樣的 ResourceQuota 做用於集羣，若是用戶真的用超了資源，表現的行爲是：它在提交 Pod spec 時，會收到一個 forbidden 的 403 錯誤，提示 exceeded quota。這樣用戶就沒法再提交對應用超的資源了。

而若是再提交一個沒有包含在這個 ResourceQuota 裏的資源，仍是能成功的。

這就是 Kubernetes 裏 ResourceQuota 的基本用法。 咱們能夠用 ResourceQuota 方法來作到限制每個 namespace 的資源用量，從而保證其餘用戶的資源使用。

小結：如何知足 Pod 資源要求？

上面介紹完了基礎資源的使用方式，也就是咱們作到了如何知足 Pod 資源要求。下面作一個小結：

• Pod 要配置合理的資源要求

  • CPU/Memory/EphemeralStorage/GPU

• 經過 Request 和 Limit 來爲不一樣業務特色的 Pod 選擇不一樣的 QoS

  • Guaranteed：敏感型，須要業務保障
  • Burstable：次敏感型，須要彈性業務
  • BestEffort：可容忍性業務
• 爲每一個 NS 配置 ResourceQuota 來防止過量使用，保障其餘人的資源可用

如何知足 Pod 與 Pod 關係要求？

接下來給你們介紹一下 Pod 的關係調度，首先是 Pod 和 Pod 的關係調度。咱們在平時使用中可能會遇到一些場景：好比說一個 Pod 必需要和另一個 Pod 放在一塊兒，或者不能和另一個 Pod 放在一塊兒。

在這種要求下， Kubernetes 提供了兩類能力：

• 第一類能力稱之爲 Pod 親和調度：PodAffinity；
• 第二類就是 Pod 反親和調度：PodAntAffinity。

Pod 親和調度

首先咱們來看 Pod 親和調度，假如我想把一個 Pod 和另外一個 Pod 放在一塊兒，這時咱們能夠看上圖中的實例寫法，填寫上 podAffinity，而後填上 required 要求。

在這個例子中，必需要調度到帶了 key: k1 的 Pod 所在的節點，而且打散粒度是按照節點粒度去打散索引的。這種狀況下，假如能找到帶 key: k1 的 Pod 所在節點，就會調度成功。假如這個集羣不存在這樣的 Pod 節點，或者是資源不夠的時候，那就會調度失敗。這是一個嚴格的親和調度，咱們叫作強制親和調度。

有些時候咱們並不須要這麼嚴格的調度策略。這時候能夠把 required 改爲 preferred，變成一個優先親和調度。也就是優先能夠調度帶 key: k2 的 Pod 所在節點。而且這個 preferred 裏面能夠是一個 list 選擇，能夠填上多個條件，好比權重等於 100 的是 key: k2，權重等於 10 的是 key: k1。那調度器在調度的時候會優先把這個 Pod 分配到權重分更高的調度條件節點上去。

Pod 反親和調度

上面介紹了親和調度，反親和調度與親和調度比較類似，功能上是取反的，但語法上基本上是同樣的。僅是 podAffinity 換成了 podAntiAffinity，也是包括 required 強制反親和，以及一個 preferred 優先反親和。

這裏舉了兩個例子：一個是禁止調度到帶了 key: k1 標籤的 Pod 所在節點；另外一個是優先反親和調度到帶了 key: k2 標籤的 Pod 所在節點。

Kubernetes 除了 In 這個 Operator 語法以外，還提供了更多豐富的語法組合來給你們使用。好比說 In/NotIn/Exists/DoesNotExist 這些組合方式。上圖的例子用的是 In，好比說第一個強制反親和例子裏面，至關於咱們必需要禁止調度到帶了 key: k1 標籤的 Pod 所在節點。

一樣的功能也可使用 Exists，Exists 範圍可能會比 In 範圍更大，當 Operator 填了 Exists，就不須要再填寫 values。它作到的效果就是禁止調度到帶了 key: k1 標籤的 Pod 所在節點，無論 values 是什麼值，只要帶了 k1 這個 key 標籤的 Pod 所在節點，都不能調度過去。

以上就是 Pod 與 Pod 之間的關係調度。

如何知足 Pod 與 Node 關係調度

Pod 與 Node 的關係調度又稱之爲 Node 親和調度，主要給你們介紹兩類使用方法。

NodeSelector

第一類是 NodeSelector，這是一類相對比較簡單的用法。好比說有個場景：必需要調度 Pod 到帶了 k1: v1 標籤的 Node 上，這時能夠在 Pod 的 spec 中填寫一個 nodeSelector 要求。nodeSelector 本質是一個 map 結構，裏面能夠直接寫上對 node 標籤的要求，好比 k1: v1。這樣個人 Pod 就會強制調度到帶了 k1: v1 標籤的 Node 上。

NodeAffinity

NodeSelector 是一個很是簡單的用法，但這個用法有個問題：它只能強制親和調度，假如我想優先調度，就無法用 nodeSelector 來作。因而 Kubernetes 社區又新加了一個用法，叫作 NodeAffinity。

它和 PodAffinity 有點相似，也提供了兩類調度的策略：

• 第一類是 required，必須調度到某一類 Node 上；
• 第二類是 preferred，就是優先調度到某一類 Node 上。

它的基本語法和上文中的 PodAffinity 以及 PodAntiAffinity 也是相似的。在 Operator 上，NodeAffinity 提供了比 PodAffinity 更豐富的 Operator 內容。增長了 Gt 和 Lt，數值比較的用法。當使用 Gt 的時候，values 只能填寫數字。

Node 標記/容忍

還有第三類調度，能夠經過給 Node 打一些標記，來限制 Pod 調度到某些 Node 上。Kubernetes 把這些標記稱之爲 Taints，它的字面意思是污染。

那咱們如何限制 Pod 調度到某些 Node 上呢？好比說如今有個 node 叫 demo-node，這個節點有問題，我想限制一些 Pod 調度上來。這時能夠給這個節點打一個 taints，taints 內容包括 key、value、effect：

• key 就是配置的鍵值
• value 就是內容
• effect 是標記了這個 taints 行爲是什麼

目前 Kubernetes 裏面有三個 taints 行爲：

1. NoSchedule 禁止新的 Pod 調度上來；
2. PreferNoSchedul 儘可能不調度到這臺；
3. NoExecute 會 evict 沒有對應 toleration 的 Pods，而且也不會調度新的上來。這個策略是很是嚴格的，你們在使用的時候要當心一點。

如上圖綠色部分，給這個 demo-node 打了 k1=v1，而且 effect 等於 NoSchedule 以後。它的效果是：新建的 Pod  沒有專門容忍這個 taint，那就無法調度到這個節點上去了。

假若有些 Pod 是能夠調度到這個節點上的，應該怎麼來作呢？這時能夠在 Pod 上打一個 Pod Tolerations。從上圖中藍色部分能夠看到：在 Pod 的 spec 中填寫一個 Tolerations，它裏面也包含了 key、value、effect，這三個值和 taint 的值是徹底對應的，taint 裏面的 key，value，effect 是什麼內容，Tolerations 裏面也要填寫相同的內容。

Tolerations 還多了一個選項 Operator，Operator 有兩個 value：Exists/Equal。Equal 的概念是必需要填寫 value，而 Exists 就跟上文說的 NodeAffinity 同樣，不須要填寫 value，只要 key 值對上了，就認爲它跟 taints 是匹配的。

上圖中的例子，給 Pod 打了一個 Tolerations，只有打了這個 Tolerations 的 Pod，才能調度到綠色部分打了 taints 的 Node 上去。這樣的好處是 Node 能夠有選擇性的調度一些 Pod 上來，而不是全部的 Pod 均可以調度上來，這樣就作到了限制某些 Pod 調度到某些 Node 的效果。

小結

咱們已經介紹完了 Pod/Node 的特殊關係和條件調度，來作一下小結。

首先假若有需求是處理 Pod 與 Pod 的時候，好比 Pod 和另外一個 Pod 有親和的關係或者是互斥的關係，能夠給它們配置下面的參數：

• PodAffinity
• PodAntiAffinity

假如存在 Pod 和 Node 有親和關係，能夠配置下面的參數：

• NodeSelector
• NodeAffinity

假若有些 Node 是限制某些 Pod 調度的，好比說一些故障的 Node，或者說是一些特殊業務的 Node，能夠配置下面的參數：

• Node -- Taints
• Pod -- Tolerations

Kubernetes 高級調度能力

介紹完了基礎調度能力以後，下面來了解一下高級調度能力。

優先級調度

優先級調度和搶佔，主要概念有：

• Priority
• Preemption

首先來看一下調度過程提到的四個特色，咱們如何作到集羣的合理利用？當集羣資源足夠的話，只須要經過基礎調度能力就能組合出合理的使用方式。可是假如資源不夠，咱們怎麼作到集羣的合理利用呢？一般的策略有兩類：

• 先到先得策略 (FIFO) -簡單、相對公平，上手快
• 優先級策略 (Priority) - 比較符合平常公司業務特色

在實際生產中，若是使用先到先得策略，反而是一種不公平的策略，由於公司業務裏面確定是有高優先級的業務和低優先級的業務，因此優先級策略會比先到先得策略更可以符合平常公司業務特色。

接下來介紹一下優先級策略下的優先級調度是什麼樣的一個概念。好比說有一個 Node 已經被一個 Pod 佔用了，這個 Node 只有 2 個 CPU。另外一個高優先級 Pod 來的時候，低優先級的 Pod 應該把這兩個 CPU 讓給高優先級的 Pod 去使用。低優先級的 Pod 須要回到等待隊列，或者是業務從新提交。這樣的流程就是優先級搶佔調度的一個流程。

在 Kubernetes 裏，PodPriority 和 Preemption，就是優先級和搶佔的特色，在 v1.14 版本中變成了 stable。而且 PodPriority 和 Preemption 功能默認是開啓的。

優先級調度配置

怎麼使用？

如何使用優先級調度呢？須要建立一個 priorityClass，而後再爲每一個 Pod 配置上不一樣的 priorityClassName，這樣就完成了優先級以及優先級調度的配置。

首先來看一下如何建立一個 priorityClass。上圖右側定義了兩個 demo：

• 一個是建立了名爲 high 的 priorityClass，它是高優先級，得分爲 10000；
• 另外一個建立了名爲 low 的 priorityClass，它的得分是 100。

同時在第三部分給 Pod1 配置上了 high，Pod2 上配置了 low priorityClassName，藍色部分顯示了 pod 的 spec 的配置位置，就是在 spec 裏面填寫一個 priorityClassName: high。這樣 Pod 和 priorityClass 作完配置，就爲集羣開啓了一個 priorityClass 調度。

內置優先級配置

固然 Kubernetes 裏面還內置了默認的優先級。如 DefaultpriorityWhenNoDefaultClassExistis，若是集羣中沒有配置 DefaultpriorityWhenNoDefaultClassExistis，那全部的 Pod 關於此項數值都會被設置成 0。

用戶可配置的最大優先級限制爲：HighestUserDefinablePriority = 10000000000(10 億)，會小於系統級別優先級：SystemCriticalPriority = 20000000000(20 億)

其中內置了兩個系統級別優先級：

• system-cluster-critical
• system-node-critical

這就是K8S優先級調度裏內置的優先級配置。

優先級調度過程

下面介紹簡單的優先級調度過程：

首先介紹只觸發優先級調度可是沒有觸發搶佔調度的流程。

假若有一個 Pod1 和 Pod2，Pod1 配置了高優先級，Pod2 配置了低優先級。同時提交 Pod1 和 Pod2 到調度隊列裏。

調度器處理隊列的時候會挑選一個高優先級的 Pod1 進行調度，通過調度過程把 Pod1 綁定到 Node1 上。

其次再挑選一個低優先的 Pod2 進行一樣的過程，綁定到 Node1 上。

這樣就完成了一個簡單的優先級調度的流程。

優先級搶佔過程

假如高優先級的 Pod 在調度的時候沒有資源，那麼會是一個怎麼樣的流程呢？

首先是跟上文一樣的場景，可是提早在 Node1 上放置了 Pod0，佔去了一部分資源。一樣有 Pod1 和 Pod2 待調度，Pod1 的優先級大於 Pod2。

假如先把 Pod2 調度上去，它通過一系列的調度過程綁定到了 Node1 上。

緊接着再調度 Pod1，由於 Node1 上已經存在了兩個 Pod，資源不足，因此會遇到調度失敗。

在調度失敗時 Pod1 會進入搶佔流程，這時會進行整個集羣的節點篩選，最後挑出要搶佔的 Pod 是 Pod2，此時調度器會把 Pod2 從 Node1 上移除數據。

再把 Pod1 調度到 Node1 上。這樣就完成了一次搶佔調度的流程。

優先級搶佔策略

接下來介紹具體的搶佔策略和搶佔流程

上圖右側是整個kube-scheduler優先級搶佔的調度流程。首先一個 Pod 進入搶佔的時候，會判斷 Pod 是否擁有搶佔的資格，有可能上次已經搶佔過一次。若是符合搶佔資格，它會先對全部的節點進行一次過濾，過濾出符合此次搶佔要求的節點，若是不符合就過濾掉這批節點。

接着從過濾剩下的節點中，挑選出合適的節點進行搶佔。此次搶佔的過程會模擬一次調度，把上面優先級低的 Pod 先移除出去，再把待搶佔的 Pod 嘗試可否放置到此節點上。而後經過這個過程選出一批節點，進入下一個過程 ProcessPreemptionWithExtenders。這是一個擴展的鉤子，用戶能夠在這裏加一些本身搶佔節點的策略，若是沒有擴展鉤子，這裏面是不作任何動做的。

接下來的流程叫作 PickOneNodeForPreemption，就是從上面 selectNodeForPreemption list 裏面挑選出最合適的一個節點，這是有必定的策略的。上圖左側簡單介紹了一下策略：

• 優先選擇打破 PDB 最少的節點；
• 其次選擇待搶佔 Pods 中最大優先級最小的節點；
• 再次選擇待搶佔 Pods 優先級加和最小的節點；
• 接下來選擇待搶佔 Pods 數目最小的節點；
• 最後選擇擁有最晚啓動 Pod 的節點；

經過這五步串行策略過濾以後，會選出一個最合適的節點。而後對這個節點上待搶佔的 Pod 進行 delete，這樣就完成了一次待搶佔的過程。

小結

簡單介紹了一下調度的高級策略，在集羣資源緊張的時候也能合理調度資源。咱們回顧一下作了哪些事情：

• 建立自定義的一些優先級類別 (PriorityClass)；
• 給不一樣類型 Pods 配置不一樣的優先級 (PriorityClassName)；
• 經過組合不一樣類型 Pods 運行和優先級搶佔讓集羣資源和調度彈性起來。

「 阿里巴巴雲原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，作最懂雲原生開發者的技術圈。」