K8s的出现为PaaS行业的发展打了一针兴奋剂，Docker+k8s的技术路线已经成为了容器云的主流。尤其针对大流量，大弹性的应用场景来说，k8s将其从繁杂的运维、部署工作中彻底拯救出来。

然而事情往往没有那么简单而美好，当我们使用k8s去管理一些大规模集群的时候，我们会发现有很多问题等待我们解决。比如，当集群中的所有节点同时去镜像仓库拉取镜像的时候，这种大规模并发很有可能阻塞仓库的出口，导致大家的下载速度都慢得难以忍受，这就是k8s镜像分发的阿喀琉斯之踵。我们当然可以采取镜像仓库集群化的方法来缓解这个瓶颈，然而这种做法始终是治标不治本，此外还会造成维护成本升高，以及镜像同步时效性差等问题。

那么如何解决这个让人困扰的问题呢？

p2p看起来是一个好办法，去中心化的做法，不但可以降低对仓库节点的依赖，同时也可以为用户节省宝贵的外网流量。但是在k8s集群中拉取镜像的场景内使用p2p技术要面对一系列困难，包括节点间数据安全性的问题、无预热前提下的大规模并发拉取、非侵入式将集群改造成p2p网络等。

在华为云容器镜像服务中我们是这样做的：

如上图所示，我们改变了所有集群节点去镜像仓库拉取镜像的传统做法。在用户节点中注入peer客户端，使用peer客户端截取docker client的拉取镜像请求，并将请求重定向。经过修改后只有部分节点（约10%）真正到达镜像仓库去获取镜像数据，剩余节点转为自集群内的其它节点获取镜像。

要实现这个方案，主要的开发点有三处：需要对镜像仓库进行改造，部署并改造新的tracker服务器，以及在用户节点注入peer客户端。

对镜像仓库的改造

要想实现集群的p2p下载功能，所下载的文件必须包含有种子，因此要对已有的镜像仓库进行改造。当用户push镜像到镜像仓库时，仓库自动计算镜像所有layer的SHA值，并为每一个layer生成一个种子文件。

为了保证集群的安全性验证，仓库为每个接入的peer下发由仓库私钥签名的jwt token，这个token将会进入集群网络，并保证集群节点的认证安全。

部署改良后的tracker服务器

传统的Tracker服务器的主要功能是为所有peer客户端提供peer列表。针对k8s集群场景，我们所搭建的Tracker服务器除了负责分发peer列表外，还增加了许多其它特性。

1.判断peer节点的集群归属，因为tracker服务器可能对多个集群进行服务，而每个集群中的节点网络相对独立，因此tracker负责记录peer节点的集群归属信息很有必要，这样可以避免分发出网络不互通的peer列表。

2.Tracker服务器负责监控每个peer的状态，自动将部分下载完成的peer节点资源释放，因为集群节点属于客户资源，一旦完成任务应该尽快将资源释放出去。当Tracker判断当前集群中完成节点比例已足够支撑下载时，会指示部分已完结节点终结任务释放资源，并将其移除出任务列表。当所有peer节点均已完成下载，而且一段时间内没有新的下载请求进入，那么Tracker会指示将全部集群节点资源释放。

3.Tracker按比例（约10%）指定部分peer节点到镜像仓库下载，以此将数据带入整个集群网络。

4.Tracker提供peer节点的安全性验证，保证同属于一个集群并下载同一个资源的peer节点有获取peer列表的权限。

容器化的peer客户端

在这个解决方案中，我们创造性的将peer客户端容器化，并通过华为云容器引擎（CCE）的插件功能，将peer容器分发给整个集群。peer容器可以通过修改docker客户端代理的方式，拦截下载镜像请求的相关接口，将从镜像仓库下载操作转化为p2p网络下载操作，并把获取到的镜像数据归还给docker客户端，以此快速的把镜像数据分发到整个集群网络。

该peer客户端还具有以下特性：

•根据tracker的分配，修改下载地址，小部分从镜像仓库下载，大部分从集群网络中下载。

•在peer客户端的tcp握手协议中注入jwt token安全校验，保证节点数据安全，防止假冒节点盗取数据。

•Peer客户端采用优先级下载方式，能够保证在下载过程中就可以将数据传输给docker客户端，而不是当数据全部下载完全后再传输给docker，以此最大限度的节省下载实际。

经过p2p方案改造后的k8s集群，下载速度得到了极大的提升，使用p2p网络的k8s集群比不使用的集群下载速率提升非常明显。我们的测试数据显示在200节点规模的集群中，并发下载3GB镜像的总耗时，由以前的3分35秒降低到1分29秒。可见这个方案是能够解决k8s镜像分发的瓶颈问题。