自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

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

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

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

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

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

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

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

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

搶占式驅(qū)逐

Pod優(yōu)先級類

節(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ū)逐

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

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

Pod調(diào)度

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

默認(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)的過程遵循這個(gè)順序。

  • 預(yù)選
  • 打分
預(yù)選

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

打分

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

圖片

image.png

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

Pod Priority Class

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

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

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

你可以通過以下方式查詢當(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

測試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)先級。

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)先級的Pod騰出空間。

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

priorityClassName: trueberry

現(xiàn)在讓我們試著再增加三種水果:所有的新水果將包含更高的優(yōu)先級類,稱為trueberry。

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

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類別之一,這將定義它們在缺乏資源的情況下被驅(qū)逐的可能性。這三種QoS分別是:

  • Guaranteed
  • Burstable
  • BestEffort

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

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

圖片

Guaranteed

如果一個(gè)Pod被分配了一個(gè)Guaranteed的QoS等級,它們的特征如下:

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

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

Burstable

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

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

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

BestEffort

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

  • 沒有為Pod中的任何容器設(shè)置限制和請求。

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

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

圖片

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

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

  • 使用量超過請求的BestEffort Pods或Burstable Pods
  • 使用量低于請求的Burstable Pods或Guaranteed Pods

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

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

  • 如果在你的容器中添加了非常低的請求,他們的Pod可能會(huì)被分配到組1,這意味著它更有可能被驅(qū)逐。
  • 你無法知道哪個(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)先級。

其他類型的驅(qū)逐

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

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

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

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

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

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

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

kube_pod_status_reason{reasnotallow="Evicted"} > 0

圖片

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

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

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

總結(jié)

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

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

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

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


責(zé)任編輯:武曉燕 來源: 運(yùn)維開發(fā)故事
相關(guān)推薦

2025-04-08 08:05:00

PodKubernetes容器

2024-04-29 13:04:00

K8Spod驅(qū)逐

2023-10-19 19:42:25

IstioPodkubernetes

2024-06-19 09:33:05

2024-03-18 15:44:48

K8S故障運(yùn)維

2019-11-20 09:15:53

KubernetesPod

2023-11-02 20:05:17

KubernetesPod管理

2022-04-09 15:26:46

Kubernetes刪除操作源碼解析

2020-11-30 12:15:26

KubernetesPodLinux

2021-11-22 08:00:00

Kubernetes容器集群

2023-06-14 08:49:22

PodKubernetes

2020-04-26 11:16:46

KubernetesPodLinux

2020-07-06 07:52:10

Kubernetes網(wǎng)絡(luò)通信

2020-04-10 08:00:08

Kubernetes補(bǔ)丁pod

2022-05-16 08:27:20

KubernetePodLinux

2022-09-22 12:11:38

PodKubernetes

2024-04-15 05:00:00

kubernete網(wǎng)絡(luò)容器

2022-07-04 09:13:54

KubernetespodLinux

2025-03-05 08:33:56

2025-03-04 08:20:00

點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號