PV、PVC、StorageClass讲解

PV、PVC、StorageClass讲解

为了方便开发人员更加容易的使用存储才出现的概念。通常我们在一个POD中定义使用存储是这样的方式，我们以hostpath类型来说：

apiVersion: v1 kind: Pod metadata: name: mypod spec: containers: - image: nginx name: mynginx volumeMounts: - mountPath: /usr/share/nginx/html name: html volumes: - name: html # 名称 hostPath: # 存储类型 path: /data # 物理节点上的真实路径 type: Directory # 如果该路径不存在讲如何处理，Directory是要求目录必须存在

其实通过上面可以看出来，无论你使用什么类型的存储你都需要手动定义，指明存储类型以及相关配置。这里的hostpath类型还是比较简单的，如果是其他类型的比如分布式存储，那么这对开发人员来说将会是一种挑战，因为毕竟真正的存储是由存储管理员来设置的他们会更加了解，那么有没有一种方式让我们使用存储更加容易，对上层使用人员屏蔽底层细节呢？答案是肯定的，这就是PV、PVC的概念。不过需要注意的是我们在集群中通常不使用hostPath、emptyDir这种类型，除非你只是测试使用。

什么是PV

PV全称叫做Persistent Volume，持久化存储卷。它是用来描述或者说用来定义一个存储卷的，这个通常都是有运维或者数据存储工程师来定义。比如下面我们定义一个NFS类型的PV：

apiVersion: v1 kind: PersistentVolume metadata: # PV建立不要加名称空间，因为PV属于集群级别的 name: nfs-pv001 # PV名称 labels: # 这些labels可以不定义 name: nfs-pv001 storetype: nfs spec: # 这里的spec和volumes里面的一样 storageClassName: normal accessModes: # 设置访问模型 - ReadWriteMany - ReadWriteOnce - ReadOnlyMany capacity: # 设置存储空间大小 storage: 500Mi persistentVolumeReclaimPolicy: Retain # 回收策略 nfs: path: /work/volumes/v1 server: stroagesrv01.contoso.com

accessModes：支持三种类型

ReadWriteMany 多路读写，卷能被集群多个节点挂载并读写

ReadWriteOnce 单路读写，卷只能被单一集群节点挂载读写

ReadOnlyMany 多路只读，卷能被多个集群节点挂载且只能读

这里的访问模型总共有三种，但是不同的存储类型支持的访问模型不同，具体支持什么需要查询官网。比如我们这里使用nfs，它支持全部三种。但是ISCI就不支持ReadWriteMany；HostPath就不支持ReadOnlyMany和ReadWriteMany。

persistentVolumeReclaimPolicy：也有三种策略，这个策略是当与之关联的PVC被删除以后，这个PV中的数据如何被处理

Retain 当删除与之绑定的PVC时候，这个PV被标记为released（PVC与PV解绑但还没有执行回收策略）且之前的数据依然保存在该PV上，但是该PV不可用，需要手动来处理这些数据并删除该PV。

Delete 当删除与之绑定的PVC时候

Recycle 这个在1.14版本中以及被废弃，取而代之的是推荐使用动态存储供给策略，它的功能是当删除与该PV关联的PVC时，自动删除该PV中的所有数据

注意：PV必须先与POD创建，而且只能是网络存储不能属于任何Node，虽然它支持HostPath类型但由于你不知道POD会被调度到哪个Node上，所以你要定义HostPath类型的PV就要保证所有节点都要有HostPath中指定的路径。

PVC

PVC是用来描述希望使用什么样的或者说是满足什么条件的存储，它的全称是Persistent Volume Claim，也就是持久化存储声明。开发人员使用这个来描述该容器需要一个什么存储。比如下面使用NFS的PVC：

apiVersion: v1 kind: PersistentVolumeClaim metadata: name: nfs-pvc001 namespace: default labels: # 这些labels可以不定义 name: nfs-pvc001 storetype: nfs capacity: 500Mi spec: storageClassName: normal accessModes: # PVC也需要定义访问模式，不过它的模式一定是和现有PV相同或者是它的子集，否则匹配不到PV - ReadWriteMany resources: # 定义资源要求PV满足这个PVC的要求才会被匹配到 requests: storage: 500Mi # 定义要求有多大空间

这个PVC就会和上面的PV进行绑定，为什么呢？它有一些原则：

PV和PVC中的spec关键字段要匹配，比如存储（storage）大小。

PV和PVC中的storageClassName字段必须一致，这个后面再说。

上面的labels中的标签只是增加一些描述，对于PVC和PV的绑定没有关系

应用了上面的PV和PVC，可以看到自动绑定了。

在POD中如何使用PVC呢 apiVersion: apps/v1 kind: Deployment metadata: name: tomcat-deploy spec: replicas: 1 selector: matchLabels: appname: myapp template: metadata: name: myapp labels: appname: myapp spec: containers: - name: myapp image: tomcat:8.5.38-jre8 ports: - name: http containerPort: 8080 protocol: TCP volumeMounts: - name: tomcatedata mountPath : "/data" volumes: - name: tomcatedata persistentVolumeClaim: claimName: nfs-pvc001