在容器化部署规模扩大之后，镜像仓库里的镜像数量往往会以肉眼可见的速度膨胀。如果不加干预，几个月之内就可能因为堆积大量中间构建产物和过期版本，导致磁盘被写满、推送失败甚至节点拉取超时。设计一套科学的镜像清理策略与保留规则，核心目标是在控制存储成本的同时，保证出问题能回滚、审计能溯源。
镜像膨胀的真实成因与清理误区
很多团队第一次遇到仓库爆满时，直觉反应就是写个脚本把最老的镜像删掉。这种做法看似简单，却容易踩坑。镜像并非普通文件，它是由多个只读层叠加而成， registry 在删除某个标签时，如果底层共享层仍被其他镜像引用，实际空间并不会立刻释放，必须配合垃圾回收（GC）才能回收物理存储。忽略这一步，就会看到数据库里标签没了，但磁盘占用纹丝不动。
另一个常见误区是把所有带 latest 标签的镜像当作可删对象。实际上不少 CI 流程会用 latest 承载生产发布，盲目清理会直接切断回滚路径。更合理的认知是：镜像该不该留，取决于它的业务身份，而不是它的名字长得像不像临时产物。我们需要先把镜像按用途分类，再决定保留时长。
从存储原理看，Docker 镜像的层通过内容寻址存储（CAS）管理，相同层只存一份。当使用 docker image prune 或 registry API 删除清单时，只是解除了引用。真正的空间释放要执行 registry garbage-collect 并重启或重载 registry。理解这一点，才能避免清理策略停留在表面删除。
基于多维标签的保留规则设计
保留规则如果只写保留最近七天，往往会误伤仍在使用的版本。推荐的做法是在构建阶段就给镜像打上多维标签，例如 env=prod、branch=release-1.2、build_id=20240101-12。清理任务读取这些标签后，按业务维度分别设定保留数。比如生产环境保留最近十个正式版，测试环境只留当天三个。
下面这段伪代码展示了如何根据标签筛选待删镜像：
#!/bin/bash
# 列出所有镜像并提取标签信息
images=$(registry_api list --format json)
for img in $images; do
env=$(echo $img | jq -r '.labels.env')
tag=$(echo $img | jq -r '.tag')
if [ "$env" = "test" ]; then
# 测试环境超过1天且非最新则标记删除
if [ $(date -d $img.created +%s) -lt $(date -d '1 day ago' +%s) ]; then
echo "delete $tag"
fi
elif [ "$env" = "prod" ]; then
# 生产环境保留最近10个
count=$(registry_api count --env prod)
if [ $count -gt 10 ]; then
echo "delete old prod $tag"
fi
fi
done
这种规则的优势在于可解释性强，运维人员一眼能看懂为什么某个镜像被留下来。相比单纯按时间滚动，它降低了误删概率。缺点是需要在 CI 里规范打标，初期接入成本稍高，但长期收益明显。
如果团队暂时无法改造 CI 打标，也可以退而求其次，用镜像仓库自带的保留策略功能。例如 Harbor 支持按仓库级别设置保留最近 N 个标签或按天数保留。虽然灵活度不如自定义标签，但配置简单，适合中小团队快速落地。
自动化清理与垃圾回收的落地实践
策略定好之后，必须做成定时任务而非人工操作。可以用 Kubernetes CronJob 每周执行一次清理脚本，先调用 registry 删除 API 解引用，再触发 GC。注意 GC 期间 registry 最好设为只读，防止写冲突导致层损坏。以下示例展示了一个最简的 GC 触发方式：
apiVersion: batch/v1
kind: CronJob
metadata:
name: registry-gc
spec:
schedule: "0 3 * * 0"
jobTemplate:
spec:
template:
spec:
containers:
- name: gc
image: registry:2
command:
- /bin/sh
- -c
- "registry garbage-collect /etc/registry/config.yml"
restartPolicy: OnFailure
在执行 GC 前，建议先跑一遍干跑模式（dry-run），确认即将删除的层不会影响其他关键镜像。很多 registry 的 GC 命令支持 --dry-run 参数，输出会被删清单而不实际删除。这一步能拦住绝大多数误操作。
此外，清理策略要和备份机制配合。即使规则写得再严谨，也可能因标签错乱误删。保留一份最近一周的镜像清单快照，记录镜像摘要和来源构建，可以在出事后快速从异地仓库重新同步。清理不是目的，让仓库既瘦又稳才是目标。把保留规则文档化，每次调整都走评审，才能避免策略随时间腐化。
不同规模团队的策略取舍
对于只有两三个服务的初创团队，手动加简单定时脚本就够用。他们镜像变更不频繁，存储压力小，过度设计反而增加负担。此时保留规则可以粗暴些：除 latest 和当前版本外，其余只留三天。
当服务数涨到几十个，就必须引入标签维度和自动 GC。这个阶段最怕各个仓库规则不统一，建议由平台组提供基础脚本，业务线只填保留天数与保留数。用一张配置表集中管理，能减少沟通成本。
大型组织还要考虑多区域同步。清理主仓库后，边缘节点若没同步删除，会出现元数据不一致。应在清理完成后触发通知，让同步组件补齐删除事件。只有把清理当作分布式系统的一部分，规则才不会在复杂环境下失效。
image_cleanupretention_policyregistry_gc修改时间：2026-08-18 06:18:29