真正达成自适应轮转的关键在于协同调整高低水位与镜像存活年龄策略：将imageGCHighThresholdPercent降至70–75%、imageGCLowThresholdPercent降至60–65%，并延长minimumImageTTLDuration至24h或48h，使Kubelet优先清理“闲置且陈旧”镜像。
直接调高 imageGCHighThresholdPercent 并不能实现“老旧闲置镜像的自适应轮转”——它只是推迟垃圾回收触发时机，反而可能让旧镜像堆积更久。真正达成自适应轮转的关键，在于**协同调整高低水位与镜像存活年龄策略**，让 Kubelet 在资源压力可控前提下，优先清理真正“闲置且陈旧”的镜像。
理解轮转本质：不是删得越早越好，而是删得更准
Kubelet 的镜像 GC 本身已是 LRU（最近最少使用）机制，但默认配置下容易误伤刚拉取的新镜像，或放过长期未用却“不够老”的旧镜像。所谓“自适应”，是指让清理行为随节点实际负载波动、镜像真实老化程度动态响应，而非固定周期硬删除。
核心参数组合优化方案
需同时调整三项参数，形成闭环控制：
-
降低
imageGCHighThresholdPercent至 70–75%：提前触发 GC，避免磁盘突然冲高引发 DiskPressure 污点；不建议低于 65%，否则可能频繁触发干扰稳定运行 -
同步下调
imageGCLowThresholdPercent至 60–65%：扩大清理窗口（例如 75%→62%），确保单次 GC 能实质性释放空间，而非“擦边式”小幅回收 -
显著延长
minimumImageTTLDuration至 24h 或 48h：这是实现“老旧”判定的核心。默认 2 分钟仅防误删，设为 24 小时后，所有未被任何容器引用、且存在超一天的镜像，才进入可清理队列
配合运行时行为强化轮转效果
仅改参数还不够，需匹配实际使用模式：
- 确认容器运行时（如 containerd）未绕过 Kubelet 管理——手动
ctr images pull或crictl pull的镜像仍会被 GC 扫描，但若对应容器非 Pod 管理，则 Kubelet 无法感知其引用关系，易被误删。建议统一通过 Pod spec 拉取镜像 - 避免在节点上长期运行调试用的
docker run --rm类临时容器，因其退出后镜像引用立即消失，若 TTL 过短（如默认 2m），极易被快速清理，影响复现效率 - 对确需保留的中间镜像（如 base 镜像、安全扫描镜像），可打固定标签（如
:keep）并配合外部脚本定期检查，Kubelet 不识别标签，但可作为人工治理依据
验证与持续观察要点
调整后不要只看“是否删了”，而要看“删得是否合理”：
- 执行
kubectl describe node <node>查看Conditions中是否有DiskPressure，以及Images统计是否趋于平稳 - 在节点上运行
crictl images --quiet | xargs -n1 crictl inspect | jq '.status.createdAt'（containerd 场景），抽样检查被删镜像的创建时间是否普遍 ≥24h - 观察 GC 日志：
journalctl -u kubelet -n 100 --no-pager | grep "imageGC"，确认每次清理是否达到目标阈值且有明确释放量
