前言
Tensorflow作为深度学习领域逐渐成熟的项目，以其支持多种开发语言，支持多种异构平台，提供强大的算法模型，被越来越多的开发者使用。但在使用的过程中，尤其是GPU集群的时候，我们或多或少将面临以下问题：
- 资源隔离。Tensorflow（以下简称tf）中并没有租户的概念，何如在集群中建立租户的概念，做到资源的有效隔离成为比较重要的问题；
- 缺乏GPU调度。tf通过指定GPU的编号来实现GPU的调度，这样容易造成集群的GPU负载不均衡；
- 进程遗留问题。tf的分布式模式ps服务器会出现tf进程遗留问题；
- 训练的数据分发以及训练模型保存，都需要人工介入；
- 训练日志保存、查看不方便；
因此，我们需要一个集群调度和管理系统，可以解决GPU调度、资源隔离、统一的作业管理和跟踪等问题。
目前，社区中有多种开源项目可以解决类似的问题，比如yarn，kubernetes。yarn是hadoop生态中的资源管理系统，而kubernetes（以下简称k8s）作为Google开源的容器集群管理系统，在tf1.6版本加入GPU管理后，已经成为很好的tf任务的统一调度和管理系统。
下文是我们公司在tensorflow on kubernetes方面的实践经验。
设计目标
我们将tensorflow引入k8s，可以利用其本身的机制解决资源隔离，GPU调度以及进程遗留的问题。除此之外，我们还需要面临下面问题的挑战：
- 支持单机和分布式的tensorflow任务；
- 分布式的tf程序不再需要手动配置clusterspec信息，只需要指定worker和ps的数目，能自动生成clusterspec信息；
- 训练数据、训练模型以及日志不会因为容器销毁而丢失，可以统一保存；
为了解决上面的问题，我们开发了tensorflow on kubernetes系统。
架构
tensorflow on kubernetes包含三个主要的部分，分别是client、task和autospec模块。client模块负责接收用户创建任务的请求，并将任务发送给task模块。task模块根据任务的类型（单机模式和分布式模式）来确定接下来的流程：
如果type选择的是single（单机模式），对应的是tf中的单机任务，则按照按照用户提交的配额来启动container并完成最终的任务；
如果type选择的是distribute（分布式模式），对应的是tf的分布式任务，则按照分布式模式来执行任务。需要注意的是，在分布式模式中会涉及到生成clusterspec信息，autospec模块负责自动生成clusterspec信息，减少人工干预。
下面是tensorflow on kubernetes的架构图：
接下来将对三个模块进行重点介绍。
client模块
tshell
在容器中执行任务的时候，我们可以通过三种方式获取执行任务的代码和训练需要的数据：
- 将代码和数据做成新的镜像；
- 将代码和数据通过卷的形式挂载到容器中；
- 从存储系统中获取代码和数据；
前两种方式不太适合用户经常修改代码的场景，最后一种场景可以解决修改代码的问题，但是它也有下拉代码和数据需要时间的缺点。综合考虑后，我们采取第三种方式。
我们做了一个tshell客户端，方便用户将代码和程序进行打包和上传。比如给自己的任务起名字叫cifar10-multigpu，将代码打包放到code下面，将训练数据放到data下面。
最后打包成cifar10-multigpu.tar.gz并上传到s3后，就可以提交任务。
提交任务
在提交任务的时候，需要指定提前预估一下执行任务需要的配额：cpu核数、内存大小以及gpu个数（默认不提供），当然也可以按照我们提供的初始配额来调度任务。
比如，按照下面格式来将配额信息、s3地址信息以及执行模式填好后，执行send_task.py我们就可以提交一次任务。
task模块
单机模式
对于单机模式，task模块的任务比较简单，直接调用python的client接口启动container。container里面主要做了两件事情，initcontainer负责从s3中下载事先上传好的文件，container负责启动tf任务，最后将日志和模型文件上传到s3里，完成一次tf单机任务。
分布式模式
对于分布式模式，情况要稍微复杂些。下面先简单介绍一下tensforlow分布式框架。tensorflow的分布式并行基于gRPC框架，client负责建立Session，将计算图的任务下发到TF cluster上。
TF cluster通过tf.train.ClusterSpec函数建立一个cluster，每个cluster包含若干个job。 job由好多个task组成，task分为两种，一种是PS（Parameter server），即参数服务器，用来保存共享的参数，还有一种是worker，负责计算任务。
我们在执行分布式任务的时候，需要指定clusterspec信息，如下面的任务，执行该任务需要一个ps和两个worker，我们先需要手动配置ps和worker，才能开始任务。这样必然会带来麻烦。如何解决clusterspec，成为了一个必须要解决的问题。
所以在提交分布式任务的时候，task需要autospec模块的帮助，收集container的ip后，才能真正启动任务。所以分布式模式要做两件事情：
- 按照yaml文件启动container；
- 通知am模块收集此次任务container的信息后生成clusterspec；
Autospec模块
tf分布式模式的node按照角色分为ps（负责收集参数信息）和worker，ps负责收集参数信息，worker执行任务，并定期将参数发送给worker。
要执行分布式任务，涉及到生成clusterspec信息，模型的情况下，clusterspec信息是通过手动配置，这种方式比较麻烦，而且不能实现自动化，我们引入autospec模型很好的解决此类问题。
Autospec模块只有一个用途，就是在执行分布式任务时，从container中收集ip和port信息后，生成clusterspec，发送给相应的container。下面是autospec模块的工作流程图：
Container设计
tf任务比较符合k8s中kind为job的任务，每次执行完成以后这个容器会被销毁。我们利用了此特征，将container都设置为job类型。
k8s中设计了一种hook：poststart负责在容器启动之前做一些初始化的工作，而prestop负责在容器销毁之前做一些备份之类的工作。
我们利用了此特点，在poststart做一些数据获取的工作，而在prestop阶段负责将训练产生的模型和日志进行保存。我们接下来分单机和分布式两种模式来说明Container的设计思想。
总结
至此，我们已经介绍了tensorflow on kubernetes的主要流程。还有许多需要完善的地方，比如：web端提交任务以及查看运行状况和作业的日志；支持GPU的亲和性等等，总之，这只是我们前期的探索，后面还有许多东西需要完善。
本文转自中文社区-如何在Kubernetes上玩转TensorFlow ？
