【原创】Kubernetes-PV和PVC的原理和实践
一、什么是PV和PVC？
PV的全称是Persistent Volume，翻译过来为持久化存储卷，是对底层的共享存储的一种抽象，PV由管理员进行创建和配置，主要含存储能力、访问模式、存储类型、回收策略、后端存储类型等主要信息，它和具体的底层的共享存储技术的实现方式有关，比如NFS、Hostpath、RBD等。
PVC的全称是: PersistenVolumeClaim (持久化卷声明)，PVC是用户存储的一种声明，PVC和Pod类似，Pod是消耗节点node资源，PVC消耗的是PV资源，Pod可以请求CPU的内存，而PVC可以请求特定的存储空间和访问模式。
二、PV和PVC的使用场景
配图来自K8S权威指南第四版
存储工程师把分布式存储系统上的总空间划分成一个一个小的存储块，K8S的集群管理员将存储块和PV进行一一对应，用户通过PVC对对存储进行申请，比如可以指定具体容量的大小，访问模式或者存储类型，这样的好处是用户不需要关心底层的存储实现细节，只需要直接申请使用PVC即可，若申请的PVC所对应的PV不能满足用户的要求，不会生效，直到有合适的PV生成，PVC会自动与PV完成绑定，存储工程师、K8S管理员，用户之间业务解耦，灵活性更强。
三、创建PV
PV支持多种不同类型的存储，如：NFS、hostpath、RBD、ICCSI，本文以hostpath为例介绍如何创建PV
第一步：现在宿主机data目录下data/pod/volume1，volume1将作为PV对应的hostpath本地存储的目录
第二步：通过yaml文件创建PV
1 [root@k8s-master zhanglei]# cat pv-hostpath.yaml
2 kind: PersistentVolume #指定为PV类型
3 apiVersion: v1
4 metadata:
5 name: pv-statefulset #指定PV的名称
6 labels: #指定PV的标签
7 release: stable
8 spec:
9 capacity:
10 storage: 0.1Gi #指定PV的容量
11 accessModes:
12 - ReadWriteOnce #指定PV的访问模式，简写为RWO，只支持挂在1个Pod的读和写
13 persistentVolumeReclaimPolicy: Recycle #指定PV的回收策略，Recycle表示支持回收，回收完成后支持再次利用
14 hostPath: #指定PV的存储类型，本文是以hostpath为例
15 path: /data/pod/volume1 #指定PV对应后端存储hostpath的目录
说明：
accessModes支持多种访问模式
1）ReadWriteOnce（RWO）：读写权限，但是只支持挂载在1个Node
2）ReadOnlyMany（ROX）：只读权限，支持挂载在多个Node
3）ReadWriteMany（RW）：读写权限，支持挂载在多个Node
persistentVolumeReclaimPolicy的策略，指的是如果PVC被释放掉后，PV的处理，这里所说的释放，指的是用户删除PVC后，与PVC对应的PV会被释放掉，PVC个PV是一一对应的关系
1）Retain，PV的数据不会清理，会保留volume，如果需要清理，需要手动进行
2）Recycle，会将数据进行清理，即 rm -rf /thevolume/*（只有 NFS 和 HostPath 支持），清理完成后，PV会呈available状态，支持再次的bound
3）Delete，删除存储资源，会删除PV及后端的存储资源，比如删除 AWS EBS 卷（只有 AWS EBS, GCE PD, Azure Disk 和 Cinder 支持）
四、创建PVC
[root@k8s-master zhanglei]# cat pvc-hostpath.yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: mppvc-01 # 指定PVC的名称 namespace: default spec: accessModes: ["ReadWriteOnce"] # 指定PVC的访问模式 resources: requests: storage: 0.05Gi # PVC申请的容量
说明：
1）PVC声明了accessModes访问类型为ReadWriteOnce，创建后，系统会自动去找能够支持ReadWriteOnce访问类型的PV，若无符合条件的PV，则不会进行绑定，
2）PVC声明了storage的大小为0.05Gi，创建后，系统会自动去找能够支持此容量的PV，通常PV的容量至少要大于或者等于0.05Gi才会去进行绑定
从这里来看，对于用户来说，即只需要声明访问类型、容量、另外还可通过StorageClass声明具体的PV类型即可完成对持久化存储卷的申请，而不需要去维护和关注后端存储
五、查询PV和PVC的
经过前面的步骤我们创建了PV和PVC，现在来看下两者是否已经完成了绑定，在PV的创建已经指定了其名称为pv-statefulset，PVC的名称为mppvc-01
[root@k8s-master zhanglei]# kubectl get pv |grep pv-statefulset pv-statefulset 107374182400m RWO Recycle Bound default/mppvc-01
[root@k8s-master zhanglei]# kubectl get pvc |grep mppvc-01 mppvc-01 Bound pv-statefulset 107374182400m RWO 13d
可以看到pv-statefulset这个PV已经和mppvc-01的PVC进行了绑定（Bound），RWO和Recycle也是之前PV和PVC声明的状态，说明绑定成功
[root@k8s-master zhanglei]# kubectl describe pv pv-statefulset Name: pv-statefulset Labels: release=stable Annotations: pv.kubernetes.io/bound-by-controller: yes Finalizers: [kubernetes.io/pv-protection] StorageClass: Status: Bound Claim: default/mppvc-01 Reclaim Policy: Recycle Access Modes: RWO VolumeMode: Filesystem Capacity: 107374182400m Node Affinity: <none> Message: Source: Type: HostPath (bare host directory volume) Path: /data/pod/volume1 HostPathType: Events: <none>
[root@k8s-master zhanglei]# kubectl describe pvc mppvc-01 Name: mppvc-01 Namespace: default StorageClass: Status: Bound Volume: pv-statefulset Labels: <none> Annotations: pv.kubernetes.io/bind-completed: yes pv.kubernetes.io/bound-by-controller: yes Finalizers: [kubernetes.io/pvc-protection] Capacity: 107374182400m Access Modes: RWO VolumeMode: Filesystem Mounted By: <none> Events: <none>
再来看下PV的详细（describe）信息，可以看到type是hostpath类型，显示了数据卷在宿主机的/data/pod/volume1的目录。
六、总结
创建PV和PVC分为二步：
第一步：创建PV，支持自定义不同的存储大小和访问模式（RWX，RWO）、存放路径、后端服务server（如hostpath、或NAS盘的数据盘的挂载点）
第二步：创建PVC，绑定到PV。创建PVC的时候可以指定PVC的request storage，即申请的存储的容量，会根据申请的storage和访问模式自动匹配符合要求的PV
创建完PV和PVC主要是为了使用它来达到实现持久化存储的目的，如何进行使用请看本作者后续与statufulset有关的文章，谢谢阅读~
作者简介：云计算容器\K8S方向产品经理，学点技术，为更好地设计产品。
