寻求Google Container Registry的中间件/代理及镜像清理方案

方案1：用GCP Audit Logs追踪镜像拉取事件 #

• 开启GCR的Data Access Audit Logs，所有镜像拉取操作都会被记录到Cloud Logging里
• 写个脚本定期查询Cloud Logging，提取镜像名称和对应的最后拉取时间，把数据存到Cloud Storage或者BigQuery里作为数据源
• 基于这个数据源，筛选出超过1个月未被拉取的镜像，用gcloud container images delete命令批量清理
• 优势：无需额外组件，完全依托GCP原生服务，数据准确；还能设置日志保留策略，避免存储冗余日志

方案2：Cloud Functions自动化追踪+清理 #

• 给Cloud Logging配置日志路由，让GCR的拉取日志触发Cloud Functions
• 在Cloud Functions里用Firestore维护一个镜像拉取时间的状态表，每次收到拉取日志就更新对应镜像的最后拉取时间
• 再配置定时触发的Cloud Functions，定期扫描Firestore里的记录，清理超过1个月未更新的镜像
• 优势：全Serverless架构，不用运维额外服务器，拉取时间自动更新，清理流程完全自动化

方案3：换用Artifact Registry替代GCR #

• GCP的Artifact Registry是GCR的升级版，原生支持查看镜像的最后拉取时间——用gcloud artifacts docker images describe命令就能拿到pullTime字段
• 直接用Artifact Registry的原生数据，写脚本定期查询所有镜像的最后拉取时间，筛选后执行清理
• 优势：原生提供所需字段，无需额外开发追踪逻辑，迁移成本低（GCR到Artifact Registry有官方迁移工具）

额外提示 #

• 清理前建议先给目标镜像加个to-delete标签，留1-2天缓冲期，防止误删正在使用的镜像
• 批量清理脚本先在测试环境验证逻辑，没问题再推广到生产环境

内容的提问来源于stack exchange，提问作者kadamb