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

Posted 2021-04-16 分布式实验室

最近越来越多的同学找我讨论 “TensorFlow on Kubernetes” 的方案和实践，并且想了解自从上次分享《 》和《如何落地 TensorFlow on Kubernetes[1]》后，现在做成什么样了。这说明越来越多的企业开始基于 Kubernetes 和 TensorFlow 来构建自己的深度学习平台，我们非常愿意同大家交流和分享我们的实践。下面将主要介绍当前 vivo TaaS 平台的架构和功能。

vivo TaaS架构

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

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

想多说以下两点：

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

2. 由于这个方案中，每个 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等平台的开发也面临很多挑战。

相关链接：

1. https://my.oschina.net/jxcdwangtao/blog/1554472

2. https://my.oschina.net/jxcdwangtao/blog/1581879

本文转载自公众号： vivo互联网技术，ID：vivoVMIC， 。

基于Kubernetes的DevOps实践培训

点击阅读原文链接即可报名。