Categories
程式開發

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


在 Kubernetes 中,Pod 是最小的原子調度單位。這意味著所有調度和資源管理都可圍繞Pod展開,本文將從Pod入手,深入講解Kubernetes的調度和資源管理。

Kubernetes 調度過程

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

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

我們來看一下,假如要向這個 Kubernetes 集群提交一個 pod,它的調度過程是什麼樣的一個流程?

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

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

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

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

通過校驗之後,ApiServer 會在集群裡面生成一個 pod,此時生成的 pod,它的 nodeName 是空的,並且它的 phase 是 Pending 狀態。在生成了這個 pod 之後,kube-Scheduler 以及 kubelet 都能 watch 到這個 pod 的生成事件,kube-Scheduler 發現這個 pod 的 nodeName 是空的之後,會認為這個 pod 是處於未調度狀態。

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

接下來,它會把這個pod 拿到自己裡面進行調度,通過一系列的調度算法,包括一系列的過濾和打分的算法後,Schedule 會選出一台最合適的節點,並且把這一台節點的名稱綁定在這個pod 的spec 上,完成一次調度的過程。

此時我們發現,pod 的 spec 上,nodeName 已經更新成了 Node1 這個 node,更新完 nodeName 之後,在 Node1 上的這台 kubelet 會 watch 到這個 pod 是屬於自己節點上的一個 pod。

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

然後它會把這個 pod 拿到節點上進行操作,包括創建一些容器 storage 以及 network,最後等所有的資源都準備完成,kubelet 會把狀態更新為 Running,這樣一個完整的調度過程就結束了。

通過剛剛一個調度過程的演示,我們用一句話來概括一下調度過程:它其實就是在做一件事情,即把 pod 放到合適的 node 上。

這裡有個關鍵字“合適”,什麼是合適呢?下面給出幾點合適定義的特點:

  • 首先要滿足 pod 的資源要求;

  • 其次要滿足 pod 的一些特殊關係的要求;

  • 再次要滿足 node 的一些限制條件的要求;

  • 最後還要做到整個集群資源的合理利用。

做到以上的要求後,可以認為我們把 pod 放到了一個合適的節點上了。

接下來我會為大家介紹 Kubernetes 是怎麼做到滿足這些 pod 和 node 的要求的。

Kubernetes 基礎調度力

下面為大家介紹一下 Kubernetes 的基礎調度能力,Kubernetes 的基礎調度能力會以兩部分來展開介紹:

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

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

  • pod 和 pod 之間的關係場景,包括怎麼去親和一個 pod,怎麼去互斥一個 pod?

  • pod 和 node 之間的關係場景,包括怎麼去親和一個 node,以及有一些 node 怎麼去限制 pod 調度上來。

如何滿足 Pod 資源要求

pod 的資源配置方法

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

上圖是 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

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

首先我們如何創建出來一個 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。

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

比如說上面的例子,可以不用填寫 memory 的資源,只要填寫 CPU 的資源,它就是一種 Burstable Pod。

BestEffort Pod

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

第三類 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。

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

非整數的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

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

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

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 親和調度

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

首先我們來看 Pod 親和調度,假如我想把一個 Pod 和另一個 Pod 放在一起,這時我們可以看上圖中的實例寫法,填寫上 podAffinity,然後填上 required 要求。

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

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

有些時候我們並不需要這麼嚴格的調度策略。這時候可以把 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 所在節點。

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

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

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

第一類是 NodeSelector,這是一類相對比較簡單的用法。比如說有個場景:必須要調度 Pod 到帶了 k1: v1 標籤的 Node 上,這時可以在 Pod 的 spec 中填寫一個 nodeSelector 要求。 nodeSelector 本質是一個 map 結構,裡面可以直接寫上對 node 標籤的要求,比如 k1: v1。這樣我的 Pod 就會強制調度到帶了 k1: v1 標籤的 Node 上。

NodeAffinity

NodeSelector 是一個非常簡單的用法,但這個用法有個問題:它只能強制親和調度,假如我想優先調度,就沒法用 nodeSelector 來做。於是 Kubernetes 社區又新加了一個用法,叫做 NodeAffinity。

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

