内容简介：vivo TaaS架构关于如何将 Kubernetes 和 TensorFlow 整合起来的 Topic，以及我们的 CaaS 技术栈的介绍，请参考过往的两篇文章，在这里我不再赘述。下面是当前我们的TaaS平台架构图：
| 编辑推荐: |
| 本文来自于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等平台的开发也面临很多挑战。
以上就是本文的全部内容，希望本文的内容对大家的学习或者工作能带来一定的帮助，也希望大家多多支持 码农网
猜你喜欢:
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
Beginning Google Maps API 3
Gabriel Svennerberg / Apress / 2010-07-27 / $39.99
This book is about the next generation of the Google Maps API. It will provide the reader with the skills and knowledge necessary to incorporate Google Maps v3 on web pages in both desktop and mobile ......一起来看看 《Beginning Google Maps API 3》 这本书的介绍吧!
