Kubernetes Pod驅(qū)逐怎么理解

本篇內(nèi)容主要講解“Kubernetes Pod驅(qū)逐怎么理解”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“Kubernetes Pod驅(qū)逐怎么理解”吧!

在 Kubernetes 中，Pod 使用的資源最重要的是 CPU、內(nèi)存和磁盤 IO，這些資源可以被分為可壓縮資源（CPU）和不可壓縮資源（內(nèi)存，磁盤 IO）?？蓧嚎s資源不可能導致 Pod 被驅(qū)逐，因為當 Pod 的 CPU 使用量很多時，系統(tǒng)可以通過重新分配權重來限制 Pod 的 CPU 使用。而對于不可壓縮資源來說，如果資源不足，也就無法繼續(xù)申請資源（內(nèi)存用完就是用完了），此時 Kubernetes 會從該節(jié)點上驅(qū)逐一定數(shù)量的 Pod，以保證該節(jié)點上有充足的資源。

當不可壓縮資源不足時，Kubernetes 是通過 kubelet 來驅(qū)逐 Pod 的。kubelet 也不是隨機驅(qū)逐的，它有自己的一套驅(qū)逐機制，每個計算節(jié)點的 kubelet 都會通過抓取 cAdvisor 的指標來監(jiān)控節(jié)點的資源使用量，下面我們來具體分析每種情況。

1. 存儲資源不足

下面是 kubelet 默認的關于節(jié)點存儲的驅(qū)逐觸發(fā)條件：

• nodefs.available<10%（容器 volume 使用的文件系統(tǒng)的可用空間，包括文件系統(tǒng)剩余大小和 inode 數(shù)量）

• imagefs.available<15%（容器鏡像使用的文件系統(tǒng)的可用空間，包括文件系統(tǒng)剩余大小和 inode 數(shù)量）

當 imagefs 使用量達到閾值時，kubelet 會嘗試刪除不使用的鏡像來清理磁盤空間。

當 nodefs 使用量達到閾值時，kubelet 就會拒絕在該節(jié)點上運行新 Pod，并向 API Server 注冊一個 DiskPressure condition。然后 kubelet 會嘗試刪除死亡的 Pod 和容器來回收磁盤空間，如果此時 nodefs 使用量仍然沒有低于閾值，kubelet 就會開始驅(qū)逐 Pod。從 Kubernetes 1.9 開始，kubelet 驅(qū)逐 Pod 的過程中不會參考 Pod 的 QoS，只是根據(jù) Pod 的 nodefs 使用量來進行排名，并選取使用量最多的 Pod 進行驅(qū)逐。所以即使 QoS 等級為 Guaranteed 的 Pod 在這個階段也有可能被驅(qū)逐（例如 nodefs 使用量最大）。如果驅(qū)逐的是 Daemonset，kubelet 會阻止該 Pod 重啟，直到 nodefs 使用量超過閾值。

如果一個 Pod 中有多個容器，kubelet 會根據(jù) Pod 中所有容器的 nodefs 使用量之和來進行排名。即所有容器的 container_fs_usage_bytes 指標值之和。

舉個栗子，假設某計算節(jié)點上運行著一系列已知 QoS 等級和 nodefs 使用量的 Pod：

當 nodefs 的使用量超過閾值時，kubelet 會根據(jù) Pod 的 nodefs 使用量來對 Pod 進行排名，首先驅(qū)逐使用量最多的 Pod。排名如下圖所示：

可以看到在本例中，QoS 等級為 Guaranteed 的 Pod 最先被驅(qū)逐。

2. 內(nèi)存資源不足

下面是 kubelet 默認的關于節(jié)點內(nèi)存資源的驅(qū)逐觸發(fā)條件：

• memory.available<100Mi

當內(nèi)存使用量超過閾值時，kubelet 就會向 API Server 注冊一個 MemoryPressure condition，此時 kubelet 不會接受新的 QoS 等級為 Best Effort 的 Pod 在該節(jié)點上運行，并按照以下順序來驅(qū)逐 Pod：

