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

最新推荐文章于 2024-09-09 15:25:53 发布

Docker_

最新推荐文章于 2024-09-09 15:25:53 发布

阅读量2.5k

点赞数

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

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 平台，提供一系列算法脚本管理的能力，这个没多少可说的。