容器相比虚拟机最突出的特点之一便是轻量化和快速启动。相比虚拟机动辄十几个 G 的镜像，容器镜像只包含应用以及应用所需的依赖库，所以可以做到几百 M 甚至更少。但即便如此，几十秒的镜像拉取还是在所难免，如果镜像更大，则耗费时间更长。
我们团队（阿里云弹性容器 ECI）分析了 3000 个不同业务 Pod 的启动时间，具体如下图。可以看出，在 Pod 启动过程中，镜像拉取部分耗时最长。大部分 Pod 需要 30s 才能将镜像拉下来，这极大增加了容器的启动时间。
如果是大规模启动，这个问题则会变得更糟糕。镜像仓库会因为镜像并发拉取导致带宽打满或者服务端压力过大而直接崩溃。
我们多次遇到过这个问题。由于一个服务的副本数达到 1000+ ，在迅速扩容 1000+ 多个实例的时候，很多 Pod 都处于 Pending 状态，等待镜像拉取。
虽然 kubernetes 在调度的时候已经支持镜像的亲和性，但只针对老镜像，如果并发启动的新镜像的话，还是需要从镜像仓库里面拉取。下面提供几种常用的解决思路。
方法一：多镜像仓库
多镜像仓库能够很好降低单个仓库的压力，在并发拉取镜像的时候，可以通过域名解析负载均衡的方法，将镜像仓库地址映射到不同的镜像仓库，从而降低单个仓库的压力。
不过，这里有个技术挑战点：镜像仓库之间的镜像同步。
为了确保 Docker 客户端无论从哪个仓库都可以获取到最新的镜像，需要保证镜像已经成功复制到了每个镜像仓库。开源的镜像仓库 Harbor 已经支持镜像复制功能，可以帮助我们将镜像分发到不同的仓库中。
方法二：P2P 镜像分发
多镜像仓库虽然能够缓解单个仓库的压力，但仍然不能完全避免单个仓库被打爆的问题，而且多个仓库的运维成本也比较
