在模型构建、训练、调整、测试后我们对自己的模型部署成服务时候，我们需要稳定访问避免死锁，
本文是使用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目前不支持生命周期管理，结束的训练进程并不会自动关闭，这也需要进行额外的处理。