哈喽~大家好，Service的基本概念讲了一个大致的框架，不知道大家有没有看到，如果不懂，欢迎大家前来一起讨论哦。
现在我们开始接下来的内容。
Job
批处理任务通常并行（或串行）启动多个计算进程去处理一批工作项（work item）,在处理完成后，整个批处理任务结束。k8s支持批处理类型的应用，我们可以通过Kubernetes Job这种资源对象定义并启动一个批处理任务Job。与RC、Deployment、ReplicaSet、DaemonSet类似，Job也控制一组Pod容器。从这个角度来看，Job也是一种特殊的Pod副本自动控制器，同时Job控制Pod副本与RC等控制器的工作机制有以下重要差别。
（1）Job所控制的Pod副本是短暂运行的，可以将其视为一组Docker容器，其中的每个Docker容器都仅仅运行一次。当Job控制的所有Pod副本都运行结束时，对应的Job也就结束了。Job生存的Pod副本是不能自动重启的，对应Pod副本的RestartPoliy都被设置为Never。k8s1.5之后提供了类似crontab的定时任务——Cronjob，解决了某些批处理任务需要定时反复执行的问题。
（2）Job所控制的Pod副本的工作模式能够多实例并行计算，以TensorFlow框架为例，可以将一个机器学习的计算任务分布到10台机器上，在每台机器上都运行一个worker执行计算任务，这很适合通过Job生成10个Pod副本同时启动运算。
后面我们会继续深入讲解Job的实现原理及对应的案例。
Volume
Volume（存储卷）是Pod中能够被多个容器访问的共享目录。k8s中的Volume与Docker中的Volume概念、用途和目的都比较类似，但两者不能等价。k8s中的Volume被定义在Pod上，然后被一个Pod里的多个容器挂载到具体的文件目录下；k8s中的Volume与Pod的生命周期相同，但与容器的生命周期不相关，当容器终止或者重启时，Volume中的数据也不会丢失。k8s支持多种类型的Volume，如GlusterFS，Ceph等先进的分布式文件系统。
接下来为大家准备了一个实例。
我们要给之前的Tomcat Pod增加一个名为datavol的Volume，并且挂载到容器的/mydata-data目录上，则只要对Pod的定义文件做如下修正即可。
替换资源
2
3
2
3
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
2kind: ReplicationController
3metadata:
4 name: frontend
5spec:
6 replicas: 1
7 selector:
8 tier: frontend
9 template:
10 metadata:
11 labels: #可以自己定义key-value
12 app: app-demo
13 tier: frontend #前端架构
14 spec:
15 volumes:
16 - name: datavol
17 emptyDir: {}
18 containers:
19 - name: tomcat-damo
20 image: tomcat
21 volumeMounts:
22 - mountPath: /mydata-data
23 name: datavol
24 imagePullPolicy: IfNotPresent
25 ports:
26 - containerPort: 8080
27 env:
28 - name: GET_HOSTS_FROM
29 value: dns
30
31
验证是否挂载成功。
除了可以让一个Pod里的多个容器共享文件、让容器的数据写到宿主机的磁盘上或者写文件到网络存储中，Kubernetes的Volume还扩展出了一种非常有实用价值的功能，即容器配置文件集中化定义与管理，这是通过ConfigMap这种新的资源对象来实现的，后面会详细说明。
k8s提供看丰富的Volume类型，下面逐一进行说明。
1.emptyDir
一个emptyDir Volume是在Pod分配到Node是创建的，它的初始内容为空，并且无须指定宿主机上对应的目录文件。当Pod从Node上移除时，emptyDir中的数据也会被永久删除。emptyDir的一些用途如下。
◎ 临时空间，例如用于某些应用程序运行时所需的临时目录，且无须永久保留。
◎ 长时间任务的中间过程CheckPoint的临时保存目录。
◎ 一个容器需要从另一个容器中获取数据的目录（多容器共享目录）。
目前，用户无法控制emptyDir使用的介质种类。
2.hostPath
hostPath为在Pod上挂在宿主机上的文件或目录，它通常可以用于以下几方面。
◎ 容器应用程序生成的日志文件需要永久保存时，可以使用宿主机的高速文件系统进行存储。
◎ 需要访问宿主机上Docker引擎内部数据结构的容器应用时，可以通过定义hostPath为宿主机/var/lib/docker目录，使容器内部应用可以直接访问Docker的文件系统。
在使用这种类型的Volume时，需要注意以下几点。
◎ 在不同的Node上具有相同配置的Pod，可能会因为宿主机上的目录和文件不同而导致对Volume上目录和文件的访问结果不一致。
◎ 如果使用了资源配额管理，则Kubernetes无法将hostPath在宿主机上使用的资源纳入管理。
使用宿主机的/data目录定义了一个hostPath类型的Volume:
2
3
4
5
2- name: "Oersistent-storage"
3 hostPath:
4 path: "/data"
5
3.gcePersistentDist
** **使用这种类型的Volume表示使用谷歌公有云提供的永久磁盘（Persistent Disk， PD）存放Volume的数据，它与emptyDir不同，PD上的内容会被永久保存，当Pod删除时，PD只是被卸载（Unmount），但不会被删除。需要注意的是，你需要先创建一个PD，才能使用公测PersistentDisk。
使用gcePersistentDisk时有以下一些限制条件。
◎ Node（运行kubelet的节点）需要是GCE虚拟机。
◎ 这些虚拟机需要与PD存在于相同的GCE项目和Zone中。
通过gcloud命令即可创建一个PD：
2
2
定义gcePersistentDisk类型的Volume的示例如下：
2
3
4
5
6
7
2- name: test-volume
3 # This GCE PD must already exist.
4 gcePersistentDisk:
5 pdName: my-data-disk
6 fsType: ext4
7
4.awsElasticBlockStore
与GCE类似，该类型的Volume使用亚马逊公有云听的EBS Volume存储数据，需要先创建一个EBS Volume才能使用。
使用的限制条件如下：
◎ Node（运行kubelet的节点）需要是AWS EC2实例。
◎ 这些AWS EC2实例需要与EBS Volume存在于相同的region和availability-zone中。
◎ EBS只支持单个EC2实例挂载一个Volume。
创建一个EBS Volume：
2
2
定义awsElasticBlockStore类型的Volume的示例如下：
2
3
4
5
6
7
2- name: test-volumes
3 # This AWS EBS volume must already exist.
4 awsElasticBlockStore:
5 volumeID: aws://<availability-zone>/<volume-id>
6 fsType: ext4
7
5.NFS
** **使用NFS网络文件系统提供的共享目录存储数据时，我们需要在系统中部署一个NFS Server。定义NFS类型的Volume的示例如下：
2
3
4
5
6
7
2- name: nfs
3 nfs:
4 # 改为你的NFS服务器地址
5 server: nfs-server.localhost
6 path: "/"
7
6.其他类型的Volume
◎ iscsi：使用iSCSI存储设备上的目录挂载到Pod中。
◎ flocker：使用Flocker管理存储卷。
◎ glusterfs：使用开源GlusterFS网络文件系统的目录挂载到Pod中。
◎ rbd：使用Ceph块设备共享存储（Rados Block Device）挂载到Pod中。
◎ gitRepo：通过挂载一个空目录，并从Git库clone一个git repository以供Pod使用。
◎ secret：一个Secret Volume用于为Pod提供加密的信息，你可以将定义在Kubernetes中的Secret直接挂载为文件让Pod访问。Secret Volume是通过TMFS（内存文件系统）实现的，这种类型的Volume总是不会被持久化的。
小结：
通过文章的长度大家就可以知道Volume的重要性了，这里只是让大家有个Volume的概念，后面我们会详细全面的讲解，进行项目实战哦。
