Kubernetes对象中的PersistentVolume、PersistentVolumeClaim和StorageClass的概念关系

Kubernetes容器要持久化数据，离不开volume，k8s的volume和Docker原生概念中的volume有一些差别，不过本次不讲这个，本次要明确的是k8s持久化数据用到的几个对象PersistentVolume、PersistentVolumeClaim和StorageClass，首先明确这既然都是k8s对象，就可以通过API来创建的。

k8s的volume支持的类型有很多，例如emptyDir、hostPath、nfs等，这些相对好理解，还有一种就是ersistentVolumeClaim，刚开始接触的时候不太理解这个对象该如何使用，本次主要介绍ersistentVolumeClaim相关的概念和使用方法。

开始先要提一下PersistentVolume（PV）对象，PersistentVolume和Volume一样是群集中的一块存储区域，然而Kubernetes将PersistentVolume抽象成了一种集群资源，类似于集群中的节点(Node)对象，这意味着我们可以使用Kubernetes API来创建PersistentVolume对象。PV与Volume最大的不同是PV拥有着独立于Pod的生命周期。

而PersistentVolumeClaim（PVC）代表了用户对PV资源的请求。用户需要使用PV资源时，只需要创建一个PVC对象（包括指定使用何种存储资源，使用多少GB，以何种模式使用PV等信息），Kubernetes会自动为我们分配我们所需的PV。如果把PersistentVolume类比成集群中的Node，那么PersistentVolumeClaim就相当于集群中的Pod，Kubernetes为Pod分配可用的Node，类似的也可以理解成为PersistentVolumeClaim分配可用的PersistentVolume。

1、静态创建PV对象

可以直接静态创建一个PV对象，作为一个存储供PVC使用，创建PV主要有下面几个参数

accessModes 访问模式有下面三种：

ReadWriteOnce（RWO）：是最基本的方式，可读可写，但只支持被单个 Pod 挂载。
ReadOnlyMany（ROX）：只读模式，可以被多个 Pod 挂载。
ReadWriteMany（RWX）：可读可写，并且可以被被多个 Pod 挂载。

persistentVolumeReclaimPolicy 回收策略，即 PVC 释放卷的时候 PV 该如何操作，有下面三种：

Retain，不清理，删除PVC时，PV仍然存在并标记为“released”（需要删除时需要手动清理）

Recycle，删除数据，对卷执行清理（rm -rf / thevolume / *），并使其再次可用于新索引（只有 NFS 和 HostPath 支持）

Delete，删除存储资源，会从Kubernetes中删除PV对象，以及外部基础结构中的关联存储资产，例如AWS EBS，GCE PD，Azure磁盘或Cinder卷

#静态创建PV
apiVersion: v1

kind: PersistentVolume

metadata:

  name: pv0003

spec:

  capacity:

    storage: 5Gi

  volumeMode: Filesystem

  accessModes:

    - ReadWriteOnce

  persistentVolumeReclaimPolicy: Recycle

  storageClassName: slow

  mountOptions:

    - hard

    - nfsvers=4.1

  nfs:

    path: /tmp

    server: 172.17.0.2

定义PV时，我们需要指定其底层存储的类型，例如上文中创建的PV，底层使用nfs存储，支持的类型很多，例如awsElasticBlockStore、FC、nfs、RBD、CephFS、Hostpath、StorageOS等等，可以查看官方文档。

可以查看当前集群下创建的PV对象，kubectl get PersistentVolume --all-namespaces

2、静态创建PVC对象

创建PV之后，并没有被使用，如果想使用这个PV就需要创建PVC了，最后在pod中指定使用这个PVC而建立起pod和PV的关系。

#静态创建PVC
apiVersion: v1

kind: PersistentVolumeClaim

metadata:

  name: myclaim

spec:

  accessModes:

    - ReadWriteOnce
  volumeMode: Filesystem

  resources:

    requests:

      storage: 8Gi

  storageClassName: slow

  selector:

    matchLabels:

      release: "stable"

#pod使用PVC

kind: Pod

apiVersion: v1

metadata:

  name: mypod

spec:

  containers:

    - name: myfrontend

      image: dockerfile/nginx

      volumeMounts:

      - mountPath: "/var/www/html"

        name: mypd

  volumes:

    - name: mypd

      persistentVolumeClaim:

        claimName: myclaim

分析一下上面的代码：

创建PVC时指定了accessModes = ReadWriteOnce。这表明这个PVC希望使用accessModes = ReadWriteOnce的PV。
创建PVC时指定了volumeMode= Filesystem。这表明这个PVC希望使用volumeMode= Filesystem的PV。
创建PVC时指定了storageClassName: slow，此配置用于绑定PVC和PV，意思是这个PVC希望使用storageClassName=slow的PV。我们可以看到最上面创建PV时也包含storageClassName=slow的配置。
PVC还可以指定PV必须满足的Label，如加了selector匹配matchLabels: release: "stable"。这表明此PVC希望使用Label：release: "stable"的PV。
最后是resources声明，跟pod一样可以声明使用特定数量的资源，storage: 8Gi表明此PVC希望使用8G的Volume资源。

通过上面的分析，我们可以看到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-dir

          mountPath: /var/mysql/data

      #volumes:

      #- name: data-dir

      #  hostPath:

      #    path: /opt/mysql

  volumeClaimTemplates:

  - metadata:
      #annotations: volume.alpha.kubernetes.io/storage-class: xxxx

      creationTimestamp: null

      name: data-dir

    spec:

      accessModes:

      - ReadWriteOnce

      resources:

        requests:

          storage: 10Gi

      storageClassName: slow

      volumeMode: Filesystem

    status:

      phase: Pending

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

      volumes:

      - name: config

        configMap:

          name: {{ template "redis-ha.fullname" . }}-configmap

      - name: probes

        configMap:

          name: {{ template "redis-ha.fullname" . }}-probes

      {{- if .Values.sysctlImage.mountHostSys }}

      - name: host-sys

        hostPath:

          path: /sys

      {{- end }}

{{- if .Values.persistentVolume.enabled }}

  volumeClaimTemplates:

  - metadata:

      name: data

      annotations:

      {{- 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: data

        hostPath:

          path: {{ tpl .Values.hostPath.path .}}

{{- else }}

      - name: data

        emptyDir: {}

{{- end }}

总结一下整个过程

Kubernetes对象中的PersistentVolume、PersistentVolumeClaim和StorageClass的概念关系-LMLPHP

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/

pvc

Kubernetes对象中的PersistentVolume、PersistentVolumeClaim和StorageClass的概念关系