一、pv和pvc概述
1、pv和pvc的关系
PV：K8S在指定的存储设备中逻辑划分创建出来的可持久化的存储资源对象
PVC：对PV存储资源对象的请求和绑定，也是Pod能够定义使用的一种存储卷类型(persistentVolumeClaim)
PV是集群中的资源。 PVC是对这些资源的请求，也是对资源的索引检查。
PVC 的使用逻辑：
在 Pod 中定义一个存储卷（该存储卷类型为 PVC），定义的时候直接指定大小，PVC 必须与对应的 PV 建立关系，PVC 会根据配置的定义去 PV 申请，而 PV 是由存储空间创建出来的。PV 和 PVC 是 Kubernetes 抽象出来的一种存储资源。
2、创建pv资源的方式
静态创建pv
原理：Kubernetes 管理员在集群中预先定义一些存储资源，并逻辑划分这些存储资源对象，将这些资源暴露给集群中的用户使用
动态创建pv
上述介绍的PV和PVC模式是需要运维人员先创建好PV，然后开发人员定义好PVC进行一对一的Bond，但是如果PVC请求成千上万，那么就需要创建成千上万的PV，对于运维人员来说维护成本很高，Kubernetes提供一种自动创建PV的机制，叫StorageClass，它的作用就是创建PV的模板。
原理：根据PVC的配置通过引用StorageClass(简称SC)资源触发存储卷插件动态的创建PV资源
pvc和pv绑定，才可以给pod使用，StorageClass是创建pv的模板
3、PV和PVC的生命周期
Provisioning（配置）---> Binding（绑定）---> Using（使用）---> Releasing（释放） ---> Recycling（回收）
●Provisioning，即 PV 的创建，可以直接创建 PV（静态方式），也可以使用 StorageClass 动态创建
●Binding，将 PV 分配给 PVC
●Using，Pod 通过 PVC 使用该 Volume，并可以通过准入控制StorageProtection（1.9及以前版本为PVCProtection） 阻止删除正在使用的 PVC
●Releasing，Pod 释放 Volume 并删除 PVC
●Recycling，回收 PV，可以保留 PV 以便下次使用，也可以直接从云存储中删除
根据这 5 个阶段，PV 的状态有以下 4 种：
●Available（可用）：表示可用状态，还未被任何 PVC 绑定
●Bound（已绑定）：表示 PV 已经绑定到 PVC
●Released（已释放）：表示 PVC 被删掉，但是资源尚未被集群回收
●Failed（失败）：表示如果 PV 或 PVC 遇到无法解决的问题，例如配额不足、配置错误或者绑定过程中的异常情况，可能会进入 Failed 状态
一个PV从创建到销毁的具体流程如下：
1、一个PV创建完后状态会变成Available，等待被PVC绑定。
2、一旦被PVC邦定，PV的状态会变成Bound，就可以被定义了相应PVC的Pod使用。
3、Pod使用完后会释放PV，PV的状态变成Released。
4、变成Released的PV会根据定义的回收策略做相应的回收工作。有三种回收策略，Retain、Delete和Recycle。Retain就是保留现场，K8S集群什么也不做，等待用户手动去处理PV里的数据，处理完后，再手动删除PV。Delete策略，K8S会自动删除该PV及里面的数据。Recycle方式，K8S会将PV里的数据删除，然后把PV的状态变成Available，又可以被新的PVC绑定使用。
二、pv的各种参数定义
1、查看pv的定义方式
kubectl explain pv #查看pv的定义方式
FIELDS:apiVersion: v1kind: PersistentVolumemetadata: #由于 PV 是集群级别的资源，即 PV 可以跨 namespace 使用，所以 PV 的 metadata 中不用配置 namespacename: spec
2、pv定义的规格
kubectl explain pv.spec #查看pv定义的规格
spec:
nfs:（定义存储类型）
path:（定义挂载卷路径）
server:（定义服务器名称）
accessModes:（定义访问模式，有以下三种访问模式，以列表的方式存在，也就是说可以定义多个访问模式）
- ReadWriteOnce #（RWO）卷可以被一个节点以读写方式挂载。 ReadWriteOnce 访问模式也允许运行在同一节点上的多个 Pod 访问卷。
- ReadOnlyMany #（ROX）卷可以被多个节点以只读方式挂载。
- ReadWriteMany #（RWX）卷可以被多个节点以读写方式挂载。
#nfs 支持全部三种；iSCSI 不支持 ReadWriteMany（iSCSI 就是在 IP 网络上运行 SCSI 协议的一种网络存储技术）；HostPath 不支持 ReadOnlyMany 和 ReadWriteMany。
capacity:（定义存储能力，一般用于设置存储空间）
storage: 2Gi （指定大小）
storageClassName: （自定义存储类名称，此配置用于绑定具有相同类别的PVC和PV）
persistentVolumeReclaimPolicy: Retain #回收策略（Retain/Delete/Recycle）
#Retain（保留）：当用户删除与之绑定的PVC时候，这个PV被标记为released（PVC与PV解绑但还没有执行回收策略）且之前的数据依然保存在该PV上，但是该PV不可用，需要手动来处理这些数据并删除该PV。
#Delete（删除）：删除与PV相连的后端存储资源。对于动态配置的PV来说，默认回收策略为Delete。表示当用户删除对应的PVC时，动态配置的volume将被自动删除。（只有 AWS EBS, GCE PD, Azure Disk 和 Cinder 支持）
#Recycle（回收）：如果用户删除PVC，则删除卷上的数据，卷不会删除。（只有 NFS 和 HostPath 支持）
三、实战演练
1、创建静态pv
配置nfs
192.168.10.31服务器配置nfs，
mkdir -p /data/volumes/v{1..5}
vim /etc/exports
/data/volumes/v1 192.168.10.0/24(rw,sync,no_root_squash)
/data/volumes/v2 192.168.10.0/24(rw,sync,no_root_squash)
/data/volumes/v3 192.168.10.0/24(rw,sync,no_root_squash)
/data/volumes/v4 192.168.10.0/24(rw,sync,no_root_squash)
/data/volumes/v5 192.168.10.0/24(rw,sync,no_root_squash)exportfs -arv
在node节点上可以查看到共享文件
创建pv
vim demo1-pv.yamlapiVersion: v1
kind: PersistentVolume
metadata:name: pv001
spec:capacity:storage: 1GiaccessModes:- ReadWriteOnce- ReadWriteMany#persistentVolumeReclaimPolicy: Recycle #storageClassName: slow nfs:path: /data/volumes/v1server: 192.168.10.31kubectl apply -f demo1-pv.yaml
若要多创建几个pv可以直接在demo-v1.yaml文件中定义
创建pvc
vim demo2-pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:name: mypvc001
spec:accessModes:- ReadWriteManyresources:requests:storage: 2Gi#storageClassName: slow
kubectl apply -f demo2-pvc.yaml
结合pod，将pv、pvc一起运行
vim demo3-pod.yaml apiVersion: v1
kind: Pod
metadata:labels:run: demo3name: demo3-pod
spec:volumes:- name: scj-volpersistentVolumeClaim:claimName: mypvc003containers:- image: nginx:latestname: myappports:- containerPort: 80resources: {}volumeMounts:- name: scj-volmountPath: /mntdnsPolicy: ClusterFirstrestartPolicy: Always
status: {}
注：pvc绑定pod资源之后无法直接删除，需要先删除对应的pod资源才能够删除
2、创建动态pv
搭建 StorageClass + nfs-client-provisioner ，实现 NFS 的动态 PV 创建
上传nfs-client-provisioner.tar 、nfs-client.zip压缩包到master节点上传nfs-client-provisioner.tar到两个node节点Kubernetes 本身支持的动态 PV 创建不包括 NFS，所以需要使用外部存储卷插件分配PV。详见：https://kubernetes.io/zh/docs/concepts/storage/storage-classes/
卷插件称为 Provisioner（存储制备器），NFS 使用的是 nfs-client，这个外部卷插件会使用已经配置好的 NFS 服务器自动创建 PV。
Provisioner：用于指定 Volume 插件的类型，包括内置插件（如 kubernetes.io/aws-ebs）和外部插件（如 external-storage 提供的 ceph.com/cephfs）。
创建 Service Account，用来管理 NFS Provisioner 在 k8s 集群中运行的权限和动态规则
master节点
kubectl apply -f nfs-client-rbac.yaml
kubectl get serviceaccounts
创建nfs存储卷插件
此时再创建一个目录
删除pv前需要先删除pod ，否则删除失败
总结：
创建PV的方式：
静态PV创建：手动根据PV资源对象的配置文件创建PV资源
动态PV创建：根据PVC的配置通过引用StorageClass(简称SC)资源触发存储卷插件动态的创建PV资源
PV的4种状态：
Available（可用）：表示为可用状态，此时PV已经被创建出来了，但还未被PVC绑定
Bound（已绑定）：表示PV已经与PVC绑定了（PV与PVC是一对一的绑定关系），此时PVC可以被Pod使用
Released（已释放）：表示PVC被删除了，但PV还没被回收
Failed（失败）：表示PV或PVC遇到无法解决的问题
静态PV创建的步骤：
1）准备好存储设备
2）准备创建PV资源的配置文件，定义访问模式(ReadWriteOnce、ReadOnlyMany、ReadWriteMany、ReadWriteOncePod)、最大存储空间、回收策略(Retain、Recycle、Delete)、存储设备类型等配置
3）准备创建PVC资源的配置文件，定义使用的访问模式(必要条件，必须是PV支持的访问模式)、请求的存储空间大小(默认就近选择大于等于指定大小的PV)等配置来绑定PV
4）准备创建Pod资源的配置文件，定义存储卷类型为PVC存储卷(persistentVolumeClaim)，并在容器配置中定义存储卷挂载点路径
动态PV创建的步骤：
1）准备好存储设备
2）如果是外置存储卷插件，需要先创建Pod使用的sa账户和RBAC授权（创建角色授予相关资源对象的操作权限，并将账户与角色绑定），使得sa账户具有对PV、PVC、SC等资源的操作权限
3）准备创建外置存储卷插件Pod资源的配置文件，定义serviceAccountName为上一步创建的sa账户，并设置容器的环境变量的值（比如存储卷插件名称，服务器地址等）
4）准备创建SC资源(StorageClass)的配置文件，设置 provisioner(存储卷插件名称)、parameters(PV的参数) 和 reclaimPolicy(PV的回收策略) 等字段配置
-------------------以上操作是一劳永逸的，创建好存储卷插件和StorageClass资源以后，只要创建PVC资源引用SC资源就可以自动触发存储卷插件动态创建PV资源-------------------
5）准备创建PVC资源的配置文件，定义使用的访问模式、请求的存储空间大小、storageClassName 等配置来动态创建PV资源并绑定PV
6）准备创建Pod资源的配置文件，定义存储卷类型为PVC存储卷(persistentVolumeClaim)，并在容器配置中定义存储卷挂载点路径