您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 Code iProcess 课程 认证 咨询 工具 火云堂 讲座吧   成长之路  
会员   
 
   
 
  
每天15篇文章
不仅获得谋生技能
更可以追随信仰
 
     
   
 订阅
  捐助
vivo基于Kubernetes构建企业级TaaS平台实践
 
112 次浏览     评价:  
 2018-12-10
 
编辑推荐:
本文来自于CSDN,本文主要介绍当前 vivo TaaS 平台以及 TaaS架构和TensorBoard服务等。

vivo TaaS架构

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

下面是当前我们的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-autoscale源 码分析及如何解决 KubeDNS 性能瓶颈[2]》。

当然更好的解决办法其实是应该是对 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 训练的调度优化;

调度时考虑服务器的网络 IO 资源;

训练数据和模型的管理;

为 TensorFlow Serving 提供自动化LB配置;

基于 GPU 的调度和训练;

集群资源使用情况的动态监控,并对新的 TensorFlow 集群创建请求做更有意义的资源检查;

如果需要,使用 Glusterfs 提高训练数据的 Read IO;

......(事情总是做不完的)

总结

这里对 vivo TaaS 平台做了简单介绍,在这背后摸索的过程中我们解决了很多问题,但是未来的路很长,随着集群规模的快速膨胀,我们要做的工作会越来越多。TaaS 平台只是我们 Kubernetes 在 vivo 落地的一个方向,DevOps、ESaaS等平台的开发也面临很多挑战。

   
112 次浏览  评价: 差  订阅 捐助
相关文章

云计算的架构
对云计算服务模型
云计算核心技术剖析
了解云计算的漏洞
相关文档

云计算简介
云计算简介与云安全
下一代网络计算--云计算
软浅析云计算
相关课程

云计算原理与应用
云计算应用与开发
CMMI体系与实践
基于CMMI标准的软件质量保证
每天2个文档/视频
扫描微信二维码订阅
订阅技术月刊
获得每月300个技术资源
 
 

关于我们 | 联系我们 | 京ICP备10020922号 京公海网安备110108001071号