vivo基於Kubernetes構建企業級TaaS平臺實踐-知識星球

最近越來越多的同學找我討論 “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 平臺，提供一系列演演算法指令碼管理的能力，這個沒多少可說的。