1. 搭建 Harbor 的要求
Harbor 硬件要求:
- CPU,最少 2 核,4 核更好
- Mem,最少 4 GB,8 GB 更好
- Disk,最少 40 GB,160 GB 更好
Docker 版本要求:
- 17.06.0 以上
在 Kubernetes 上搭建 Harbor ,可以参考文档,使用 Helm 搭建 harbor 。
2. Harbor 提供的功能
Harbor 是在 Docker Registry 的基础之上,进行了企业级扩展。Harbor 提供的功能包括:
- 基于角色的权限控制
- 基于策略的镜像复制
- 漏洞扫描
- LDAP 认证
- 镜像垃圾清理
- Notary 镜像签名
- 操作日志
- RESTful API
- Chart 包的管理
3. Harbor 集成的组件
3.1 Clair
Clair 是 CoreOS 开源的镜像漏洞扫描工具。
Clair 的原理是,首先对镜像进行特征的提取,再将这些特征匹配 CVE 漏洞库。Clair 是以静态的方式,按照镜像 layer 层级,进行扫描的。
3.2 Notray
在构建镜像时,通常会基于一些基础镜像,添加符合应用场景的镜像层,得到新的镜像。为了防止在构建过程中,非法植入恶意镜像层,便有了内容信任(Content Trust)机制,用以保证镜像层来源可信。
Notary 是一套镜像的签名工具, 用来保证镜像层在 pull、push、transfer 过程中的一致性和完整性。避免中间人攻击,阻止非法的镜像更新和运行。
镜像层的创建者可以对镜像层做数字签名,生成摘要,保存在 Notary 服务中。开启 Content Trust 机制之后,未签名的镜像无法被拉取。
通过设置环境变量,可以开启 Content Trust 机制:
export DOCKER_CONTENT_TRUST=1
export DOCKER_CONTENT_TRUST_SERVER=https://notary.harbor.chenshaowen.com
推、拉镜像时,要求镜像层有签名:
|
|
|
|
3.3 Docker Registry
Docker Registry 是 Docker 官方提供的镜像存储组件。
registry v2 拥有断点续传、镜像多层并发拉取等功能。
当 pull 一个镜像时,先进行认证,获取到 token 并授权通过,然后获取镜像的 manifest 文件,进行 signature 校验。校验完成之后,依据 manifest 包含的信息,拉取各层。拉取完成后,也需要先在本地进行校验。
当 push 一个镜像时,先将镜像各层并发推送至 registry ,推送完成后,再将镜像的 manifest 推至 registry。
在 registry 的存储目录下,能够找到两个文件夹:一个是 blobs,用于存储层级文件;另外一个是 repositories,以索引的方式保存了 registry 中镜像的元数据。
|
|
4. Kubernetes 中的 Harbor
上面是 Harbor 的架构图。下面根据 Kubernetes 中运行的 Pod 了解一下 Harbor 中的相关模块:
|
|
- chartmuseum, chart 存储,在挂载的 PV 中可以看到以文件目录形式存储的 chart 包。
- clair,用于镜像安全扫描
- core,核心功能控制
- database,用于存储 projects、users、roles、images 等元数据。
- jobservice,执行定时任务,提供 API 供外部提交任务及查询执行结果。
- notary-server、notary-signer,实现 Docker Content Trust ,镜像签名。
- portal,UI 页面入口
- redis,缓存
- registry,Docker 的原生 registry 组件
5. HA 方案
- 多主复制
通过一个 LB ,将请求导向多个 Harbor 实例上。这种方式不能保证数据的一致性,在生产环境常会遇到问题。
- 多实例,共享存储
同样是,通过一个 LB ,将请求导向多个 Harbor 实例。但是全部实例共享存储,只需要存储是高可用,那么整个 Harbor 集群也就高可用了。
6. Harbor 的一些问题
2022.07 新增
- 任务队列慢
使用 Harbor 进行主从复制时,Harbor 的任务执行非常慢。如上图,日常推送不到 2K,而任务堆积了 5.7K,根本无法作为生产的同步方案使用。
主从 Harbor 的直接同步是不可行的,如果借助第三方工具或可一试。
- Trivy 扫描不可用
我们采用的是 4C8GB 机器使用 docker compose 部署 Harbor。Harbor 有两种安全扫描自动触发方式:
- 上传镜像之后扫描。导致任务堆积,需要等十几个小时才能执行。
- 定时扫描。如上图,每次扫描时,内存不断增长,CPU 间歇性拉高,直至达到接近 98% 消耗,影响机器稳定性。而且,之前扫描过的镜像,第二次依然会扫描,无法控制资源消耗。
因此,建议采用外置的 Trivy 镜像安全扫描器,同时分散到多个实例进行扫描。
- 任务执行机制缺陷
在基于 Kubernetes 的一个 Harbor 实例上,增加 Job Service 的副本数量不能显著提升任务的执行速度。
同时,在页面上取消的任务并不能马上取消,而是需要删掉 Redis 中的数据。如果采用的是无状态的 Redis,可以重启 Redis 取消任务。