Kubernetes部署tensorflow模型

在模型建構、訓練、調整、測試後我們對自己的模型部署成服務時候，我們需要穩定通路避免死鎖，

本文是使用kubernetes部署tensorflow服務的一個流程

TensorFlow on Kubernetes

如我們上面所介紹的，在單機環境下是無法訓練大型的神經網絡的。在谷歌的内部，Google Brain以及TensorFlow都跑在谷歌内部的叢集管理系統Borg上。我在谷歌電商時，我們使用的商品分類算法就跑在1千多台伺服器上。在谷歌外，我們可以将TensorFlow跑在Kubernetes上。在介紹如何将TensorFlow跑在Kubernetes上之前，我們先來介紹一下如何并行化的訓練深度學習的模型。

深度學習模型常用的有兩種分布式訓練方式。一種是同步更新，另一種是異步更新。如上面的ppt所示，在同步更新模式下，所有伺服器都會統一讀取參數的取值，計算參數梯度，最後再統一更新。而在異步更新模式下，不同伺服器會自己讀取參數，計算梯度并更新參數，而不需要與其他伺服器同步。同步更新的最大問題在于，不同伺服器需要同步完成所有操作，于是快的伺服器需要等待慢的伺服器，資源使用率會相對低一些。而異步模式可能會使用陳舊的梯度更新參數導緻訓練的效果受到影響。不同的更新模式各有優缺點，很難統一的說哪一個更好，需要具體問題具體分析。

無論使用哪種更新方式，使用分布式TensorFlow訓練深度學習模型需要有兩種類型的伺服器，一種是參數伺服器，一種是計算伺服器。參數伺服器管理并儲存神經網絡參數的取值；計算伺服器負責計算參數的梯度。

在TensorFlow中啟動分布式深度學習模型訓練任務也有兩種模式。一種為In-graph replication。在這種模式下神經網絡的參數會都儲存在同一個TensorFlow計算圖中，隻有計算會配置設定到不同計算伺服器。另一種為Between-graph replication，這種模式下所有的計算伺服器也會建立參數，但參數會通過統一的方式配置設定到參數伺服器。因為In-graph replication處理海量資料的能力稍弱，是以Between-graph replication是一個更加常用的模式。

最後一個問題，我們剛剛提到TensorFlow是支援以分布式叢集的方式運作的，那麼為什麼還需要Kubernetes？如果我們将TensorFlow和Hadoop系統做一個簡單的類比就可以很清楚的解釋這個問題。大家都知道Hadoop系統主要可以分為Yarn、HDFS和mapreduce計算架構，那麼TensorFlow就相當于隻是Hadoop系統中Mapreduce計算架構的部分。

TensorFlow沒有類似Yarn的排程系統，也沒有類似HDFS的存儲系統。這就是Kubernetes需要解決的部分。Kubernetes可以提供任務排程、監控、失敗重新開機等功能。沒有這些功能，我們很難手工的去每一台機器上啟動TensorFlow伺服器并時時監控任務運作的狀态。除此之外，分布式TensorFlow目前不支援生命周期管理，結束的訓練程序并不會自動關閉，這也需要進行額外的處理。