「Bug」Kubernetes 节点出现 DiskPressure，并且自动恢复

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