Harbor OVA 版垃圾回收（Garbage Collection）功能验证指南与实现原理

Harbor OVA 版垃圾回收Garbage Collection功能验证指南与实现原理【免费下载链接】harborAn open source trusted cloud native registry project that stores, signs, and scans content.项目地址: https://gitcode.com/GitHub_Trending/ha/harbor本指南以 Harbor OVA 虚拟机的垃圾回收Garbage CollectionGC验证流程为核心完整覆盖从部署 OVA、推送与删除镜像、到通过重启触发 GC 并核对磁盘空间的每一步实操细节同时结合 Harbor 源码GC 控制器与 GC Job 实现深入解释 GC 的 mark/sweep 工作原理。读完本文你将掌握如何在 OVA 环境中验证 Harbor 的 GC 功能、如何判定回收是否成功以及 GC 在底层是如何识别并删除无引用数据块的。背景OVA 版 Harbor 与垃圾回收Harbor 是一个开源的云原生镜像仓库支持内容签名与漏洞扫描。OVAOpen Virtual Appliance是 Harbor 针对 vSphere 环境提供的虚拟设备交付形态将 Harbor 的整套组件core、registry、jobservice、postgresql、redis 等打包进一台虚拟机可通过 vCenter 直接部署适合在 ESXi 环境中快速落地。关于 OVA 部署方式的更多用例可参考 tests/testcases/Group5-OVA-install-config 目录下的网络配置5-01、重启5-02、HTTPS5-04、LDAP 集成5-05等测试用例。在 Harbor 中用户在 UI 或通过 Docker CLI 删除镜像后磁盘空间并不会立即释放。删除操作只是移除了镜像在 Harbor 数据库中的元数据tag 引用而实际存储在 registry 存储后端如/data卷中的 blob配置层、镜像层、manifest仍然占用空间。垃圾回收Garbage CollectionHarbor 内部任务类型GARBAGE_COLLECTION见 src/jobservice/job/known_jobs.go就是用于扫描并清理这些无引用的数据块从而回收磁盘空间。因此验证 OVA 版 Harbor 的 GC 功能是否正常是部署后运维检查中的重要一环也是 5-03-OVA-garbage-collection.md 这一测试用例的核心目的确认 OVA 版 Harbor 能够通过垃圾回收释放已删除镜像占用的空间。环境准备在执行本验证流程前需要准备以下环境缺一不可一个 Harbor 的 OVA 二进制文件用于在 vSphere 中部署 Harbor 虚拟机vCenter 环境至少包含一台 ESX 主机且网络支持 DHCPOVA 默认通过 DHCP 获取 IP一台装有 Docker CLI 的 Linux 主机作为 Docker 客户端用于docker login和docker push。注意GC 验证会涉及对 Harbor VM 的电源操作关机、开机和 vSphere 控制台操作请确保具备 vCenter 的相应权限并在非生产或测试环境中执行。完整验证流程验证的整体思路是先部署一个未开启 GC的 Harbor推送一批镜像并删除记录/data卷的磁盘占用然后修改 OVA 虚拟机设置开启 GC重启虚拟机触发一次 GC再次检查/data卷占用是否下降并核对 GC 日志有无报错最后再重复一轮推送、删除与重启确认 GC 在第二次重启后依然有效。第一步部署未开启 GC 的 Harbor OVA在 vCenter 中部署 Harbor OVA 虚拟机部署过程中将 Garbage Collection 选项设置为false即初始不启用垃圾回收。这一步是后续对比的关键只有在 GC 关闭的状态下删除镜像后空间不会被回收才能通过重启开启 GC 来验证回收效果。第二步创建项目并推送镜像在 Harbor 的 Web UI 中创建一个项目Project。在 Docker 客户端主机上使用管理员账号登录 Harbordocker login harbor_host按提示输入 admin 用户名与密码。向刚创建的项目推送若干镜像docker tag image:tag harbor_host/project/image:tag docker push harbor_host/project/image:tag镜像总大小建议至少 500MB。只有保证足够的镜像体积GC 前后通过df -h看到的磁盘占用差异才会明显、可判定。第三步删除镜像并记录磁盘占用在 Harbor 的 Web UI 中删除第二步推送的镜像此时 GC 未开启存储中的数据块不会被清理。在 vSphere 中打开 Harbor 虚拟机的控制台以 root 用户登录执行df -h /data记录输出中的Used已使用空间数值。这是 GC 执行前的基线数据。第四步关机并开启 GC 选项关闭 Harbor 虚拟机Power off。右键点击虚拟机选择 Edit Settings编辑设置。将 Garbage Collection 选项设置为true。重新开机Power on。这是 OVA 版 Harbor 触发 GC 的方式通过虚拟机配置选项在启动时执行一次垃圾回收。因此每次希望执行 GC 时都需要在关机状态下修改该项并重启这也是本用例第 15 步要验证第二次重启后 GC 依然有效的原因。第五步等待服务就绪并核对空间虚拟机开机后等待一段时间直到通过浏览器可以访问 Harbor 服务确认服务已就绪。再次通过 vSphere 控制台以 root 登录虚拟机执行df -h /data将此时/data卷的 Used 数值与第三步记录的值进行对比。第六步检查 GC 日志查看/data目录下垃圾回收的日志文件确认执行过程中没有错误# 以 root 身份在 Harbor VM 控制台执行 ls -lt /data | head # 根据日志文件时间与内容检查是否有 error预期 GC 日志中应无 error 级别的错误。第七步重复验证第二次 GC重复第三步至第四步前半段在 UI 中删除若干新推送的镜像保证有新产生的待回收数据再次执行关机、Edit Settings 确认 Garbage Collection 仍为 true、开机。重复第五、六步的检查确认 GC 在第二次重启后依然能够正常工作并释放空间。提示也可以顺带练习关闭 GC 后再验证用于对比 GC 关闭状态下删除镜像后df -h /data的 Used 值基本不变。预期结果完成上述流程后应满足以下预期第五步中/data卷的Used 空间应显著下降即被删除镜像的空间被回收第六步中GC 日志文件不应包含任何错误第七步中第二次重启触发的 GC 依然有效空间再次被正确回收。深入GC 在源码中是如何工作的上述验证流程之所以能释放空间背后是 Harbor 的垃圾回收任务机制。理解这一点有助于判断日志输出、参数行为以及排查回收不彻底等问题。GC 的执行入口与任务调度Harbor 将 GC 实现为一个 JobService 任务任务类型名为GARBAGE_COLLECTION定义于 src/jobservice/job/known_jobs.go。GC 控制器src/controller/gc/controller.go提供了完整的管理接口Start手动启动一次 GC 任务会创建 Execution 与 Task并携带delete_untagged、delete_tag、dry_run、workers、redis_url_reg、time_window等参数见 controller.goStop停止正在运行的 GC 任务GetSchedule/CreateSchedule/DeleteSchedule查看、创建按 cron 定时与删除 GC 调度计划。OVA 版在开机时触发 GC本质上就是系统启动阶段发起一次 GC 执行而标准部署中则可以通过 UI 的垃圾回收页面手动触发或按 cron 计划定时触发。GC 任务的核心执行逻辑mark 与 sweep 两阶段GC 的实际执行逻辑在 src/jobservice/job/impl/gc/garbage_collection.go 的GarbageCollector.Run中见 garbage_collection.go分为两个阶段mark标记阶段找出所有无引用的候选数据块。包括从 Harbor 数据库中删除过的 artifact记录在 artifact trash 中对应的 manifest 与 blob未被任何 manifest 引用的 untagged blobdelete_untagged开启时还会先把未打标签的 artifact 移入 trash通过blobMgr.UselessBlobs查询出的无引用 blob。mark 阶段只会把候选 blob 的状态标记为StatusDelete并不会真正删除数据同时会统计可释放空间的粗略估计值并写入执行结果。sweep清扫阶段真正执行删除。对于 manifest会先通过 registry v2 API 删除 tag/revision再调用 registry controller 的DeleteManifest删除存储中的 manifest并同步清理数据库中的关联记录对于普通 blobconfig、layer调用registryCtlClient.DeleteBlob删除存储中的数据并删除数据库记录。删除完成后GC 会把实际释放的空间freed_space、清理的 blob 数purged_blobs和 manifest 数purged_manifests通过Checkin写回执行结果见 garbage_collection.go。此外sweep 完成后还会清理 registry 的 Redis 缓存键blobs::*、repository::*这是为了解决 registry 的已知缓存问题保证后续拉取行为正确见 garbage_collection.go。关键参数及其对验证结果的影响GC 任务的参数解析见parseParamsgarbage_collection.go理解这些参数有助于解释为什么有的镜像删了空间却回收不掉参数默认值说明delete_untaggedtrue是否删除未打标签untagged的 artifact。开启时GC 会把没有 tag 的 artifact 移入 trash 并最终清理其数据delete_tagtrue是否在删除 manifest 时同步删除其在 registry 后端存储中的 tag 记录通过 v2 DELETE manifest APIdry_runfalse是否只做演练。开启时仅标记候选并统计可释放空间不实际删除任何数据time_window2小时时间窗口。只有在该时间窗口之前创建/更新的候选数据才会被纳入清理避免误删刚上传的数据测试调试时可设为 0workers1删除 blob 的并发工作线程数是 sweep 阶段的并行度参数redis_url_reg无registry 使用的 Redis 地址用于 sweep 后的缓存清理例如若镜像删除后空间未立即回收常见原因可能包括GC 尚未运行、time_window内保护、数据仍被 tag 引用或处于 dry run 模式。在 OVA 验证流程中只有删除镜像 → 重启触发 GC两个动作都完成后/data的 Used 值才会下降。常见问题排查GC 后空间未下降确认 GC 选项确实已设为 true 并完成了一次重启确认日志中无报错确认删除的镜像在数据库中已无 tag 引用未打标签的镜像需要delete_untagged生效。GC 日志位置OVA 版 Harbor 的 GC 日志位于/data目录下通过 vSphere 控制台 root 登录即可查看。只删 tag 不删数据Harbor 中删除镜像的 tag 只是解除引用blob 仍被保留等待下一次 GC 的 mark 阶段将其识别为无引用数据并清理这是正常的延迟释放设计。小结本文以 OVA 版 Harbor 的 GC 验证为主线给出了从环境准备、推送/删除镜像、开机触发 GC、df -h /data对比到日志核查的完整可复现流程并深入源码说明了 GC 的 mark/sweep 两阶段原理与关键参数。按此流程执行即可确认 OVA 版 Harbor 的垃圾回收功能正常确保删除镜像后存储空间能被有效回收。完整的原始测试用例定义见 5-03-OVA-garbage-collection.md相关实现可继续阅读 src/controller/gc/controller.go 与 src/jobservice/job/impl/gc/garbage_collection.go。【免费下载链接】harborAn open source trusted cloud native registry project that stores, signs, and scans content.项目地址: https://gitcode.com/GitHub_Trending/ha/harbor创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考