K8s Node 從垃圾回收到資源殘留，你看明白了嗎？
眾所周知，K8s 的控制器是面向終態(tài)的控制循環(huán)模式，一般的控制循環(huán)不會考慮復雜狀態(tài)流轉(zhuǎn)，而是計算當前和預期的狀態(tài)差異，進行調(diào)整。但 Kubelet 是個例外，作為實際的資源控制者，有太多需要考慮的細節(jié)，因此許多非核心操作均是異步執(zhí)行，包括資源的垃圾回收。
什么是垃圾
Kubelet 視角的 Pod 狀態(tài)
Kubelet 的控制循環(huán)中有大量的狀態(tài)參數(shù)，這些異步的操作均依賴于這些狀態(tài)的準確性。但 Pod 依賴的組件和資源多種多樣，早期的 K8s 版本，因為狀態(tài)不準確、不一致、遺漏、竟態(tài)條件，導致的 Kubelet 行為異常的 Bug 比比皆是。
為了解決這些問題，Kubelet 提供了兩個不同的狀態(tài)子系統(tǒng)：：
- podManager：反映 Pod 從 APIServer 角度看的狀態(tài)，也就是期望狀態(tài)
- podWorkers：反映 Pod 從 Kubelet Worker 透出的狀態(tài)，也就是事實狀態(tài)
根據(jù)這兩個狀態(tài)以及對比，就可以算出當前 Pod 需要進行的操作，以及某些操作是否安全。資源垃圾回收和兩個 podWorkers 狀態(tài)相關(guān)：
狀態(tài)名 | 含義 | 可能的情況 |
| 是否應該積極清理所有和 Pod 相關(guān)的資源 | Pod 被驅(qū)逐 or Pod 被刪除并且容器停止 |
| 是否應該積極清理 Pod 的運行時資源 | 所有的容器已停止 |
容器回收策略
容器的回收以 1分鐘為間隔定期觸發(fā)，不支持修改頻率。其規(guī)則受到很多條件的限制，但基本可以分為下面幾個情況。
- 清理退出 Pod 的容器，如果 Pod 在 podWorkers 中處于下面的狀態(tài)，就觸發(fā)容器回收：
Pod 處于ShouldPodContentBeRemoved
Full GC 并且 Pod 處于 ShouldPodRuntimeBeRemoved
- 單個Pod 的非運行容器數(shù)超出限制（--maximum-dead-containers-per-container）
- 總非運行容器數(shù)超出限制（--maximum-dead-containers）
- 如果 2 和 3 無法同時滿足，則優(yōu)先保證 3
對于 k8s 管理的容器來說，不要通過 docker 等工具自行進行容器回收，有一些退出容器起到占位符的作用，如果被刪除，k8s 可能會重啟把容器拉起。比如 docker system prune 會清理掉 init container 的退出容器，Kubelet 會誤認為 init container 未執(zhí)行，嘗試將 init container 重新拉起（如果你的 Pod 無法重入，那就慘了）。
Sandbox 回收策略
Pod 生命周期主流程里并沒有同步的去刪除 Sandbox，而是依賴 GC 的能力完成 Sandbox 清理。
Sandbox 殘留是 containerd 場景下常見的問題，如果 containerd 部分資源釋放有問題，比如掛載點問題，偶見容器已經(jīng)清理但 Sandbox 還在。如果經(jīng)年累月，可能會出現(xiàn)這么一個錯誤日志（https://github.com/kubernetes/kubernetes/issues/63858）：
grpc: received message larger than max (4195017 vs. 4194304)Sandbox GC 發(fā)生在 Container GC 之后，基本策略是：
- 清理退出 Pod 的 Sandbox：
Pod 處于ShouldPodContentBeRemoved，刪除和 Pod 關(guān)聯(lián)的全部 Sandbox
Full GC 并且 Pod 處于 ShouldPodRuntimeBeRemoved，刪除和 Pod 關(guān)聯(lián)的全部 Sandbox
- 如果 Pod 還在運行中，則只保留一個 Sandbox
鏡像回收策略
鏡像的垃圾回收策略是個愛恨功能，有時候你覺得他太勤快了，仿佛容器剛停掉，鏡像就需要重新再拉取一遍，有時候你感覺他太保守了，節(jié)點頻繁在磁盤壓力徘徊。
其實為了保持二者的平衡，鏡像的回收策略略微復雜。和容器回收一樣，鏡像回收也是以一個固定的時間間隔觸發(fā)，目前是 5min ，不支持自定義配置。
影響 image 回收的配置：
- imageMaximumGCAge：如果設(shè)置，超過這個時間未使用鏡像則回收
- imageMinimumGCAge：雖然未使用，但小于這個值不會回收（避免清理剛拉取的鏡像）
- imageGCHighThresholdPercent：大于該閾值則進行清理
- imageGCLowThresholdPercent：小于該閾值則結(jié)束清理
工作流程
Contaienr GC
圖片
Container GC 過程：
- 按創(chuàng)建時間，依次判斷需要 GC 的容器
- 優(yōu)雅退出，和執(zhí)行 pre stop hook
- 調(diào)用 container runtime 操作：StopContainer
- 清理容器日志
- 調(diào)用 container runtime 操作：RemoveContainer
Sandbox GC 過程：
- 按創(chuàng)建時間，依次判斷需要 GC 的 Sandbox
- 如果 Sandbox 包含任何容器，則跳過 GC
- 對需要 GC 的 Sandbox 依次執(zhí)行 container runtime 操作：
StopPodSandbox
RemovePodSandbox
Image GC
鏡像回收有兩個重要的數(shù)據(jù)來源：
- imagesInUse ：每次觸發(fā)時獲取正在使用的 image，并更新 imageRecords 中的使用時間
- imageRecords：記錄了全量的 image，基于此數(shù)據(jù)進行可回收判斷
使用中的不回收
標記為 pinned 的不回收（https://github.com/containerd/containerd/pull/7944）
根據(jù)發(fā)現(xiàn)鏡像和使用時間進行排序
基本回收流程：
- 如果開啟了 imageMaximumGCAge 配置，則超過該時間的鏡像會被回收
- 如果沒有超過 imageGCHighThresholdPercent 則結(jié)束
- 嘗試清理鏡像到足夠滿足 imageGCLowThresholdPercent
在開始 gc 后拉取的鏡像不清理
小于 imageMinimumGCAge 的鏡像不清理
調(diào)用 container runtime 操作：RemoveImage
