K8s的出现为PaaS行业的发展打了一针兴奋剂,Docker+k8s的技术路线已经成为了容器云的主流。尤其针对大流量,大弹性的应用场景来说,k8s将其从繁杂的运维、部署工作中彻底拯救出来。然而事情往往没有那么简单而美好,当我们使用k8s去管理一些大规模集群的时候,我们会发现有很多问题等待我们解决。比如,当集群中的所有节点同时去镜像仓库拉取镜像的时候,这种大规模并发很有可能阻塞仓库的出口,导致大家的下载速度都慢得难以忍受,这就是k8s镜像分发的阿喀琉斯之踵。我们当然可以采取镜像仓库集群化的方法来缓解这个瓶颈,然而这种做法始终是治标不治本,此外还会造成维护成本升高,以及镜像同步时效性差等问题。
那么如何解决这个让人困扰的问题呢?p2p看起来是一个好办法,去中心化的做法,不但可以降低对仓库节点的依赖,同时也可以为用户节省宝贵的外网流量。但是在k8s集群中拉取镜像的场景内使用p2p技术要面对一系列困难,包括节点间数据安全性的问题、无预热前提下的大规模并发拉取、非侵入式将集群改造成p2p网络等。经过不断的探索与实验,我们--华为云容器镜像服务,终于摸索出了一套在k8s集群中完美整合p2p下载的方案。该方案的提出有效的解决了我们遇到的实际问题,提高了镜像下载速度,并为客户节省了大量带宽资源。
p2p改造后的集群下载测试结果
如上图所示,我们限制了镜像仓库的下载带宽,并测试了200节点与500节点情况下,不同下载方式的状况。随着节点数量的增大,并发量触及到镜像仓库下载瓶颈的可能性也随之增大,然而使用了p2p下载方式改造的k8s集群并没有受到该瓶颈的制约,表现远强于传统下载方式。尤其是对于较大的镜像,差距更为明显。我们是如何把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列表外,还增加了许多其它特性。
- 判断peer节点的集群归属,因为tracker服务器可能对多个集群进行服务,而每个集群中的节点网络相对独立,因此tracker负责记录peer节点的集群归属信息很有必要,这样可以避免分发出网络不互通的peer列表。
- Tracker服务器负责监控每个peer的状态,自动将部分下载完成的peer节点资源释放,因为集群节点属于客户资源,一旦完成任务应该尽快将资源释放出去。当Tracker判断当前集群中完成节点比例已足够支撑下载时,会指示部分已完结节点终结任务释放资源,并将其移除出任务列表。当所有peer节点均已完成下载,而且一段时间内没有新的下载请求进入,那么Tracker会指示将全部集群节点资源释放。
- Tracker按比例(约10%)指定部分peer节点到镜像仓库下载,以此将数据带入整个集群网络。
- Tracker提供peer节点的安全性验证,保证同属于一个集群并下载同一个资源的peer节点有获取peer列表的权限。
- 根据tracker的分配,修改下载地址,小部分从镜像仓库下载,大部分从集群网络中下载。
- 在peer客户端的tcp握手协议中注入jwt token安全校验,保证节点数据安全,防止假冒节点盗取数据。
- Peer客户端采用优先级下载方式,能够保证在下载过程中就可以将数据传输给docker客户端,而不是当数据全部下载完全后再传输给docker,以此最大限度的节省下载实际。
华为云容器镜像服务p2p功能使用指导: