細(xì)說(shuō)Kubernetes Pod的驅(qū)逐

作者：?jiǎn)炭?2023-02-09 16:47:34

云計(jì)算

云原生 在搶占期間，Kubernetes將試圖通過(guò)驅(qū)逐優(yōu)先級(jí)較低的Pod來(lái)釋放資源，以安排一個(gè)新的Pod。通過(guò)優(yōu)先級(jí)類，你可以控制哪些Pod更有可能在搶占后繼續(xù)運(yùn)行，因?yàn)樗鼈儽或?qū)逐的可能性較小。

公司主營(yíng)業(yè)務(wù)：成都網(wǎng)站制作、網(wǎng)站設(shè)計(jì)、移動(dòng)網(wǎng)站開發(fā)等業(yè)務(wù)。幫助企業(yè)客戶真正實(shí)現(xiàn)互聯(lián)網(wǎng)宣傳，提高企業(yè)的競(jìng)爭(zhēng)能力。創(chuàng)新互聯(lián)是一支青春激揚(yáng)、勤奮敬業(yè)、活力青春激揚(yáng)、勤奮敬業(yè)、活力澎湃、和諧高效的團(tuán)隊(duì)。公司秉承以“開放、自由、嚴(yán)謹(jǐn)、自律”為核心的企業(yè)文化，感謝他們對(duì)我們的高要求，感謝他們從不同領(lǐng)域給我們帶來(lái)的挑戰(zhàn)，讓我們激情的團(tuán)隊(duì)有機(jī)會(huì)用頭腦與智慧不斷的給客戶帶來(lái)驚喜。創(chuàng)新互聯(lián)推出昌邑免費(fèi)做網(wǎng)站回饋大家。

Kubernetes Pods被驅(qū)逐是什么意思？它們被終止了，通常是由于沒(méi)有足夠的資源，但是為什么會(huì)發(fā)生這種情況呢？

驅(qū)逐是一個(gè)過(guò)程，分配給一個(gè)節(jié)點(diǎn)的Pod被要求終止。Kubernetes中最常見的情況之一是搶占，為了在資源有限的節(jié)點(diǎn)上安排一個(gè)新的Pod，通常需要終止另外一個(gè)Pod。

另外，Kubernetes會(huì)不斷檢查資源使用情況，當(dāng)節(jié)點(diǎn)壓力過(guò)大的時(shí)候，會(huì)觸發(fā)節(jié)點(diǎn)壓力驅(qū)逐。

每天，數(shù)以千計(jì)的Pod被驅(qū)逐出他們的家園。擱淺和迷茫，他們不得不放棄以前的生活方式。他們中的一些人甚至?xí)o(wú)家可歸。當(dāng)前的社會(huì)，對(duì)CPU和內(nèi)存的要求會(huì)越來(lái)越高。

本篇文章將從以下幾個(gè)方面來(lái)展開介紹：

Pod被驅(qū)逐的原因：搶占和節(jié)點(diǎn)壓力

搶占式驅(qū)逐

Pod優(yōu)先級(jí)類

節(jié)點(diǎn)壓力驅(qū)逐

服務(wù)質(zhì)量類

其他類型的驅(qū)逐

Prometheus中的Kubernetes Pod驅(qū)逐監(jiān)控

Pods被驅(qū)逐的原因：搶占和節(jié)點(diǎn)壓力

Kubernetes中發(fā)生Pod驅(qū)逐的原因有幾個(gè)，最重要的原因是：

搶占

節(jié)點(diǎn)壓力驅(qū)逐

搶占驅(qū)逐

搶占的過(guò)程如下：如果一個(gè)新的Pod需要被調(diào)度，但沒(méi)有任何合適的節(jié)點(diǎn)有足夠的資源，那么kube-scheduler將檢查是否通過(guò)驅(qū)逐（終止）一些優(yōu)先級(jí)較低的Pod，用來(lái)保障新的Pod可以調(diào)度。

讓我們先了解一下Kubernetes調(diào)度是如何工作的。

Pod調(diào)度

Kubernetes調(diào)度是將Pod分配給節(jié)點(diǎn)的過(guò)程。

