仓库 GC 是什么
镜像仓库删除 manifest 或标签后，底层 blob 不会自动消失：blob 按内容寻址、可能被多个 manifest 共享，必须执行仓库自己的垃圾回收流程来释放无引用空间。判断是否需要 GC 的最直接信号是「删了镜像但存储不降」。自建 registry 手动执行，Harbor 有 GC 任务，云托管仓库多数已自动化。
基本信息
| 原理 | 先解除引用，再回收无引用 blob |
|---|---|
| 工具 | 自建 registry 的 garbage-collect 命令；Harbor 的 GC 任务 |
| 窗口 | 安排在低峰并避免与推送并发 |
| 频率 | 定期执行（如月度），不要等磁盘告警才想起 |
| 验证 | 对比执行前后存储占用与删除计数 |
典型使用场景
- 存储告警后的空间释放
- 例行维护：把 GC 纳入月度运维计划
- 保留策略收紧后回收历史遗留 blob
- Harbor 项目配额管理：GC 配合保留策略控制配额
- 迁移或备份前瘦身，降低传输量
- 接手旧仓库：先跑一次 GC 摸清真实占用再做容量规划
registry 官方工具
registry 官方工具
# registry 需以只读或停写状态运行
bin/registry garbage-collect /etc/docker/registry/config.yml
# 看输出中释放的 blob 数量与预期是否一致
du -sh /var/lib/registry # 执行前后对比实际占用按仓库类型选 GC 方式
| 类型 | 方式 | 注意 |
|---|---|---|
| Docker registry | 命令行 garbage-collect | 需停写或只读模式 |
| Harbor | 面板 GC 任务 | 看任务日志与配额变化 |
| 云托管仓库 | 平台自动化 | 特殊保留规则仍要人工核对 |
先做一次「删 tag 后存储未下降」的验证，确认 GC 流程真的在跑，不然清理只会停留在标签层面。
删标签与 GC 是两步：保留策略负责删引用，GC 负责回收空间，两步都配置好才真正省存储；缺了 GC 这一环，删除操作等于没做。
GC 期间别跑镜像扫描等重 IO 任务：资源竞争会拉长窗口，安排在维护时段，并把执行记录写进维护日志。