K8s 节点磁盘：imageGCHighThresholdPercent 默认 80% 触发太晚，Pod 连环驱逐怎么提前预警？

【背景】 我维护一个 8 节点（16C64G，Kubernetes 1.28.9，containerd 1.7.13，cgroup v2，100GB 系统盘）的生产集群，CNI 是 Calico 路由模式。最近 2 个月节点磁盘压力明显上来：镜像拉取高峰（每天 14:00~16:00 集中发版）期间，/var/lib/containerd 占比会在 30 分钟内从 55% 冲到 82%。

【现象】

• 节点磁盘使用率越过 80% 后，kubelet 触发 image GC，开始删旧镜像；
• 但 GC 是异步的，删一个 2GB 的 Java 基础镜像要 30~60s，期间新镜像还在拉；
• 结果：某台节点在 14:23 一次性驱逐了 7 个 Pod（事件里写的是 Evicted: container runtime image GC），业务侧看到一波 5xx；
• 监控里 kubelet_running_pods 下跌、node_filesystem_available_bytes 触底、containerd images 目录 size 曲线和驱逐事件时间对不上——GC 还没删完，Pod 已经被杀了。

【已尝试的排查】

1. 把 kubelet.imageGCHighThresholdPercent 从默认 80 调到 70、imageGCLowThresholdPercent 从 80 调到 60，驱逐从 7 个降到 2 个，但没归零；
2. 给所有 Pod 加了 ephemeral-storage 的 request（500Mi），调度器会把 Pod 往磁盘余量大的节点放，效果有限——因为驱逐发生在运行中的 Pod 上，调度器事前不知道；
3. 查了 containerd 的 content 目录，发现大量按 sha256 命名的 layer 是"被引用但没人用"的孤儿，ctr images ls 看不到但占空间；
4. 没试过：containerd 自定义 GC 策略、节点本地 registry 缓存、镜像分层压缩（zstd）。

【期望的回答】 想听听大家在生产里真正生效的组合：

• imageGCHighThresholdPercent / imageGCLowThresholdPercent 你们配多少？依据是什么（镜像大小？拉取带宽？驱逐容忍度？）；
• 有没有人踩过"阈值调低反而 GC 更频繁、拉取风暴更严重"的反噬？怎么破？
• containerd 1.7 的 content 目录孤儿 layer 怎么安全清理？有没有比 ctr images prune 更细粒度的手段？
• 如果节点磁盘真的不够（100GB 系统盘 + 大镜像），除了扩容，还有什么"软"手段能降低驱逐概率？
• 监控侧：除了 node_filesystem_available_bytes，还有哪些指标能提前预警 image GC 即将触发（比如 containerd 的 images 数量、content 目录增长速率）？