「Bug」Kubernetes 节点出现 DiskPressure，并且自动恢复
2020-04-14
Bug 描述
测试机进行一次完整的部署(近 90 个新 Pod 被调度到同一个节点)后，通过 Dashboard 查看，发现 Pod 容器组有一个 Failed Pod。
容器总体个数正常，Failed Pod 是“多余的”。
排查流程
- 在 Dashboard 中查看该 Pod，只显示它处于 Failed 状态，没有更多提示。没什么用。。
- 通过 k9s 查看该 Pod 的详细信息，发现它是因为 DiskPressure 而被驱逐（Evicted）。
- 用 ssh 进入这个节点，通过
df -h命令确认磁盘状态，发现磁盘利用率为 46%，远低于 DiskPressure 的默认触发条件：85%。DiskPressure 自己消失了。。
既然磁盘压力自己恢复了，应该是 kubernetes 自己有某种清理策略，开始网上查询资料：
- 网上查询资料 Kubernetes Node节点DiskPressure异常处理，了解到是 kubelet 组件负责管理节点资源。
- 搜索到官方文档 kubernets - 回收节点资源
- 上述文档说在 with-imagefs 和 without-imagefs 时，遇到 DiskPressure，有不同的资源回收策略。
- 清理策略比较复杂，后面再讨论。
- 通过
vim查看 kubelet 日志/var/log/message，搜索关键字Evicted，DiskPressure，Pressure等，查找到了DiskPressure相关信息 - 观察 DiskPressure 日志的上下文，发现有
imageGCManager清理 image 相关的日志。这显然就是一个自动回收资源的事件。 - 搜索 kubernetes image gc，找到官方文档：配置 kubelet 垃圾回收策略
- 另有硬驱逐策略的默认阈值 Hard Eviction Thresholds 一致，
- 相关 Issue: Kubernetes Issue - Can we deprecate '--image-gc-high-threshold' and 'image-gc-low-threshold'
- 相关提案：Kubelet - Eviction Policy
分析结果
总的来说，就是 DiskPressure 是因为历史镜像过多引起的。目前有两种方法可以让 kubernetes 自己进行数据清理：
方法一：配置镜像的垃圾回收策略
已被标记为弃用
这涉及到两个参数:
image-gc-high-threshold: 当磁盘使用率超过这个值时，就会触发镜像回收器。默认值为 85%。image-gc-low-threshold: 当镜像回收器被触发后，它至少会使磁盘使用率低于这个阈值（否则不会停）。默认值为 80%。
方法二：配置驱逐策略（推荐）
根据官方文档说明，为了统一 kubernetes 中的资源回收参数，未来将弃用方法一。
新的镜像GC策略已经被合并到了Pod驱逐策略中，详细的配置方法见下文。
容器镜像GC、Pod驱逐以及节点压力
节点压力 DiskPressure 会导致 Pod 被驱逐，也会触发容器镜像的 GC。
根据官方文档 配置资源不足时的处理方式，Kubelet 提供如下用于配置容器 GC 及 Evicetion 的阈值：
--eviction-hard和eviction-soft: 对应旧参数--image-gc-high-threshold，这两个参数配置镜像 GC 及驱逐的触发阈值。磁盘使用率的阈值默认为 85%- 区别在于
eviction-hard是立即驱逐，而eviction-soft在超过eviction-soft-grace-period之后才驱逐。
- 区别在于
--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
