记录Harbor
清理镜像垃圾时遇到的错误{"errors":[{"code":"NOT_FOUND","message":"{\"code\":10010,\"message\":\"object is not found\",\"details\":\"2cc49b89751876fa18acb008\"}"}]}
导致回收失败,不能正常清理,最终占用越来越多的磁盘空间的解决过程。
问题
通过监控工具发现服务器的磁盘利用率接近80%,导致部分Kubernetes
节点不能正常工作,需要清理出一部分磁盘空间。进一步分析后发现Harbor
整体占用了500多G的磁盘空间。
对Harbor
中相关项目下的多余镜像手动删除后,项目下的磁盘占用空间恢复正常。
但回到项目整体界面上去看时,其占用的总空间还是和之前的一样都为500多G。
根据之前的经验虽然镜像被删除了,但还存在大量的垃圾导致占用了巨量的存储空间,此时需要对其进行垃圾清理,在系统管理
->清理任务
中点击立即清理垃圾
后经过几个小时后去查看结果时,类似如下,一直提示垃圾清理失败!
一开始自己以为是要清理的镜像垃圾太多导致需要的时间也更多,但自己等了两三天还是清理失败,这肯定不正常!
点击某条具体的执行记录,查看其日志,显示如下,并没有啥有价值的信息
解决
根据前述报错信息去Google查找,发现在GitHub
上这个问题很普遍
基于这条回复、这条回复以及这篇文章上说的是需要将registry
数据库下的admin_job
表的deleted
字段从false修改为true,当前使用的Harbor
版本为v2.10.3
基于docker
部署,进入名为harbor-db
的容器后发现由于自己的Harbor
版本相对于别人反馈的版本更新,该表并不存在!
对blob
表查询其总数,结果如下,虽然总数很多,但并没有提供啥有用的信息
继续查看对应的搜索结果,在这条回复中找到一条相关度很高的说明
Was this job executed 24 hours ago, the job service reaper all the execution and task exceed 24 hour and result in the not found error.
Please update the configuration and restart Harbor. use the file logger for job service and change the max_update_hours to 168
该段回复的主要意思是清理垃圾的时间太长超过了24小时,任务中心将该任务进行了强行终止与回收,进而导致非正常的查询失败错误。
而我之前也是等待了两三天也没清理成功,于是按照其说明修改$PWD/common/config/jobservice/config.yml
,将对应时间从24 修改为168 ,之后重启Harbor
服务。
yaml
jobLoggers:
- file
...
reaper:
max_update_hours: 168
max_dangling_hours: 168
基于Docker
重启Harbor
服务之后,我又等待了两三天,结果依旧和以前一样!
随着日常开发任务的迭代,Harbor
镜像仓库占用的磁盘空间也越来越大,该问题必须解决,没办法,我只能硬着头皮继续翻看GitHub
中关于这方面问题的相关检索结果。
最终在这条回复中找到Harbor
开发者的如下说明
Please go to the Job Service Dashboard and select the workers and you can find the job in the worker, and there is a log link, you can check when it is running
切换到自己的Harbor
对应界面后发现任务果然被挂起
选中GARBAGE_COLLECTION
类型的任务,将其重新启动,然后切换到工作者(Worker)
tab页下,可发现其下有任务正在执行。
点击对应的链接,可查看该任务执行者的详细信息,类似如下,从中可发现此时已经开始正常清理镜像垃圾!
在Harbor
界面查看相关任务执行结果,发现其状态均变为SUCCESS
点击其中某一条任务查看详细日志,结果如下,此时可发现令人讨厌的not found
错误已经消失!
在Harbor
主界面查看最关键的磁盘空间占用,已经减少到不到200G,符合预期,问题解决!