vivo基于Kubernetes构建企业级TaaS平台实践

Author: xidianwangtao@gmail.com

vivo TaaS架构

关于如何将Kubernetes和TensorFlow整合起来的Topic，以及咱们的CaaS技术栈的介绍，请参考过往的两篇文章，在这里我再也不赘述。

• 浅尝TensorFlow on Kubernetes
• 如何落地TensorFlow on Kubernetes

下面是当前咱们的TaaS平台架构图：

想多说如下两点：

• 有的同窗问我，咱们是如何将HDFS的训练数据迁移到Glusterfs的，在这统一回复：目前基于HDFS做为后端分布式存储的TaaS能知足算法团队的需求，因此最终咱们也没有作这个数据迁移工做。

• 因为这个方案中，每一个TensorFlow训练都会对应一个Kubernetes NameSpace，每一个TensorFlow Task都会对应一个Headless Service，各个Task经过KubeDNS进行发现和域名解析。在咱们的环境中，当一个TensorFlow训练的Task数超过600时，偶尔会出现Headless Service Name域名解析失败的状况，致使分布式TensorFlow集群内部的Session链接创建失败，最终没法成功启动此次Between-Graph训练。咱们经过Kubernetes的孵化项目cluster-proportional-autoscaler来根据集群Node数量对KubeDNS副本数进行弹性伸缩来解决这一问题的。下面是咱们使用的kube-dns-autoscaler配置：

  kind: ConfigMap
  	apiVersion: v1
  	metadata:
  	  name: kube-dns-autoscaler
  	  namespace: kube-system
  	data:
  	  linear: |
  	    {
  	    "nodesPerReplica": 10,
  	    "min": 1,
  	    "max": 50,
  	    "preventSinglePointFailure": true
  	    }

  关于这个问题的深刻探讨，请参考个人博文cluster-proportional-autoscaler源码分析及如何解决KubeDNS性能瓶颈。固然更好的解决办法实际上是应该是对cluster-proportional-autoscaler进行二次开发，根据集群中Service Number来对KubeDNS进行弹性伸缩。由于在咱们AI的场景下，一台高配的服务器能运行的Pods数能够多达80个，正常状况不会超过30个，这么大的弹性范围，无疑使用Service Number来对KubeDNS进行弹性伸缩是最好的选择。

vivo TaaS介绍

咱们TaaS平台目前支持训练脚本的托管、训练项目的建立和管理、TensorBoard服务的一键建立能力，虽然支持一键建立TensorFlow Serving服务帮助模型上线，可是由于还没作TensorFlow Serving的Load Balance，因此这个特性还没正式上线，目前正在开发中，之后有机会再跟你们分享。

算法托管

用户登陆TaaS Portal, 上传本地的算法脚本到TaaS平台, 提供一系列算法脚本管理的能力，这个没多少可说的。

每一个算法，咱们约定使用run.sh文件启动训练。

训练项目

接下来，用户根据算法脚本的路径建立对应的训练项目。

训练项目分两种类型：普通训练和定时训练。定时训练顾名思义，就是经过定时器控制训练实例，每隔必定周期启动一次训练，而且支持启动下一次训练前是否强行杀死上一次的训练。还能够设置该次训练最长容许的时长，超时强行杀死本次训练。

建立完项目后，接下来就是启动训练了，填入worker数和ps数，选择对应的resource.requests，提交训练请求。

而后请求转到Kubernetes中，建立对应的Namespace, workers job, ps deployment及其对应的Headless Services，imagePullSecret等Object，TaaS生成对应的训练记录。

每一个训练记录都对应一个Kubernetes Namespace,能够查看训练详情、各个task的日志和对应的Grafana监控面板。

TensorBoard服务

TensorBoard经过加载log目录下的summary data，为模型和训练提供了web视图，能够帮助算法工程师定位算法的瓶颈。vivo TaaS平台支持一键建立TensorBoard服务。

请求会转到Kubernetes建立对应的TensorBoard Deployment等Object，TaaS页面提供该TensorBoard服务的访问入口。

点击“模型展现”，便可跳转到对应的TensorBoard Web视图。

vivo TaaS后续规划

目前咱们的TaaS平台仍然处于早期阶段，还有不少工做须要去作：

• 基于任务优先级进行线上线下混合部署、资源抢占式调度；
• 训练和TensorFlow Serving物理资源资源共享并进行资源池管理；
• 为训练添加自定义命令行参数；
• 大规模TensorFlow训练的调度优化；
• 调度时考虑服务器的网络IO资源；
• 训练数据和模型的管理；
• 基于LVS为TensorFlow Serving提供自动化LB配置；
• 基于gpu的调度和训练；
• 集群资源使用状况的动态监控，并对新的TensorFlow集群建立请求作更有意义的资源检查；
• 若是须要，使用Glusterfs提升训练数据的Read IO；
• ...(事情老是作不完的)

总结

这里对vivo TaaS平台作了简单介绍，在这背后摸索的过程当中咱们解决了不少问题，可是将来的路很长，随着集群规模的快速膨胀，咱们要作的工做会愈来愈多。TaaS平台只是咱们Kubernetes在vivo落地的一个方向，DevOps、ESaaS等平台的开发也面临不少挑战，若是你也有志于深耕容器云相关技术，欢迎加入咱们团队。

广告：更多干货欢迎微信关注“vivo互联网技术”公众号