Kubernetes Pods被驅逐是什么意思？它們被終止了，通常是由于沒有足夠的資源，但是為什么會發生這種情況呢？

驅逐是一個過程，分配給一個節點的Pod被要求終止。Kubernetes中最常見的情況之一是搶占，為了在資源有限的節點上安排一個新的Pod，通常需要終止另外一個Pod。

另外，Kubernetes會不斷檢查資源使用情況，當節點壓力過大的時候，會觸發節點壓力驅逐。

每天，數以千計的Pod被驅逐出他們的家園。擱淺和迷茫，他們不得不放棄以前的生活方式。他們中的一些人甚至會無家可歸。當前的社會，對CPU和內存的要求會越來越高。

本篇文章將從以下幾個方面來展開介紹：

Pod被驅逐的原因：搶占和節點壓力

搶占式驅逐

Pod優先級類

節點壓力驅逐

服務質量類

其他類型的驅逐

Prometheus中的Kubernetes Pod驅逐監控

Kubernetes中發生Pod驅逐的原因有幾個，最重要的原因是：

搶占

節點壓力驅逐

搶占驅逐

搶占的過程如下：如果一個新的Pod需要被調度，但沒有任何合適的節點有足夠的資源，那么kube-scheduler將檢查是否通過驅逐（終止）一些優先級較低的Pod，用來保障新的Pod可以調度。

讓我們先了解一下Kubernetes調度是如何工作的。

Pod調度

Kubernetes調度是將Pod分配給節點的過程。

默認情況下，有一個負責調度的Kubernetes實體，稱為kube-scheduler，它將在控制平面上運行。Pod將在Pending狀態下開始，直到找到一個匹配的節點。

將一個Pod分配給一個節點的過程遵循這個順序。

• 預選
• 打分

預選

在預選過程中，kube-scheduler將選擇當前Pod可能被放置的所有節點。這里將考慮到污點和容忍度等特征。一旦完成，它將有一個適合該Pod的節點列表。

打分

在打分過程中，kube-scheduler將從上一步得到的列表中，給每個節點分配一個分數。這樣一來，候選節點就會從最合適到最不合適排序。如果兩個節點有相同的分數，kube-scheduler會將它們隨機排序。

image.png

但是，如果沒有合適的節點讓Pod運行，會發生什么？在這種情況下，Kubernetes將啟動搶占程序，試圖驅逐低優先級的Pod，以便分配新的Pod。

Pod Priority Class

怎樣才能防止某個特定的Pod在搶占過程中被驅逐？有時候，一個特定的Pod對你來說是至關重要的，不應該被終止。

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

Priority Class是一個Kubernetes對象，允許我們將數字優先級值映射到特定的Pod。那些數值較高的被歸類為更重要，不太可能被驅逐。

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

這里有三個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

還有兩個Priority Class：trueberry和falseberry。其中trueberry擁有比較高的優先級。

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

這意味著在發生搶占的情況下，raspberry和strawberry更有可能被驅逐，以便為更高優先級的Pod騰出空間。

然后通過在Pod定義中加入優先級類別，將其分配給Pod。

priorityClassName: trueberry

現在讓我們試著再增加三種水果：所有的新水果將包含更高的優先級類，稱為trueberry。

由于這三個新的水果對內存或CPU的要求是節點無法滿足的，kubelet會驅逐所有比新水果優先級低的Pod。Blueberry保持運行，因為它有更高的優先級。

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

最終結果如下：

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

節點壓力驅逐

除了搶占之外，Kubernetes還不斷檢查節點資源，如磁盤壓力、CPU或內存不足（OOM）。

如果節點的資源（如CPU或內存）消耗達到一定的閾值，Kubelet將開始驅逐Pod，以釋放資源。服務質量（QoS）將被納入考慮范圍，以確定驅逐順序。

服務質量QoS

在Kubernetes中，Pod被賦予三種QoS類別之一，這將定義它們在缺乏資源的情況下被驅逐的可能性。這三種QoS分別是：

• Guaranteed
• Burstable
• BestEffort

這些QoS類別是如何分配給Pod的？這是基于對CPU和內存的限制和請求。

• limits：一個容器可以使用的資源的最大數量。
• requests：容器運行所需的最小資源量。

Guaranteed

如果一個Pod被分配了一個Guaranteed的QoS等級，它們的特征如下：

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

一個有保證的Pod在正常情況下不會被驅逐以分配給節點中的另一個Pod。

Burstable

如果一個Pod的QoS等級為Burstable，那么它將被分配到一個QoS等級。

• 它沒有擔保的QoS等級。
• 為Pod中的一個容器設置了限制或請求。

一個Burstable Pod可以被驅逐，但比下一個類別的可能性小。

BestEffort

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

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

BestEffort Pod在節點中發生節點壓力過程的情況下具有最高的驅逐機會。

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

如前所述，QoS類將被納入節點壓力驅逐的考慮范圍。以下是內部發生的過程。

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

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

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

從上述內容中得到的一些啟示。

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

其他類型的驅逐

本文主要介紹搶占和節點壓力驅逐，但Pod也可以通過其他方式被驅逐。例子包括。

API發起的驅逐

你可以通過使用Kubernetes Eviction API【1】請求對你的一個節點中的Pod進行按需驅逐。

基于污點的驅逐

通過Kubernetes污點和容忍度，可以指導你的Pod應該如何分配給Node。但是，如果你將NoExecute污點應用于現有的Node，所有不容忍它的Pod將被立即驅逐。

節點排水

有些時候，節點變得無法使用，或者你不想再在上面工作。命令kubectl cordon可以防止新的Pod被安排在它上面，但也有可能一次性完全清空所有當前Pod。如果你運行kubectl drain nodename，該節點中的所有Pod將被驅逐，尊重其優雅的終止期。

Kubernetes Pod驅逐監控

在你的云解決方案中，你可以使用Prometheus來輕松監控Pod驅逐的做法。

kube_pod_status_reason{reasnotallow="Evicted"} > 0

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

如果你想深入了解，請查看以下關于Prometheus中監控資源的文章。

• 如何合理調整Kubernetes的資源限制【1】
• Kubernetes容量規劃：如何合理安排你的集群的請求【2】

總結

正如你所看到的，驅逐只是Kubernetes的另一個功能，它允許你控制有限的資源：在這種情況下，Pod將使用的節點。

在搶占期間，Kubernetes將試圖通過驅逐優先級較低的Pod來釋放資源，以安排一個新的Pod。通過優先級類，你可以控制哪些Pod更有可能在搶占后繼續運行，因為它們被驅逐的可能性較小。

在執行過程中，Kubernetes將檢查節點壓力，并在需要時驅逐Pod。通過QoS類，你可以控制哪些Pod在節點壓力的情況下更有可能被驅逐。

內存和CPU是節點中的重要資源，你需要配置你的Pod、容器和節點來使用它們的正確數量。如果你對這些資源進行相應的管理，不僅可以節省成本，而且還可以確保重要的進程無論如何都能繼續運行。