它和 PodAffinity 有點類似,也提供了兩類調度的策略:

  • 第一類是 required,必須調度到某一類 Node 上;

  • 第二類是 preferred,就是優先調度到某一類 Node 上。

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

Node 標記/容忍

還有第三類調度,可以通過給 Node 打一些標記,來限制 Pod 調度到某些 Node 上。 Kubernetes 把這些標記稱之為 Taints,它的字面意思是污染。

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

那我們如何限制 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) – 比較符合日常公司業務特點

在實際生產中,如果使用先到先得策略,反而是一種不公平的策略,因為公司業務裡面肯定是有高優先級的業務和低優先級的業務,所以優先級策略會比先到先得策略更能夠符合日常公司業務特點。

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

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

在 Kubernetes 裡,PodPriority 和 Preemption,就是優先級和搶占的特點,在 v1.14 版本中變成了 stable。並且 PodPriority 和 Preemption 功能默認是開啟的。

優先級調度配置

怎麼使用?

如何使用優先級調度呢?需要創建一個 priorityClass,然後再為每個 Pod 配置上不同的 priorityClassName,這樣就完成了優先級以及優先級調度的配置。

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

首先來看一下如何創建一個 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 到調度隊列裡。

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

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

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

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

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

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

優先級搶占過程

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

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

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

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

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

緊接著再調度 Pod1,因為 Node1 上已經存在了兩個 Pod,資源不足,所以會遇到調度失敗。

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

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

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

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

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

優先級搶占策略

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

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

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

接著從過濾剩下的節點中,挑選出合適的節點進行搶占。這次搶占的過程會模擬一次調度,把上面優先級低的 Pod 先移除出去,再把待搶占的 Pod 嘗試能否放置到此節點上。然後通過這個過程選出一批節點,進入下一個過程 ProcessPreemptionWithExtenders。這是一個擴展的鉤子,用戶可以在這裡加一些自己搶占節點的策略,如果沒有擴展鉤子,這裡面是不做任何動作的。

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

  • 優先選擇打破 PDB 最少的節點;

  • 其次選擇待搶占 Pods 中最大優先級最小的節點;

  • 再次選擇待搶占 Pods 優先級加和最小的節點;

  • 接下來選擇待搶占 Pods 數目最小的節點;

  • 最後選擇擁有最晚啟動 Pod 的節點;

通過這五步串行策略過濾之後,會選出一個最合適的節點。然後對這個節點上待搶占的 Pod 進行 delete,這樣就完成了一次待搶占的過程。

小結

簡單介紹了一下調度的高級策略,在集群資源緊張的時候也能合理調度資源。我們回顧一下做了哪些事情:

  • 創建自定義的一些優先級類別 (PriorityClass);

  • 給不同類型 Pods 配置不同的優先級 (PriorityClassName);

  • 通過組合不同類型 Pods 運行和優先級搶占讓集群資源和調度彈性起來。

本文轉載自阿里巴巴雲原生微信公眾號(ID:Alicloudnative)。

相關閱讀:

從零開始入門 K8s:etcd 性能優化實踐

從零開始入門 K8s:手把手帶你理解 etcd

從零開始入門 K8s:深入剖析 Linux 容器

從零開始入門 K8s:Kubernetes 中的服務發現與負載均衡

從零開始入門 K8s:Kubernetes 網絡概念及策略控制

從零開始入門 K8s:監控與日誌的可觀測性

從零開始入門 K8s:應用存儲和持久化數據卷:存儲快照與拓撲調度

從零開始入門 K8s:應用存儲和持久化數據卷的核心知識

從零開始入門 K8s:應用配置管理

從零開始入門 K8s:應用編排與管理:Job & DaemonSet

從零開始入門 K8s:應用編排與管理

從零開始入門 K8s:K8s 的應用編排與管理

從零開始入門 K8s:詳解 Pod 及容器設計模式

從零開始入門 K8s:詳解 K8s 容器基本概念

從零開始入門 K8s:詳解 K8s 核心概念