卡瓦邦噶！
·
Harbor GC 问题
内容提要
最近忙于处理 Harbor 镜像存储服务，面对大量 Docker 镜像和复杂的删除流程。通过改进 GC 逻辑，使用 Python 脚本实现自动化，删除效率提升至3天，解决了人工操作的繁琐问题。
关键要点
-
最近忙于处理 Harbor 镜像存储服务，面临大量 Docker 镜像和复杂的删除流程。
-
Harbor 存储的 Docker 镜像数量庞大，存储容量已达到 PiB 级别。
-
删除镜像的流程复杂，包括删除 Tag、扫描数据库和删除未引用的 blob。
-
引用计数适合此场景，但 Harbor 没有采用，官方使用 Mark and Sweep 方案。
-
Harbor 的 GC 方案运行时间过长，之前的负责人设计了针对性改进。
-
通过 SQL 查询和 API 删除镜像，使用 web UI 触发 GC 逻辑。
-
改进后，整体运行时间缩短至一个月，但仍存在问题。
-
使用 Python 脚本自动化 GC 逻辑，运行时间缩短至 3 天。
-
上一个负责人的文档详细记录了 Harbor GC 的逻辑和改进点。
-
另一个同事搭建新 Harbor 集群，使用运维手段解决技术问题。
延伸问答
Harbor GC 的主要问题是什么？
Harbor 的 GC 方案运行时间过长，之前需要超过一个月才能完成一次 GC。
如何改进 Harbor 的 GC 逻辑？
通过使用 Python 脚本自动化 GC 逻辑，整体运行时间缩短至 3 天，减少了人工操作。
Harbor 中删除镜像的复杂流程包括哪些步骤？
删除镜像的流程包括删除 Tag、扫描数据库找到未引用的 blob、删除这些未被引用的 blob。
为什么 Harbor 没有使用引用计数方案？
Harbor 没有采用引用计数方案，可能是因为维护引用记录较难，容易导致数据误删或垃圾产生。
如何通过 SQL 查询优化 Harbor 的 GC 过程？
可以通过 SQL 查询判断是否需要保留每个 image，只保留最近的 3 个版本，利用 API 删除不需要的镜像。
在 Harbor 中，如何处理未引用的 blob？
需要扫描整个数据库，找到没有被任何其他 image 和 tag 引用的 blob，才能进行删除。