• Pod 的內(nèi)存使用量是否超過了 request 指定的值

• 根據(jù) priority 排序，優(yōu)先級低的 Pod 最先被驅(qū)逐

• 比較它們的內(nèi)存使用量與 request 指定的值之差。

按照這個順序，可以確保 QoS 等級為 Guaranteed 的 Pod 不會在 QoS 等級為 Best Effort 的 Pod 之前被驅(qū)逐，但不能保證它不會在 QoS 等級為 Burstable 的 Pod 之前被驅(qū)逐。

如果一個 Pod 中有多個容器，kubelet 會根據(jù) Pod 中所有容器相對于 request 的內(nèi)存使用量與之和來進行排名。即所有容器的 （container_memory_usage_bytes 指標值與 container_resource_requests_memory_bytes 指標值的差）之和。

繼續(xù)舉例，假設某計算節(jié)點上運行著一系列已知 QoS 等級和內(nèi)存使用量的 Pod：

當節(jié)點的內(nèi)存使用量超過閾值時，kubelet 會根據(jù) Pod 相對于 request 的內(nèi)存使用量來對 Pod 進行排名。排名如下所示：

可以看到在本例中，可以看到在本例中，QoS 等級為 Guaranteed 的 Pod 在 QoS 等級為 Burstable 的 Pod 之前被驅(qū)逐。

當內(nèi)存資源不足時，kubelet 在驅(qū)逐 Pod 時只會考慮 requests 和 Pod 的內(nèi)存使用量，不會考慮 limits。

3. Node OOM (Out Of Memory)

因為 kubelet 默認每 10 秒抓取一次 cAdvisor 的監(jiān)控數(shù)據(jù)，所以有可能在 kubelet 驅(qū)逐 Pod 回收內(nèi)存之前發(fā)生內(nèi)存使用量激增的情況，這時就有可能觸發(fā)內(nèi)核 OOM killer。這時刪除容器的權利就由kubelet 轉交到內(nèi)核 OOM killer 手里，但 kubelet 仍然會起到一定的決定作用，它會根據(jù) Pod 的 QoS 來設置其 oom_score_adj 值：

如果該節(jié)點在 kubelet 通過驅(qū)逐 Pod 回收內(nèi)存之前觸發(fā)了 OOM 事件，OOM killer 就會采取行動來降低系統(tǒng)的壓力，它會根據(jù)下面的公式來計算 oom_score 的值：

容器使用的內(nèi)存占系統(tǒng)內(nèi)存的百分比 + oom_score_adj = oom_score

OOM killer 會殺掉 oom_score_adj 值最高的容器，如果有多個容器的 oom_score_adj 值相同，就會殺掉內(nèi)存使用量最多的容器（其實是因為內(nèi)存使用量最多的容器的 oom_score 值最高）。關于 OOM 的更多內(nèi)容請參考：Kubernetes 內(nèi)存資源限制實戰(zhàn)。

假設某節(jié)點運行著 4 個 Pod，且每個 Pod 中只有一個容器。每個 QoS 類型為 Burstable 的 Pod 配置的內(nèi)存 requests 是 4Gi，節(jié)點的內(nèi)存大小為 30Gi。每個 Pod 的 oom_score_adj 值如下所示：

當調(diào)用 OOM killer 時，它首先選擇 oom_score_adj 值最高的容器（1000），這里有兩個容器的 oom_score_adj 值都是 1000，OOM killer 最終會選擇內(nèi)存使用量最多的容器。

到此，相信大家對“Kubernetes Pod驅(qū)逐怎么理解”有了更深的了解，不妨來實際操作一番吧！這里是億速云網(wǎng)站，更多相關內(nèi)容可以進入相關頻道進行查詢，關注我們，繼續(xù)學習！