镜像过期策略需基于标签与时间双维度精准清理：正式标签保留最近3个版本及90天内最新推送，临时标签按72小时无拉取标记，180天未拉取则入队；依托Harbor保留策略或registry工具自动执行，强制预览确认、灰度启用、窗口限流，并全程审计+白名单保护。
镜像过期策略的自动化管理，核心在于识别“哪些镜像该清理”和“何时触发清理”，而非单纯定时删除。关键不是删得快，而是删得准、可追溯、不误伤。
基于标签与时间双维度定义过期规则
仅按推送时间或创建时间判断容易误删——比如一个基础镜像可能多年未更新但仍在生产使用；而一个带 dev- 或 pr- 前缀的临时镜像，即使刚推3小时也应快速清理。推荐组合策略：
- 对 main、vX.Y.Z 等正式标签，保留最近3个版本 + 最近90天内最新推送的任意版本
- 对 feature/、hotfix/、build- 类前缀标签，统一设置为“72小时内无拉取记录即标记为待清理”
- 所有镜像若超过180天未被任何项目拉取（需对接仓库访问日志或 Prometheus 指标），自动进入过期队列
利用仓库原生能力或轻量工具实现自动标记与清理
避免自研复杂调度器。优先用已有生态工具降低维护成本：
- Docker Registry 配合 registry-cli 或 reg 工具，通过 API 查询镜像元数据（如
last_pushed、tags），脚本化执行过滤与删除 - Harbor 用户直接启用内置的 Retention Policy：支持按标签正则、推送时间、拉取时间、是否被项目引用等条件组合配置，策略生效后自动归档/删除
- 私有 registry 若支持 OCI Distribution Spec v1.1+，可调用
GET /v2/<name>/referrers检查镜像是否被 Helm Chart 或其他镜像多层引用，防止级联误删
清理前强制校验与灰度执行
自动化清理必须带“刹车机制”，否则一次误配可能导致服务中断：
- 每次清理任务启动前，生成预览报告：列出将被删除的镜像名、标签、大小、最后拉取时间，并发送到企业微信/Slack频道供人工确认
- 首次启用策略时，默认只标记（tag）为 expired，不实际删除；持续运行3天无告警后再开启真实删除开关
- 生产环境清理限制为每周二凌晨2:00–4:00窗口期，且单次最多清理50个镜像，避免 I/O 打满影响拉取性能
审计与回滚能力不可省略
删掉的镜像无法恢复，但操作过程必须全程留痕：
- 所有清理动作写入结构化日志（含操作人、策略ID、匹配规则、实际删除列表、耗时），接入 ELK 或 Loki 统一检索
- 关键仓库配置定期备份（如 Harbor 的 retention_policies 表、Registry 的 config.yml + hooks），备份频率不低于每日一次
- 为高频使用的 base 镜像（如 ubuntu:22.04、node:18-alpine）设置白名单，禁止任何策略触达
不复杂但容易忽略：过期策略的有效性，取决于你能否准确知道“谁在用哪个镜像”。没有拉取行为采集，所有时间规则都是拍脑袋。先打通可观测性，再谈自动化。
