先上个静态pv实例：
a，先在nfs服务器192.168.217.18内增加几个目录，并重启nfs服务：
[root@slave2 nfs-sc]# mkdir -p /data/nfs-sc/vm{1..3} [root@slave2 nfs-sc]# cd /data/nfs-sc/ [root@slave2 nfs-sc]# ls index.html vm1 vm2 vm3 systemctl restart nfs rpcbind [root@slave2 nfs-sc]# showmount -e slave2 Export list for slave2: /data/nfs-sc/vm3 * /data/nfs-sc/vm2 * /data/nfs-sc/vm1 * /data/nfs-sc (everyone)
b，创建三个不同容量的pv---test-pv.yaml
apiVersion: v1 kind: PersistentVolume metadata: name: vm1 #自定义pv名字 spec: capacity: storage: 100M #定义这个pv的限制存储大小 accessModes: - ReadWriteMany #定义操作的权限 storageClassName: nfs #自定义定义存储的类名,特定类的PV只能绑定到请求该类的PVC。没有storageClassName的PV没有类，只能绑定到不请求特定类的PVC nfs: path: /data/nfs-sc/vm1 #绑定主机的的路径 server: 192.168.217.18 #指定nfs主机的ip地址 --- apiVersion: v1 kind: PersistentVolume metadata: name: vm2 #自定义pv名字 spec: capacity: storage: 1Gi #定义这个pv的限制存储大小 accessModes: - ReadWriteMany #定义操作的权限 storageClassName: nfs #自定义定义存储的类名,特定类的PV只能绑定到请求该类的PVC。没有storageClassName的PV没有类，只能绑定到不请求特定类的PVC nfs: path: /data/nfs-sc/vm2 #绑定主机的的路径 server: 192.168.217.18 #指定nfs主机的ip地址 --- apiVersion: v1 kind: PersistentVolume metadata: name: vm3 #自定义pv名字 spec: capacity: storage: 3Gi #定义这个pv的限制存储大小 accessModes: - ReadWriteMany #定义操作的权限 storageClassName: nfs #自定义定义存储的类名,特定类的PV只能绑定到请求该类的PVC。没有storageClassName的PV没有类，只能绑定到不请求特定类的PVC nfs: path: /data/nfs-sc/vm3 #绑定主机的的路径 server: 192.168.217.18 #指定nfs主机的ip地址
执行脚本，查看pv状态，此时状态都是available：
[root@master nginx]# k apply -f test-pv.yaml persistentvolume/vm1 unchanged persistentvolume/vm2 created persistentvolume/vm3 created [root@master nginx]# k get pv NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE nginx-pv 3Gi RWO Retain Bound web/nginx-pvc 3h39m vm1 100M RWX Retain Available nfs 32s vm2 1Gi RWX Retain Available nfs 10s vm3 3Gi RWX Retain Available nfs 10s
c:创建pvc--test-pvc.yaml
kind: PersistentVolumeClaim apiVersion: v1 metadata: name: nginx-pvc #这个名字随便了，一哈pod部署的时候会引用这个名字 spec: accessModes: - ReadWriteMany resources: requests: storage: 2G #定义要申请的空间大小 storageClassName: nfs #这里要和我们定义pv那里storageClassName一样才行
执行此脚本后，查看pv和pvc的状态：
[root@master nginx]# k get pv,pvc -A NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE persistentvolume/nginx-pv 3Gi RWO Retain Bound web/nginx-pvc 3h58m persistentvolume/vm1 100M RWX Retain Available nfs 19m persistentvolume/vm2 1Gi RWX Retain Available nfs 19m persistentvolume/vm3 3Gi RWX Retain Bound default/nginx-pvc nfs 19m NAMESPACE NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE default persistentvolumeclaim/nginx-pvc Bound vm3 3Gi RWX nfs 10m
OK，pvc申请的是2G，因此，只有pv叫vm3的符合，看状态是已经绑定了。下面创建一个nginx测试一哈：
deploy-test-pv.yaml
apiVersion: apps/v1 kind: Deployment metadata: labels: app: nginx-deploy-pvc name: nginx-deploy-pvc spec: replicas: 2 selector: matchLabels: app: nginx-deploy-pvc template: metadata: labels: app: nginx-deploy-pvc spec: containers: - image: nginx name: nginx volumeMounts: #这里定义pod中要挂载的路径 - name: html mountPath: /usr/share/nginx/html volumes: - name: html #和上面的挂载目录一致 persistentVolumeClaim: claimName: nginx-pvc #这里要绑定我们创建的pvc
在18服务器上的vm3文件夹下建立测试文件：
[root@slave2 vm3]# pwd /data/nfs-sc/vm3 [root@slave2 vm3]# echo "test pv and pvc" >index.html
[root@master nginx]# k exec -it nginx-deploy-pvc-98bdcc6cd-25x4w -- /bin/bash root@nginx-deploy-pvc-98bdcc6cd-25x4w:/# curl localhost test pv and pvc
OK，完成目标。以上都是静态持久化存储，那么，动态的持久化存储需要利用nfs-client插件来实现了，动态存储的优点为按需分配，自动创建pv，省去了管理pv的麻烦，可动态扩展存储，使用十分方便。
StorageClass动态存储就不说了，以往的博客做过总结，请看我原来的博客：
kubernetes学习之持久化存储StorageClass（4）_zsk_john的博客-CSDN博客
有几点需要补充一哈，关于StorageClass的注解，可以使用storageClassName: managed-nfs-storage来代替，也就是下面的文件可以改写成：
[root@master nfs-sc]# cat test-claim.yaml kind: PersistentVolumeClaim apiVersion: v1 metadata: name: test-claim annotations: volume.beta.kubernetes.io/storage-class: "managed-nfs-storage" spec: accessModes: - ReadWriteMany resources: requests: storage: 1Mi
改成这样也是OK的：
[root@master nfs-sc]# cat test-claim.yaml kind: PersistentVolumeClaim apiVersion: v1 metadata: name: test-claim spec: accessModes: - ReadWriteMany resources: requests: storage: 1Mi volumeMode: Filesystem storageClassName: managed-nfs-storage
当用户声明一个 PVC 时，如果在 PVC 中添加了 StorageClassName 字段，其意图为：当 PVC 在集群中找不到匹配的 PV 时，会根据 StorageClassName 的定义触发相应的 Provisioner 插件创建合适的 PV 供绑定，即创建动态数据卷；动态数据卷时由 Provisioner 插件创建的，并通过 StorageClassName 与 PVC 进行关联。
StorageClass 可译为存储类，表示为一个创建 PV 存储卷的模板；在 PVC 触发自动创建PV的过程中，即使用 StorageClass 对象中的内容进行创建。其内容包括：目标 Provisioner 名字，创建 PV 的详细参数，回收模式等配置。
总结：
StorageClassName 也就是sc的名字可在pv和pvc里都定义的哦，如果是动态存储，pv自然是不需要写了，免去了很多麻烦。StorageClassName可以以注解的方式定义，但目前好像是抛弃了此方式。
pvc和将要使用pvc的pod应该是处于一个namespace，这里需要特别注意，否则会报错找不到pvc。
nfs-client插件是有namespace限定的，但，pvc可以与其不是一个namespace。