默認(rèn)情況下，有一個(gè)負(fù)責(zé)調(diào)度的Kubernetes實(shí)體，稱為kube-scheduler，它將在控制平面上運(yùn)行。Pod將在Pending狀態(tài)下開始，直到找到一個(gè)匹配的節(jié)點(diǎn)。

將一個(gè)Pod分配給一個(gè)節(jié)點(diǎn)的過(guò)程遵循這個(gè)順序。

• 預(yù)選
• 打分

預(yù)選

在預(yù)選過(guò)程中，kube-scheduler將選擇當(dāng)前Pod可能被放置的所有節(jié)點(diǎn)。這里將考慮到污點(diǎn)和容忍度等特征。一旦完成，它將有一個(gè)適合該P(yáng)od的節(jié)點(diǎn)列表。

打分

在打分過(guò)程中，kube-scheduler將從上一步得到的列表中，給每個(gè)節(jié)點(diǎn)分配一個(gè)分?jǐn)?shù)。這樣一來(lái)，候選節(jié)點(diǎn)就會(huì)從最合適到最不合適排序。如果兩個(gè)節(jié)點(diǎn)有相同的分?jǐn)?shù)，kube-scheduler會(huì)將它們隨機(jī)排序。

image.png

但是，如果沒(méi)有合適的節(jié)點(diǎn)讓Pod運(yùn)行，會(huì)發(fā)生什么？在這種情況下，Kubernetes將啟動(dòng)搶占程序，試圖驅(qū)逐低優(yōu)先級(jí)的Pod，以便分配新的Pod。

Pod Priority Class

怎樣才能防止某個(gè)特定的Pod在搶占過(guò)程中被驅(qū)逐？有時(shí)候，一個(gè)特定的Pod對(duì)你來(lái)說(shuō)是至關(guān)重要的，不應(yīng)該被終止。

這就是為什么Kubernetes具有Priority Class。

Priority Class是一個(gè)Kubernetes對(duì)象，允許我們將數(shù)字優(yōu)先級(jí)值映射到特定的Pod。那些數(shù)值較高的被歸類為更重要，不太可能被驅(qū)逐。

你可以通過(guò)以下方式查詢當(dāng)前的Priority Class。

kubectl get priorityclasses
kubectl get pc

NAME                      VALUE        GLOBAL-DEFAULT   AGE
system-cluster-critical   2000000000   false            2d
system-node-critical      2000001000   false            2d

測(cè)試Priority Class

這里有三個(gè)Pod：blueberry, raspberry 和 strawberry。

NAME         READY   STATUS             RESTARTS   AGE
blueberry    1/1     Running            0          4h41m
raspberry    1/1     Running            0          58m
strawberry   1/1     Running            0          5h22m

還有兩個(gè)Priority Class：trueberry和falseberry。其中trueberry擁有比較高的優(yōu)先級(jí)。

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: trueberry
value: 1000000
globalDefault: false
description: "This fruit is a true berry"

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: falseberry
value: 5000
globalDefault: false
description: "This fruit is a false berry"

• blueberry將使用trueberry
• raspberry和strawberry將使用ffalseberry

這意味著在發(fā)生搶占的情況下，raspberry和strawberry更有可能被驅(qū)逐，以便為更高優(yōu)先級(jí)的Pod騰出空間。

然后通過(guò)在Pod定義中加入優(yōu)先級(jí)類別，將其分配給Pod。

priorityClassName: trueberry

現(xiàn)在讓我們?cè)囍僭黾尤N水果：所有的新水果將包含更高的優(yōu)先級(jí)類，稱為trueberry。

由于這三個(gè)新的水果對(duì)內(nèi)存或CPU的要求是節(jié)點(diǎn)無(wú)法滿足的，kubelet會(huì)驅(qū)逐所有比新水果優(yōu)先級(jí)低的Pod。Blueberry保持運(yùn)行，因?yàn)樗懈叩膬?yōu)先級(jí)。

