（1）Volume概要知识

默认情况下容器中的磁盘文件是非持久化的，对于运行在容器中的应用来说面临两个问题：

第一：当容器挂掉kubelet将重启启动它时，文件将会丢失；

第二：当Pod中同时运行多个容器，容器之间需要共享文件时。Kubernetes的Volume解决了这两个问题。

Kubernetes Volume具有明确的生命周期，与pod相同。因此，Volume的生命周期比Pod中运行的任何容器要持久，在容器重新启动时能可以保留数据，当然，当Pod被删除不存在时，Volume也将消失。

Kubernetes支持许多类型的Volume，Pod可以同时使用任意类型/数量的Volume。

要使用Volume，pod需要指定Volume的类型和内容（spec.volumes字段），和映射到容器的位置（spec.containers.volumeMounts字段）。

Volume的配置样例：

template:

  metadata:

    labels:

      app: app-demo

      tier: frontend

  spec:

    volumes:

    - name: datavol

      emptyDir: {}

    containers:

    - name: tomcat-demo

      image: tomcat

      volumeMounts:

        - mountPath: /mydata-data

          name: datavol

      imagePullPolicy: IfNotPresent      

 

 

（2）Volume 类型

Kubernetes支持Volume类型有：

emptyDir

hostPath

gcePersistentDisk

awsElasticBlockStore

nfs

iscsi

fc (fibre channel)

flocker

glusterfs

rbd

cephfs

gitRepo

secret

persistentVolumeClaim

downwardAPI

projected

azureFileVolume

azureDisk

vsphereVolume

Quobyte

PortworxVolume

ScaleIO

StorageOS

local

（3）emptyDir

使用emptyDir时，当Pod分配到Node上时，将会创建一个emptyDir Volume，它的内容为空，并且只要Node上的Pod一直运行，Volume就会一直存在。当Pod（不管任何原因）从Node上被删除时，emptyDir也同时会删除，存储的数据也将永久删除。emptyDir Volume的存储介质（Disk，SSD等）取决于kubelet根目录（如/var/lib/kubelet）所处文件系统的存储介质。不限制emptyDir或hostPath Volume使用的空间大小，不对容器或Pod的资源隔离。

注：删除容器不影响emptyDir。

emptyDir的一些用途：

临时空间

一个容器需要从另一个容器中获取数据的目录

示例：

apiVersion: v1

kind: Pod

metadata:

  name: test-pd

spec:

  containers:

  - image: gcr.io/google_containers/test-webserver

    name: test-container

    volumeMounts:

    - mountPath: /cache

      name: cache-volume

  volumes:

  - name: cache-volume

    emptyDir: {}

 

（4）hostPath

hostPath允许挂载Node上的文件系统到Pod里面去。如果Pod需要使用Node上的文件，可以使用hostPath。

通常有以下两种使用场景：

（1）容器应用程序生成的日志文件需要永久保存时，可以使用宿主机的文件系统进行存储。

（2）需要访问宿主机上Docker引擎内部数据结构的容器应用时，可以通过定义hostPath为宿主机/var/lib/docker目录，使容器内部应用可以直接访问Docker的文件系统。

使用hostPath的注意事项：

在不同的Node上具有相同配置的Pod，可能会因为宿主机上的目录和文件不同而导致对Volume上目录和文件的访问结果不一致。

如果使用了资源配额管理，则k8s无法将hostPath在宿主机上使用的资源纳入管理。

hostPath使用示例：

apiVersion: v1

kind: Pod

metadata:

  name: test-pd

spec:

  containers:

  - image: gcr.io/google_containers/test-webserver

    name: test-container

    volumeMounts:

    - mountPath: /test-pd

      name: test-volume

  volumes:

  - name: test-volume

    hostPath:

      # directory location on host

      path: /data

（5）NFS

Kubernetes中通过简单地配置就可以挂载NFS到Pod中，而NFS中的数据是可以永久保存的，同时NFS支持同时写操作。Pod被删除时，Volume被卸载，内容被保留。这就意味着NFS能够允许我们提前对数据进行处理，而且这些数据可以在Pod之间相互传递。

NFS使用示例（PV）：nfs-pv.yaml

apiVersion: v1

kind: PersistentVolume

metadata:

  name: nfs

spec:

  capacity:

    storage: 1Mi

  accessModes:

    - ReadWriteMany

  nfs:

    # FIXME: use the right IP

    server: 10.244.1.4

    path: "/exports"

 

Persistent Volume（PV）

PersistentVolume子系统为用户和管理员提供了一个API，它抽象了如何提供存储以及如何使用它的细节。 为此，我们引入两个新的API资源：PersistentVolume和PersistentVolumeClaim。

PersistentVolume（PV）是管理员设置的群集中的一部分存储。 它就像集群中的一个资源，就像一个节点是集群资源一样。 PV是类似Volumes的插件，但具有独立于Pod的生命周期。 此API对象捕获存储实现的细节，即NFS，iSCSI或特定于云提供程序的存储系统。

PersistentVolumeClaim（PVC）是用户存储的请求。 它与Pod相似。 Pod消耗节点资源，PVC消耗PV资源。 Pod可以请求特定级别的资源（CPU和内存）。 PVC声明可以请求特定的存储空间大小和访问模式（例如，可以一次读/写或多次只读）。

PV可以理解成是k8s集群中的某个网络存储中对应的一块存储资源，它与Volume很类似，但有以下区别：

PV只能是网络存储，不属于任何Node，但可以在每个Node上访问；

PV不是定义是Pod上的，而是独立定义的；

PV目前支持的存储类型包括：gcePersistentDisk、AWSElasticBlockStore、AzureFile、AzureDisk、FC、Flocker、NFS、iSCSI、RBD、CephFS、Cinder、GlusterFS、Vsphere Volume、Quobyte Volumes、VMware Photon、Portworx Volumes、ScaleIO Volumes和HostPath(仅支持单机测试使用)。

比较重要的PV的accessModes属性：

ReadWriteOnce: 读写权限，只能被单个Node挂载；

ReadOnlyMany: 只读权限，允许被多个Node挂载；

ReadWriteMany: 读写权限，允许被多个Node挂载；

PV的几种状态：

Available

Bound

Released: 对应的PVC已经删除，但资源还没有被集群回收。

Failed：PV自动回收失败。

PV/PVC使用示例：nfs-pvc.yaml

kind: PersistentVolumeClaim

apiVersion: v1

metadata:

  name: my-nfs

spec:

  accessModes:

    - ReadWriteMany

  resources:

    requests:

      storage: 1Mi

注：PV的示例参见上一段落的NFS使用示例。

 

然后，在Pod的Volume定义中引用上述PVC即可：

      volumes:

        - name: mypvc

          persistentVolumeClaim:

            claimName: my-nfs