Harbor GC 流程分析
最近我们构建环境的 Harbor GC 经常出故障,借排查问题的机会,梳理了 Harbor GC 的流程,这个文档是基于官方的 2.2.3 源码分析的,GC 大概分为这两部分:
- API 创建任务,并通知 job service,这部分是在 core 组件中完成的。
- job service 处理任务,并给 core 组件同步任务状态,这部分是在 job service 组件中完成的。
两个组件通过 HTTP 请求的方式交互。
Core 处理 API 请求
至此,创建任务的部分已结束。
Job Service 处理任务
Job Service 处理任务的逻辑又可以再细分为几个步骤:
- 初始化 Worker 来处理任务
- API 接收 core 的请求,把任务保存用于后续处理
- 任务分发,从 Redis 中获取任务所需要的参数,并交给 Worker 来处理
- 状态变更,任务的每个阶段都会有状态的变更
这部分代码量比较大,截图时有可能会只截取重要的部分。
Worker 初始化
处理 API 请求
任务分发
job 出栈之前还会判断当前正在处理的 job 数量,只有小于最大并发数,才能取出数据,其中用到的四个 redis key 分别是
{namespace}:jobs:GARBAGE_COLLECTION
job 队列,前面提到的 api 请求就是把 job 保存到这里了{namespace}:jobs:GARBAGE_COLLECTION:{woker pool id}:inprogress
worker 正在处理的 job,这个 woker id 是 worker 启动生成的随机字符串,在另一个 redis key 里保存的。{namespace}:jobs:GARBAGE_COLLECTION:lock
当前正在处理的 job 数量{namespace}:jobs:GARBAGE_COLLECTION:max_concurrency
最大并发数
状态更新
redisJob.Run 里面用 tracker 对 job 数据做了一次封装,主要是用来更新 job 状态,这部分就不展开讲了。
Todo
- Garbage Collector 逻辑
- job 重试逻辑
- 通知 core 组件