NAME         READY   STATUS             RESTARTS   AGE
banana       0/1     ContainerCreating  0          2s
blueberry    1/1     Running            0          4h42m
raspberry    0/1     Terminating        0          59m
strawberry   0/1     Terminating        0          5h23m
tomato       0/1     ContainerCreating  0          2s
watermelon   0/1     ContainerCreating  0          2s

最終結(jié)果如下：

NAME         READY   STATUS             RESTARTS   AGE
banana       1/1     Running            0          3s
blueberry    1/1     Running            0          4h43m
tomato       1/1     Running            0          3s
watermelon   1/1     Running            0          3s

節(jié)點(diǎn)壓力驅(qū)逐

除了搶占之外，Kubernetes還不斷檢查節(jié)點(diǎn)資源，如磁盤壓力、CPU或內(nèi)存不足（OOM）。

如果節(jié)點(diǎn)的資源（如CPU或內(nèi)存）消耗達(dá)到一定的閾值，Kubelet將開始驅(qū)逐Pod，以釋放資源。服務(wù)質(zhì)量（QoS）將被納入考慮范圍，以確定驅(qū)逐順序。

服務(wù)質(zhì)量QoS

在Kubernetes中，Pod被賦予三種QoS類別之一，這將定義它們?cè)谌狈Y源的情況下被驅(qū)逐的可能性。這三種QoS分別是：

• Guaranteed
• Burstable
• BestEffort

這些QoS類別是如何分配給Pod的？這是基于對(duì)CPU和內(nèi)存的限制和請(qǐng)求。

• limits：一個(gè)容器可以使用的資源的最大數(shù)量。
• requests：容器運(yùn)行所需的最小資源量。

Guaranteed

如果一個(gè)Pod被分配了一個(gè)Guaranteed的QoS等級(jí)，它們的特征如下：

• Pod中的所有容器都為CPU和內(nèi)存設(shè)置了限制和請(qǐng)求。
• 在Pod中的所有容器都有相同的CPU限制和CPU請(qǐng)求的值。
• Pod中的所有容器都有相同的內(nèi)存限制和內(nèi)存請(qǐng)求值。

一個(gè)有保證的Pod在正常情況下不會(huì)被驅(qū)逐以分配給節(jié)點(diǎn)中的另一個(gè)Pod。

Burstable

如果一個(gè)Pod的QoS等級(jí)為Burstable，那么它將被分配到一個(gè)QoS等級(jí)。

• 它沒(méi)有擔(dān)保的QoS等級(jí)。
• 為Pod中的一個(gè)容器設(shè)置了限制或請(qǐng)求。

一個(gè)Burstable Pod可以被驅(qū)逐，但比下一個(gè)類別的可能性小。

BestEffort

一個(gè)Pod將被分配一個(gè)BestEffort的QoS類別，它們將：

• 沒(méi)有為Pod中的任何容器設(shè)置限制和請(qǐng)求。

BestEffort Pod在節(jié)點(diǎn)中發(fā)生節(jié)點(diǎn)壓力過(guò)程的情況下具有最高的驅(qū)逐機(jī)會(huì)。

重要的是：在限制和請(qǐng)求中可能有其他可用的資源，如短暫的存儲(chǔ)，但它們不用于QoS類的計(jì)算。

如前所述，QoS類將被納入節(jié)點(diǎn)壓力驅(qū)逐的考慮范圍。以下是內(nèi)部發(fā)生的過(guò)程。

kubelet按照以下順序排列要被驅(qū)逐的Pod。

• 使用量超過(guò)請(qǐng)求的BestEffort Pods或Burstable Pods
• 使用量低于請(qǐng)求的Burstable Pods或Guaranteed Pods

Kubernetes將嘗試在第二組之前驅(qū)逐第一組的Pod。

從上述內(nèi)容中得到的一些啟示。

• 如果在你的容器中添加了非常低的請(qǐng)求，他們的Pod可能會(huì)被分配到組1，這意味著它更有可能被驅(qū)逐。
• 你無(wú)法知道哪個(gè)特定的Pod會(huì)被驅(qū)逐，只是Kubernetes會(huì)嘗試在第2組之前驅(qū)逐第1組的Pod。
• 有保證的Pod通常不會(huì)被驅(qū)逐：Kubelet不會(huì)為了安排其他Pod而驅(qū)逐它們。但是，如果一些系統(tǒng)服務(wù)需要更多的資源，kubelet將在必要時(shí)終止有保證的Pod，并且總是以最低的優(yōu)先級(jí)。

