1、Kubernetes集群管理员通过提供不同的存储类，可以满足用户不同的服务质量级别、备份策略和任意策略要求的存储需求。动态存储卷供应使用StorageClass进行实现，其允许存储卷按需被创建。如果没有动态存储供应，Kubernetes集群的管理员将不得不通过手工的方式类创建新的存储卷。通过动态存储卷，Kubernetes将能够按照用户的需要，自动创建其需要的存储。

基于StorageClass的动态存储供应整体过程如下图所示：
1）集群管理员预先创建存储类（StorageClass）；

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

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

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

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

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

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

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

2、example

首先创建nfs服务，参考另外一篇文章：https://blog.csdn.net/BigData_Mining/article/details/88638879

1）创建RBAC授权provisioner，（如果集群启用了RBAC，如果namespace不是default）

# cat nfs-rbac.yaml

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: nfs-provisioner
  namespace: monitoring
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
   name: nfs-provisioner-runner
   namespace: monitoring
rules:
   -  apiGroups: [""]
      resources: ["persistentvolumes"]
      verbs: ["get", "list", "watch", "create", "delete"]
   -  apiGroups: [""]
      resources: ["persistentvolumeclaims"]
      verbs: ["get", "list", "watch", "update"]
   -  apiGroups: ["storage.k8s.io"]
      resources: ["storageclasses"]
      verbs: ["get", "list", "watch"]
   -  apiGroups: [""]
      resources: ["events"]
      verbs: ["watch", "create", "update", "patch"]
   -  apiGroups: [""]
      resources: ["services", "endpoints"]
      verbs: ["get","create","list", "watch","update"]
   -  apiGroups: ["extensions"]
      resources: ["podsecuritypolicies"]
      resourceNames: ["nfs-provisioner"]
      verbs: ["use"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: run-nfs-provisioner
subjects:
  - kind: ServiceAccount
    name: nfs-provisioner
    namespace: monitoring
roleRef:
  kind: ClusterRole
  name: nfs-provisioner-runner
  apiGroup: rbac.authorization.k8s.io

2)创建nfs的nfs-client-provisioner

# cat nfs-deployment.yaml

kind: Deployment
apiVersion: extensions/v1beta1
metadata:
   name: nfs-client-provisioner
   namespace: monitoring
spec:
   replicas: 1
   strategy:
     type: Recreate
   template:
      metadata:
         labels:
            app: nfs-client-provisioner
      spec:
         serviceAccount: nfs-provisioner
         containers:
            -  name: nfs-client-provisioner
               image: quay.io/external_storage/nfs-client-provisioner:latest
               volumeMounts:
                 -  name: nfs-client-root
                    mountPath:  /persistentvolumes
               env:
                 -  name: PROVISIONER_NAME
                    value: fuseim.pri/ifs
                 -  name: NFS_SERVER
                    value: 10.2.68.77
                 -  name: NFS_PATH
                    value: /data/opv
         volumes:
           - name: nfs-client-root
             nfs:
               server: 10.2.68.77
               path: /data/opv

！！PS：10.2.68.77是nfs服务的监听地址，/data/opv是nfs共享的目录。
这个镜像中volume的mountPath默认为/persistentvolumes，不能修改，否则运行时会报错。

3)创建storageclass

# cat storageclass-nfs.yaml

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: grafana-nfs
  namespace: monitoring
provisioner: fuseim.pri/ifs
reclaimPolicy: Retain

provisioner: 该字段指定使用存储卷类型，不同的存储卷提供者类型这里要修改成对应的值。
reclaimPolicy：有两种策略：Delete、Retain。默认是Delet
用户删除PVC释放对PV的占用后，系统根据PV的"reclaim policy"决定对PV执行何种回收操作。 目前，"reclaim policy"有三种方式：Retained、Recycled、Deleted。
Retained

保护被PVC释放的PV及其上数据，并将PV状态改成"released"，不将被其它PVC绑定。集群管理员手动通过如下步骤释放存储资源：

手动删除PV，但与其相关的后端存储资源如(AWS EBS, GCE PD, Azure Disk, or Cinder volume)仍然存在。
手动清空后端存储volume上的数据。
手动删除后端存储volume，或者重复使用后端volume，为其创建新的PV。

Delete

删除被PVC释放的PV及其后端存储volume。对于动态PV其"reclaim policy"继承自其"storage class"，
默认是Delete。集群管理员负责将"storage class"的"reclaim policy"设置成用户期望的形式，否则需要用
户手动为创建后的动态PV编辑"reclaim policy"。

Recycle

保留PV，但清空其上数据，已废弃

！！PS：fuseim.pri/ifs为上面deployment上创建的PROVISIONER_NAME（可以更改，但是这两个地方必须统一）。

4)创建PersistenetVolumeClaim

在存储类被正确创建后，就可以创建PersistenetVolumeClaim来请求StorageClass，而StorageClass将会为PersistenetVolumeClaim自动创建一个可用PersistentVolume。PersistenetVolumeClaim是对PersistenetVolume的声明，即PersistenetVolume为存储的提供者，而PersistenetVolumeClaim为存储的消费者。

# cat pvc.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: test-claim
  namespace: monitoring
 # annotations:
 #   volume.beta.kubernetes.io/storage-class: "grafana-nfs"
spec:
  storageClassName: grafana-nfs
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1Mi

！！PS：grafana-nfs为上面创建的storageclass的name，1Mi是设置的目录的大小。

5)testpod

# cat testpod.yaml

kind: Pod
apiVersion: v1
metadata:
  name: test-pod
  namespace: monitoring
spec:
  containers:
  - name: test-pod
    image: busybox
    command:
      - "/bin/sh"
    args:
      - "-c"
      - "touch /mnt/SUCCESS && exit 0 || exit 1"
    volumeMounts:
      - name: nfs-pvc
        mountPath: "/mnt"
  restartPolicy: "Never"
  volumes:
    - name: nfs-pvc
      persistentVolumeClaim:
        claimName: test-claim

启动pod，一会儿pod就是completed状态，说明执行完毕。

我们去NFS共享目录查看有没有SUCCESS文件。

说明部署正常，并且可以动态分配NFS的共享卷。

StatefulSet案例

本来做StorageClass测试的目的就是为了实现StatefulSet，结果越做越跑偏。。。现在回到原本的目标，来实现一个简单的StatefulSet。

编写statefulset.yaml文件如下：

apiVersion: apps/v1beta1
kind: StatefulSet
metadata:
  name: web
spec:
  serviceName: "nginx1"
  replicas: 2
  volumeClaimTemplates:
  - metadata:
      name: test
      annotations:
        volume.beta.kubernetes.io/storage-class: "nfs"
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi
  template:
    metadata:
      labels:
        app: nginx1
    spec:
      serviceAccount: nfs-provisioner
      containers:
      - name: nginx1
        image: nginx
        imagePullPolicy: IfNotPresent
        volumeMounts:
        - mountPath: "/persistentvolumes"
          name: test

注意，这里的mountPath必须指定为/persistentvolumes，否则会出现表面上PV创建成功，其实在NFS系统中找不到的问题。

当发现两个Pod都正常运行，且在NFS系统中能够找到PV，说明试验成功。

进一步的，可以用kubectl exec -it 进入Pod，并创建一个文件，看看在PV中能否发现相同的文件已生成。