概念
存储管理跟计算管理是两个不同的问题。理解每个存储系统是一件复杂的事情，特别是对于普通用户来说，有时并不需要关心各种存储实现，只希望能够安全可靠地存储数据。
为了简化对存储调度，K8S对存储的供应和使用做了抽象，以API形式提供给管理员和用户使用。要完成这一任务，引入了两个新的API资源：Persistent Volume（持久卷，以下简称PV）和Persistent Volume Claim（持久卷申请，以下简称PVC）。
PV是集群中的一块网络存储，跟Node一样，也是集群的资源。PV跟Volume(卷)类似，不过会有独立于Pod的生命周期。由系统管理员配置创建的一个数据卷（即PV类型），它代表了某一类存储插件实现。
PVC是用户的一个请求，跟Pod类似。Pod消费Node的资源，PVC消费PV的资源。Pod 能够申请特定的资源（CPU和内存）；PVC能够申请特定的尺寸和访问模式（例如可以加载一个读写，以及多个只读实例），而无须感知后端的存储实现。.
PV类型
PV类型使用插件的形式来实现。K8S现在支持以下插件：
GCEPersistentDisk
AWSElasticBlockStore
AzureFile
AzureDisk
FC (FibreChannel)
Flocker
NFS
iSCSI
RBD (CephBlock Device)
CephFS
Cinder(OpenStack block storage)
Glusterfs
VsphereVolume
QuobyteVolumes
HostPath
VMware Photon
PortworxVolumes
ScaleIOVolumes
PV、PVC生命周期
PV是集群的资源。PVC是对这一资源的请求，也是对资源的所有权的检验。PV和PVC 之间的互动遵循如下的生命周期。
供应
集群管理员会创建一系列的PV。这些PV包含了为集群用户提供的真实存储资源。可利用 K8S API来消费。
绑定
用户创建一个包含了容量和访问模式的PVC。Master会监听PVC的产生，并尝试根据请求内容查找匹配的PV，并把PV和PVC进行绑定。用户能够获取满足需要的资源，并且在使用过程中可能超出请求数量。
如果找不到合适的卷，这一申请就会持续处于非绑定状态，一直到出现合适的PV。例如一个集群准备了很多的50G大小的持久卷，（虽然总量足够）也是无法响应100G的申请的，除非把100G的PV加入集群。
使用
Pod把PVC作为卷来使用。集群会通过PVC查找绑定的PV，并Mount给Pod。对于支持多种访问方式的卷，用户在使用 PVC 作为卷时，可以指定需要的访问方式。
一旦用户拥有了一个已经绑定的PVC，被绑定的PV就归该用户所有了。用户的Pods能够通过在Pod的卷中包含的PVC来访问他们占有的PV。
释放
当用户完成对卷的使用时，就可以利用API删除PVC对象了，而且还可以重新申请。删除PVC后，对应的卷被视为“被释放”，但这时还不能给其他的PVC使用。之前的PVC数据还保存在卷中，要根据策略来进行后续处理。
回收
PV的回收策略向集群阐述了在PVC释放卷时，应如何进行后续工作。目前可以采用三种策略：保留，回收或者删除。保留策略允许重新申请这一资源。在PVC能够支持的情况下，删除策略会同时删除卷以及AWS EBS/GCE PD或者Cinder卷中的存储内容。如果插件能够支持，回收策略会执行基础的擦除操作（rm -rf/thevolume/*），这一卷就能被重新申请了。
创建范例
PV
每个PV包含一个spec，用于描述该卷的规格和状态。
cat << EOF > pv-lykops-sfs-0.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv-lykops-sfs-0
labels:
type: nfs
app: pv
version: v1
spec:
capacity:
storage: 1Gi
accessModes:
-ReadWriteMany
persistentVolumeReclaimPolicy: Recycle
nfs:
path: /data
server: 192.168.20.128
readOnly: false
EOF
kubectl create -f pv-lykops-sfs-0.yamlCapacity（容量）
一般来说，PV会指定存储容量。这里需要使用PV的capcity属性。
目前存储大小是唯一一个能够被申请的指标。
Access Modes（访问模式）
只要资源提供者支持，持久卷能够被用任何方式加载到主机上。每种存储都会有不同的能力，每个PV的访问模式也会被设置成为该卷所支持的特定模式。例如NFS能够支持多个读写客户端，但某个NFS PV可能会在服务器上以只读方式使用。每个PV都有自己的一系列的访问模式，这些访问模式取决于PV的能力。
访问模式的可选范围如下：
ReadWriteOnce：该卷能够以读写模式被加载到一个节点上。
ReadOnlyMany：该卷能够以只读模式加载到多个节点上。
ReadWriteMany：该卷能够以读写模式被多个节点同时加载。
在 CLI 下，访问模式缩写为：
RWO：ReadWriteOnce
ROX：ReadOnlyMany
RWX：ReadWriteMany
重要！一个卷不论支持多少种访问模式，同时只能以一种访问模式加载。例如一个 GCEPersistentDisk既能支持ReadWriteOnce，也能支持ReadOnlyMany。
Recycling Policy（回收策略）
当前的回收策略可选值包括：
Retain-人工重新申请
Recycle-基础擦除（“rm-rf /thevolume/*”）
Delete-相关的存储资产，例如AWSEBS或GCE PD卷一并删除。
目前，只有NFS和HostPath支持Recycle策略，AWSEBS、GCE PD支持Delete策略。
阶段（Phase）
一个卷会处于如下阶段之一：
Available：可用资源，尚未被绑定到PVC上
Bound：该卷已经被绑定
Released：PVC已经被删除，但该资源尚未被集群回收
Failed：该卷的自动回收过程失败。
CLI 会显示绑定到该 PV 的 PVC。
PVC
cat << EOF > pvc-lykops-sfs-0.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-lykops-sfs-0
labels:
type: nfs
app: pvc
version: v1
spec:
accessModes:
-ReadWriteMany
resources:
requests:
storage: 1Gi
EOF
kubectl create -f pvc-lykops-sfs-0.yaml访问模式
PVC使用跟PV一致的访问模式。
资源
PVC跟Pod一样可以请求特定数量的资源。在这里的请求内容就是存储（storage）。Resource Model 文中提到的内容对 PV 和 PVC 同样适用。
StatefulSet通用
Pod能够借助PVC来访问存储。PVC必须跟Pod处于同一个命名空间。集群找到Pod命名空间中的PVC，然后利用PVC获取到PV。这个卷就会被加载到主机上，让Pod使用。
cat << EOF > lykops-sfs.yaml
apiVersion: apps/v1beta1
kind: StatefulSet
metadata:
name: lykops-sfs
labels:
software: apache
project: lykops
app: lykops-sfs
version: v1
spec:
serviceName: lykops-sfs
template:
metadata:
labels:
software: apache
project: lykops
app: lykops-sfs
version: v1
name: test-sfs
spec:
containers:
- name: lykops-sfs
image: web:apache
ports:
- containerPort: 80
name: apache
volumeMounts:
- name: pvc
mountPath: /data/
volumeClaimTemplates:
-metadata:
name: pvc
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 1Gi
EOF
kubectl create -f lykops-sfs.yamlPV、PVC、调用资源的创建注意事项
使用限制
PVC、PV不能使用在deployment、rc、rs等场景下
命名规则
如上面的例子：
通用PVC的StatefulSet：StatefulSet名称为test-sfs，卷名为pvc
PV：pv-test-sfs-{0,1}
PVC：pvc-test-sfs-{0,1}
规则如下：
PVC和PV的命名规则为：资源类型-StatefulSet名称-副本数序号（从0开始）
PV和PVC的yaml规划
除了命名规则外，还需要保证访问accessModes、resources这两个一样
按照以上规则创建后，可以看到PV和PVC能关联起来