其他類型的驅(qū)逐

本文主要介紹搶占和節(jié)點(diǎn)壓力驅(qū)逐，但Pod也可以通過(guò)其他方式被驅(qū)逐。例子包括。

API發(fā)起的驅(qū)逐

你可以通過(guò)使用Kubernetes Eviction API【1】請(qǐng)求對(duì)你的一個(gè)節(jié)點(diǎn)中的Pod進(jìn)行按需驅(qū)逐。

基于污點(diǎn)的驅(qū)逐

通過(guò)Kubernetes污點(diǎn)和容忍度，可以指導(dǎo)你的Pod應(yīng)該如何分配給Node。但是，如果你將NoExecute污點(diǎn)應(yīng)用于現(xiàn)有的Node，所有不容忍它的Pod將被立即驅(qū)逐。

節(jié)點(diǎn)排水

有些時(shí)候，節(jié)點(diǎn)變得無(wú)法使用，或者你不想再在上面工作。命令kubectl cordon可以防止新的Pod被安排在它上面，但也有可能一次性完全清空所有當(dāng)前Pod。如果你運(yùn)行kubectl drain nodename，該節(jié)點(diǎn)中的所有Pod將被驅(qū)逐，尊重其優(yōu)雅的終止期。

Kubernetes Pod驅(qū)逐監(jiān)控

在你的云解決方案中，你可以使用Prometheus來(lái)輕松監(jiān)控Pod驅(qū)逐的做法。

kube_pod_status_reason{reasnotallow="Evicted"} > 0

這將顯示你的集群中所有被驅(qū)逐的Pod。你也可以將其與kube_pod_status_phase{phase="Failed"}配對(duì)，以提醒那些在Pod發(fā)生故障后被驅(qū)逐的人。

如果你想深入了解，請(qǐng)查看以下關(guān)于Prometheus中監(jiān)控資源的文章。

• 如何合理調(diào)整Kubernetes的資源限制【1】
• Kubernetes容量規(guī)劃：如何合理安排你的集群的請(qǐng)求【2】

總結(jié)

正如你所看到的，驅(qū)逐只是Kubernetes的另一個(gè)功能，它允許你控制有限的資源：在這種情況下，Pod將使用的節(jié)點(diǎn)。

在搶占期間，Kubernetes將試圖通過(guò)驅(qū)逐優(yōu)先級(jí)較低的Pod來(lái)釋放資源，以安排一個(gè)新的Pod。通過(guò)優(yōu)先級(jí)類，你可以控制哪些Pod更有可能在搶占后繼續(xù)運(yùn)行，因?yàn)樗鼈儽或?qū)逐的可能性較小。

在執(zhí)行過(guò)程中，Kubernetes將檢查節(jié)點(diǎn)壓力，并在需要時(shí)驅(qū)逐Pod。通過(guò)QoS類，你可以控制哪些Pod在節(jié)點(diǎn)壓力的情況下更有可能被驅(qū)逐。

內(nèi)存和CPU是節(jié)點(diǎn)中的重要資源，你需要配置你的Pod、容器和節(jié)點(diǎn)來(lái)使用它們的正確數(shù)量。如果你對(duì)這些資源進(jìn)行相應(yīng)的管理，不僅可以節(jié)省成本，而且還可以確保重要的進(jìn)程無(wú)論如何都能繼續(xù)運(yùn)行。

?文檔 【1】https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.25/#create-eviction-pod-v1-core

【1】https://sysdig.com/blog/kubernetes-resource-limits/

【2】https://sysdig.com/blog/kubernetes-capacity-planning/

當(dāng)前文章：細(xì)說(shuō)KubernetesPod的驅(qū)逐
文章來(lái)源：http://www.dlmjj.cn/article/cdgehsh.html