#静态创建PVapiVersion: v1
kind: PersistentVolume
metadata:name: pv0003
spec:capacity:storage: 5GivolumeMode: FilesystemaccessModes:- ReadWriteOncepersistentVolumeReclaimPolicy: RecyclestorageClassName: slowmountOptions:- hard- nfsvers=4.1nfs:path: /tmpserver: 172.17.0.2

#静态创建PVCapiVersion: v1
kind: PersistentVolumeClaim
metadata:name: myclaim
spec:accessModes:- ReadWriteOnce  volumeMode: Filesystemresources:requests:storage: 8GistorageClassName: slowselector:matchLabels:release: "stable"

#pod使用PVC
kind: Pod
apiVersion: v1
metadata:name: mypod
spec:containers:- name: myfrontendimage: dockerfile/nginxvolumeMounts:- mountPath: "/var/www/html"name: mypdvolumes:- name: mypdpersistentVolumeClaim:claimName: myclaim

通过上面的分析，我们可以看到PVC和PV的绑定，不是简单的通过Label来进行。而是要综合storageClassName，accessModes，matchLabels以及storage来匹配符合条件的PV进行绑定。

3、动态创建PV对象

    上面我们通过描述文件静态创建PV对象最终完成和pod的绑定，这种直接通过描述文件创建PV的方式称为静态创建，这样的创建方式有弊端，假如我们创建PV时指定大小为50G，而PVC请求80G的PV，那么此PVC就无法找到合适的PV来绑定。因此实际生产中更多的使用PV的动态创建。

PV的动态创建依赖于StorageClass对象。我们不需要手动创建任何PV，所有的工作都由StorageClass为我们完成，可以查看集群中的StorageClass信息 ，kubectl get StorageClass --all-namespaces

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:name: slow
provisioner: kubernetes.io/glusterfs
parameters:resturl: "http://192.168.10.100:8080"restuser: ""secretNamespace: ""secretName: ""
reclaimPolicy: Retain
allowVolumeExpansion: true

这个例子使用创建了一个基于glusterfs分布式存储的StorageClass，只有allowVolumeExpansion=teue时，才能扩展PVC，要为PVC请求更大的卷，请编辑PVC对象并指定更大的大小，这会触发底层PersistentVolume的卷的扩展。永远不会创建新的，而是调整现有卷的大小。

StorageClass的定义包含四个部分：

• provisioner：指定 Volume 插件的类型，包括内置插件（如kubernetes.io/glusterfs、kubernetes.io/aws-ebs）和外部插件（如 external-storage 提供的 ceph.com/cephfs）。
• parameters：指定 provisioner 的选项，比如 glusterfs 支持 resturl、restuser 等参数。
• mountOptions：指定挂载选项，当 PV 不支持指定的选项时会直接失败。比如 NFS 支持 hard 和 nfsvers=4.1 等选项。
• reclaimPolicy：指定回收策略，同 PV 的回收策略。

手动创建的PV时，我们指定了storageClassName=slow的配置项，然后Pod定义中也通过指定storageClassName=slow，从而完成绑定。而通过StorageClass实现动态PV时，我们只需要指定StorageClass的metadata.name即可，这个名称非常重要，用户通过名称类请求特定的存储类，储类的对象一旦被创建，name将不能再更改。
        回到上文中创建PVC的例子，此时PVC指定了storageClassName=slow。那么Kubernetes会在集群中寻找是否存在metadata.name=slow的StorageClass，如果存在，此StorageClass会自动为此PVC创建一个accessModes = ReadWriteOnce，并且大小为8GB的PV。

或者直接写到一起

#上面的部分省略了volumeMounts:- name: data-dirmountPath: /var/mysql/data#volumes:#- name: data-dir#  hostPath:#    path: /opt/mysqlvolumeClaimTemplates:- metadata:      #annotations: volume.alpha.kubernetes.io/storage-class: xxxxcreationTimestamp: nullname: data-dirspec:accessModes:- ReadWriteOnceresources:requests:storage: 10GistorageClassName: slowvolumeMode: Filesystemstatus:phase: Pending

下面是参考官方的一种比较通用的写法，基于helm的，直接将PVC的代码写到volumes的后面，根据values.yaml中的参数生成是挂载PVC的存储还是其他存储，可以作为以后自己写脚本的参考

      volumes:- name: configconfigMap:name: {{ template "redis-ha.fullname" . }}-configmap- name: probesconfigMap:name: {{ template "redis-ha.fullname" . }}-probes{{- if .Values.sysctlImage.mountHostSys }}- name: host-syshostPath:path: /sys{{- end }}
{{- if .Values.persistentVolume.enabled }}volumeClaimTemplates:- metadata:name: dataannotations:{{- range $key, $value := .Values.persistentVolume.annotations }}{{ $key }}: {{ $value }}{{- end }}spec:accessModes:{{- range .Values.persistentVolume.accessModes }}- {{ . | quote }}{{- end }}resources:requests:storage: {{ .Values.persistentVolume.size | quote }}{{- if .Values.persistentVolume.storageClass }}{{- if (eq "-" .Values.persistentVolume.storageClass) }}storageClassName: ""{{- else }}storageClassName: "{{ .Values.persistentVolume.storageClass }}"{{- end }}{{- end }}
{{- else if .Values.hostPath.path }}- name: datahostPath:path: {{ tpl .Values.hostPath.path .}}
{{- else }}- name: dataemptyDir: {}
{{- end }}

总结一下整个过程

1）集群管理员预先创建存储类（StorageClass）；

2）用户创建使用存储类的持久化存储声明(PVC：PersistentVolumeClaim)；

3）存储持久化声明通知系统，它需要一个持久化存储(PV: PersistentVolume)；

4）系统读取存储类的信息；

5）系统基于存储类的信息，在后台自动创建PVC需要的PV；

6）用户创建一个使用PVC的Pod；

7）Pod中的应用通过PVC进行数据的持久化；

8）而PVC使用PV进行数据的最终持久化处理。

官方文档 https://kubernetes.io/docs/concepts/storage/persistent-volumes/