在模型構建、訓練、調整、測試後我們對自己的模型部署成服務時候，我們需要穩定訪問避免死鎖，
本文是使用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目前不支援生命週期管理，結束的訓練程序並不會自動關閉，這也需要進行額外的處理。