K8s的出现为PaaS行业的发展打了一针兴奋剂，Docker+k8s的技术路线已经成为了容器云的主流。尤其针对大流量，大弹性的应用场景来说，k8s将其从繁杂的运维、部署工作中彻底拯救出来。然而事情往往没有那么简单而美好，当我们使用k8s去管理一些大规模集群的时候，我们会发现有很多问题等待我们解决。比如，当集群中的所有节点同时去镜像仓库拉取镜像的时候，这种大规模并发很有可能阻塞仓库的出口，导致大家的下载速度都慢得难以忍受，这就是k8s镜像分发的阿喀琉斯之踵。我们当然可以采取镜像仓库集群化的方法来缓解这个瓶颈，然而这种做法始终是治标不治本，此外还会造成维护成本升高，以及镜像同步时效性差等问题。

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

p2p看起来是一个好办法，去中心化的做法，不但可以降低对仓库节点的依赖，同时也可以为用户节省宝贵的外网流量。但是在k8s集群中拉取镜像的场景内使用p2p技术要面对一系列困难，包括节点间数据安全性的问题、无预热前提下的大规模并发拉取、非侵入式将集群改造成p2p网络等。经过不断的探索与实验，我们--华为云容器镜像服务，终于摸索出了一套在k8s集群中完美整合p2p下载的方案。该方案的提出有效的解决了我们遇到的实际问题，提高了镜像下载速度，并为客户节省了大量带宽资源。

p2p改造后的集群下载测试结果



我们是如何把p2p下载整合到k8s集群内的呢？
在华为云容器镜像服务中我们是这样做的，我们改变了所有集群节点去镜像仓库拉取镜像的传统做法。在用户节点中注入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集群，下载速度得到了提升的同时，也为客户节约了大量带宽。当前这个特性已经在菊厂云上开放给用户使用，感兴趣的同学们快来体验吧。

本文转自DockOne-p2p-如何拯救k8s镜像分发的阿喀琉斯之踵