containerd 镜像 GC 阈值在生产集群里怎么权衡？调低怕拉取失败，调高怕驱逐

背景 我维护一个 48 台 worker（8C16G，200GB 系统盘）的 K8s 1.28 集群，containerd 1.7，私有 Harbor 单节点。业务镜像偏大（基础镜像 + 依赖层，单镜像 1.8~2.4GB），发布节奏是每天 3~4 次滚动更新，一次发布要在 48 个节点上并发拉取。

现象 最近两个月出现两类互相矛盾的故障：

1. 一次大版本发布（镜像 2.4GB）进行到一半，3 台节点同时触发 kubelet 的 imagefs.available < 10% 驱逐，20 多个 Pod 被赶走，其中 2 个是有状态服务，RPO 损失约 15 分钟；
2. 我把 containerd 的 imageGCHighThreshold 从默认 85% 调到 70%、imageGCLowThreshold 从 80% 调到 60% 之后，GC 触发明显变频繁，有 2 次在 GC 进行中撞上发布窗口，拉取被 containerd 限流，出现 context deadline exceeded (Client.Timeout)，回滚了 4 个版本。

已尝试的排查

• 用 crictl images + du -sh /var/lib/containerd 确认了节点上历史镜像累积是主因（单节点最多堆了 40+ 个 tag，其中 60% 是 3 个月前的旧版本）；
• 看了 kubelet 的 --image-gc-high-threshold=85 / --image-gc-low-threshold=80，和 containerd 侧的阈值目前是双套在跑，不清楚哪个实际生效、是不是叠加；
• 没有上镜像预拉（k8s-device-plugin / warmup 之类的方案成本没算清，暂时不想动）；
• 没有清理策略：旧 tag 全靠节点自然 GC，没有 Harbor 侧的 tag 保留策略配合。

期望得到的答案形态 想问三个具体点，越具体越好，最好带可复现的配置片段或命令：

1. kubelet 的 image-gc 阈值和 containerd 的 imageGCHighThreshold 到底谁说了算？ 两者数值不一致时实际行为是什么？生产上推荐只保留一套还是两套对齐？
2. 阈值本身给个区间参考：在「200GB 系统盘 + 单镜像 2GB + 每天 3~4 次发布」这个组合下，你们线上一般把 High/Low 设在哪一档？有没有「阈值 + 保留 tag 数」的更稳组合？
3. GC 期间拉取被限流这个坑，除了错峰发布，有没有在 containerd / kubelet / Harbor 侧的配置能缓解（比如并发拉取上限、GC 速率限制、Harbor 侧 tag 保留策略）？

欢迎直接贴你们线上的 containerd config.toml 片段（脱敏）和 kubelet 启动参数，比抽象建议有用。