镜像仓在容器云处于很基础但又重要的位置,如何保证其高可用和压力测试的方案?

1回答

OkabeOkabe  实习生 , 某有限公司
泊涯zhuhaiqiang赞同了此回答
如果镜像仓使用的是Harbor的话,可以参考Harbor HA。建一个psql集群,一个redis集群,剩下的无状态组件只需要负载均衡到多个副本就行了。而数据高可用则是需要分开讨论的话题了。 压测镜像仓是一个很有意思的话题,在这里我们主要需要考虑两个问题: 1. 镜像仓的压力主要来于拉...显示全部

如果镜像仓使用的是Harbor的话,可以参考Harbor HA
建一个psql集群,一个redis集群,剩下的无状态组件只需要负载均衡到多个副本就行了。而数据高可用则是需要分开讨论的话题了。

压测镜像仓是一个很有意思的话题,在这里我们主要需要考虑两个问题:

1. 镜像仓的压力主要来于拉取和上传镜像。由于docker镜像的分层结构,如果我们对于同一个镜像反复上传下载几百几千次,那么就会变成单纯的对镜像仓的api server进行压测。
为了避免这种情况,我们需要在每次进行push操作前,build大量内容相同但是layer id不一致的镜像来上传。而对于每次pull操作,则可以pull上一步中push的镜像,所以需要pull之前rmi之前 build 的镜像。
但是在docker中构建内容相同的镜像时,docker会从相同基础镜像的其他镜像中搜索一致的层(docker缓存机制),并将其id与内容复制到当前构建的镜像中。这样会导致构建出来的镜像都拥有完全一致的层。所以我们需要在build命令中加入--no-cache来避免使用构建缓存。由于docker的构建中生成的layer id其实是一个随机数而非checksum,所以只要用了 --no-cache 我们就可以不用担心相同的dockerfile会构建出 layer id 一致的镜像。

2. 测试机网络瓶颈。
这个只能是具体状况具体分析了。如果大量进行pull\push时网络遇到了瓶颈的话,那么测试结果也是完全不可信的。所以尽可能保证测试机或者测试集群的网卡能力比镜像仓的好就行了。

对于压测的细节,可以参考openstuck的测试方案

收起
 2019-12-04
浏览1949

提问者

Dongxin系统架构师, 某银行股份有限公司

容器云管理平台选型优先顺序调查

发表您的选型观点,参与即得50金币。

问题状态

  • 发布时间:2019-12-04
  • 关注会员:2 人
  • 问题浏览:3642
  • 最近回答:2019-12-04