2020-04-14

Bug 描述

測試機進行一次完整的部署(近 90 個新 Pod 被排程到同一個節點)後，通過 Dashboard 檢視，發現 Pod 容器組有一個 Failed Pod。
容器總體個數正常，Failed Pod 是“多餘的”。

排查流程

1. 在 Dashboard 中檢視該 Pod，只顯示它處於 Failed 狀態，沒有更多提示。沒什麼用。。
2. 通過 k9s 檢視該 Pod 的詳細資訊，發現它是因為 DiskPressure 而被驅逐（Evicted）。
3. 用 ssh 進入這個節點，通過 df -h 命令確認磁碟狀態，發現磁碟利用率為 46%，遠低於 DiskPressure 的預設觸發條件：85%。DiskPressure 自己消失了。。

既然磁碟壓力自己恢復了，應該是 kubernetes 自己有某種清理策略，開始網上查詢資料：

1. 網上查詢資料 Kubernetes Node節點DiskPressure異常處理，瞭解到是 kubelet 元件負責管理節點資源。
2. 搜尋到官方文件 kubernets - 回收節點資源
   • 上述文件說在 with-imagefs 和 without-imagefs 時，遇到 DiskPressure，有不同的資源回收策略。
   • 清理策略比較複雜，後面再討論。
3. 通過 vim 檢視 kubelet 日誌 /var/log/message，搜尋關鍵字 Evicted，DiskPressure，Pressure
   等，查詢到了 DiskPressure 相關資訊
4. 觀察 DiskPressure 日誌的上下文，發現有 imageGCManager 清理 image 相關的日誌。這顯然就是一個自動回收資源的事件。
5. 搜尋 kubernetes image gc，找到官方文件：配置 kubelet 垃圾回收策略
6. 另有硬驅逐策略的預設閾值 Hard Eviction Thresholds 一致，
7. 相關 Issue: Kubernetes Issue - Can we deprecate '--image-gc-high-threshold' and 'image-gc-low-threshold'
8. 相關提案：Kubelet - Eviction Policy

分析結果

總的來說，就是 DiskPressure 是因為歷史映象過多引起的。目前有兩種方法可以讓 kubernetes 自己進行資料清理：

方法一：配置映象的垃圾回收策略

已被標記為棄用

這涉及到兩個引數:

1. image-gc-high-threshold: 當磁碟使用率超過這個值時，就會觸發映象回收器。預設值為 85%。
2. image-gc-low-threshold: 當映象回收器被觸發後，它至少會使磁碟使用率低於這個閾值（否則不會停）。預設值為 80%。

方法二：配置驅逐策略（推薦）

根據官方文件說明，為了統一 kubernetes 中的資源回收引數，未來將棄用方法一。

新的映象GC策略已經被合併到了Pod驅逐策略中，詳細的配置方法見下文。

容器映象GC、Pod驅逐以及節點壓力

節點壓力 DiskPressure 會導致 Pod 被驅逐，也會觸發容器映象的 GC。

根據官方文件 配置資源不足時的處理方式，Kubelet 提供如下用於配置容器 GC 及 Evicetion 的閾值：

1. --eviction-hard 和 eviction-soft: 對應舊引數 --image-gc-high-threshold，這兩個引數配置映象 GC 及驅逐的觸發閾值。磁碟使用率的閾值預設為 85%
   1. 區別在於 eviction-hard 是立即驅逐，而 eviction-soft 在超過 eviction-soft-grace-period 之後才驅逐。
2. --eviction-minimum-reclaim: 對應舊引數 --image-gc-low-threshold。這是進行資源回收（映象GC、Pod驅逐等）後期望達到的磁碟使用率百分比。磁碟使用率的閾值預設值為 80%。

問：能否為 ImageGC 設定一個比 DiskPressure 更低的閾值？因為我們希望能自動進行映象 GC，但是不想立即觸發 Pod 驅逐。

答：這應該可以通過設定 eviction-soft 和長一點的 eviction-soft-grace-period 來實現。
另外 --eviction-minimum-reclaim 也可以設小一點，清理得更乾淨。示例如下：

--eviction-soft=memory.available<1Gi,nodefs.available<2Gi,imagefs.available<200Gi
--eviction-soft-grace-period=3m
--eviction-minimum-reclaim=memory.available=0Mi,nodefs.available=1Gi,imagefs.available=2Gi