vivo基於Kubernetes構建企業級TaaS平臺實踐

Author: xidianwangtao@gmail.com

vivo TaaS架構

關於如何將Kubernetes和TensorFlow整合起來的Topic，以及咱們的CaaS技術棧的介紹，請參考過往的兩篇文章，在這裏我再也不贅述。

• 淺嘗TensorFlow on Kubernetes
• 如何落地TensorFlow on Kubernetes

下面是當前咱們的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-autoscaler源碼分析及如何解決KubeDNS性能瓶頸。固然更好的解決辦法實際上是應該是對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 Serving物理資源資源共享並進行資源池管理；
• 爲訓練添加自定義命令行參數；
• 大規模TensorFlow訓練的調度優化；
• 調度時考慮服務器的網絡IO資源；
• 訓練數據和模型的管理；
• 基於LVS爲TensorFlow Serving提供自動化LB配置；
• 基於gpu的調度和訓練；
• 集羣資源使用狀況的動態監控，並對新的TensorFlow集羣建立請求作更有意義的資源檢查；
• 若是須要，使用Glusterfs提升訓練數據的Read IO；
• ...(事情老是作不完的)

總結

這裏對vivo TaaS平臺作了簡單介紹，在這背後摸索的過程當中咱們解決了不少問題，可是將來的路很長，隨着集羣規模的快速膨脹，咱們要作的工做會愈來愈多。TaaS平臺只是咱們Kubernetes在vivo落地的一個方向，DevOps、ESaaS等平臺的開發也面臨不少挑戰，若是你也有志於深耕容器雲相關技術，歡迎加入咱們團隊。

廣告：更多幹貨歡迎微信關注「vivo互聯網技術」公衆號