关键在于立即确认真实占用并安全删除未引用镜像，同时将imageGCHighThresholdPercent调至75%以避免ImageGCFailed频发和Pod驱逐；需比对crictl ps -a与所有Pod spec中的image字段，仅删除两者均未引用的镜像，优先用crictl rmi --prune，紧急时用ctr -n k8s.io i prune --all。
直接触发清理并防止反复报 ImageGCFailed，关键不是等 kubelet 自动 GC，而是立刻确认镜像真实占用、安全删除未引用镜像，并调低 GC 触发阈值——默认 85% 太高，磁盘一到这个水位，Pod 就可能被驱逐。
怎么快速确认哪些镜像是真闲置的
不能只看 crictl images 列表，也不能只看 crictl ps -a 里有没有运行容器。真正“可删”的镜像必须同时满足：没被任何容器使用（crictl ps -a 输出中不出现其 ID 或 digest），也没被任何 Pod spec 引用（即不在 kubectl get pods -A -o jsonpath='{.items[*].spec.containers[*].image}' 结果里）。
- 先确保
crictl配置正确：/etc/crictl.yaml中runtime-endpoint指向unix:///var/run/containerd/containerd.sock - 查所有镜像 ID（推荐用 digest）：
crictl images --quiet - 查所有容器引用的镜像 digest：
crictl ps -a -o jsonpath='{.items[*].image.image}' | tr ' ' '\n' | sort -u - 比对后剩余的 digest，就是可安全清理的目标
用 crictl rmi --prune 还是 ctr -n k8s.io i prune
两者都能删未引用镜像，但行为有差异：crictl rmi --prune 是 kubelet 兼容方式，会尊重 imageMinimumGCAge（默认 2 分钟），跳过刚拉取的镜像；而 ctr -n k8s.io i prune 更底层、更激进，不走 kubelet GC 流程，也不受 age 限制，适合紧急清空，但风险略高——比如刚更新 Deployment、新镜像还没被容器启动，就可能被误删。
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 日常运维优先用
crictl rmi --prune - 磁盘已满、
ImageGCFailed频发且需秒级释放空间时，才用ctr -n k8s.io i prune --all - 执行前建议先
systemctl stop kubelet，避免 GC 和手动清理并发冲突
为什么调低 imageGCHighThresholdPercent 比手动清理更重要
手动删一次只能解燃眉之急；若不调阈值，kubelet 仍要等到磁盘 85% 才触发 GC，而这时节点往往已开始驱逐 Pod。实际生产中，70%～75% 是更稳妥的触发点——给 GC 留出执行时间，也避免 IO 峰值叠加。
- 编辑
/var/lib/kubelet/config.yaml，加入或修改： imageGCHighThresholdPercent: 75imageGCLowThresholdPercent: 65imageMinimumGCAge: "10m"- 改完后必须重启 kubelet：
systemctl daemon-reload && systemctl restart kubelet - 验证是否生效：
ps aux | grep kubelet看启动参数是否含对应 flag（如被命令行参数覆盖，config.yaml 设置会被忽略）
最常被忽略的一点：kubelet 的 GC 不清理 pause 镜像，但 ctr 和 crictl 会把它当普通镜像对待。如果看到大量 registry.k8s.io/pause 镜像堆积，别急着全删——确认当前节点 Kubernetes 版本所需的 pause 版本，只保留一个匹配的，其余再清理。
