简介
Kubernetes支持NFS存储，需要安装nfs-subdir-external-provisioner，它是一个存储资源自动调配器，它可将现有的NFS服务器通过持久卷声明来支持Kubernetes持久卷的动态分配。该组件是对Kubernetes NFS-Client Provisioner的扩展， nfs-client-provisioner已经不提供更新，而且nfs-client-provisioner Github 仓库也已经处于归档状态，已经迁移到nfs-subdir-external-provisioner的仓库
rbac.yaml和deployment.yaml创建在任何空间都可以，storage class是集群资源，不受名称空间限制
获取NFS Subdir External Provisioner部署文件
$ wget https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner/archive/refs/tags/nfs-subdir-external-provisioner-4.0.18.zip
$ unzip -o nfs-subdir-external-provisioner-4.0.18.zip
$ cd nfs-subdir-external-provisioner-nfs-subdir-external-provisioner-4.0.18/deploy/
$ ls
创建名称空间
$ kubectl create ns nacos-test
创建RBAC资源
$ sed -i'' "s/namespace:.*/namespace: nacos-test/g" rbac.yaml deployment.yaml
$ kubectl create -f rbac.yaml
$ vim deployment.yaml
注意：/data/nfs/nacos目录一定要提前创建好
$ kubectl apply -f deployment.yaml
$ kubectl get deployment,pods -n nacos-test
部署Storage Class
$ vim class.yaml
注意：Storage class的配置参数一定要提前编辑好，Storage Class一旦被创建，则无法修改，如需更改只能删除原Storage class资源对象并重新创建。"${.PVC.namespace}/${.PVC.name}"添加后，archiveOnDelete的值为true，当删除pvc后，数据目录会被移动到nfs服务器的共享目录下和名称空间同级的以archive开头的目录
$ kubectl apply -f class.yaml
$ kubectl get sc
设置默认Storage Class
$ kubectl get sc
创建测试PVC
$ vim test-claim.yaml
$ kubectl apply -f test-claim.yaml
$ kubectl get pvc -n nacos-test
创建测试pod
$ vim test-pod.yaml
$ kubectl apply -f test-pod.yaml
$ kubectl get pod -n nacos-test
查看文件写入
查看pod内挂载
$ kubectl exec -it test-pod -n nacos-test -- sh -c "df -h"
注意：在输出结果中可以看到挂载的NFS存储的可用空间为6.1T(这是整个磁盘的大小)，而不是PVC中分配的1G，所以storage class申请的是动态资源，只要空间足够大，就不会出现数据卷资源不够的情况。
PV名称格式是pvc+随机字符串，所以每次只要不删除PVC，那么Kubernetes中PV与存储绑定将不会丢失，要是删除PVC也就意味着删除了绑定的文件夹，下次就算重新创建相同名称的PVC，生成的文件夹名称也不会一致，因为PV名是随机生成的字符串，而文件夹命名又跟PV有关，所以删除PVC需谨慎
测试删除pod和pvc
$ kubectl delete -f test-pod.yaml test-claim.yaml
$ kubectl get pod -n nacos-test
查看NFS数据目录
从结果中可以看到Kubernetes删除PVC后，在NFS存储层并没有立即删除PVC对应的数据目录及数据，而是将原来的数据目录改名为archived-+原有数据目录名称的形式。 该结果与配置Storage Class时的参数archiveOnDelete的值设置为true的预期相符
Storage Class回收策略
第一种配置
archiveOnDelete: "false"
reclaimPolicy: Delete #默认没有配置，默认值为Delete
测试结果
- pod删除重建后数据依然存在，旧pod名称及数据依然保留给新pod使用
- sc删除重建后数据依然存在，旧pod名称及数据依然保留给新pod使用
- 删除PVC后，PV被删除且NFS Server对应数据被删除
第二种配置
archiveOnDelete: "false"
reclaimPolicy: Retain
测试结果
- pod删除重建后数据依然存在，旧pod名称及数据依然保留给新pod使用
- sc删除重建后数据依然存在，旧pod名称及数据依然保留给新pod使用
- 删除PVC后，PV不会被删除，且状态由Bound变为Released，NFS Server对应数据被保留
- 重建sc后，新建PVC会绑定新的pv，旧数据可以拷贝到新的PV中
第三种配置
archiveOnDelete: "ture"
reclaimPolicy: Retain
测试结果
- pod删除重建后数据依然存在，旧pod名称及数据依然保留给新pod使用
- sc删除重建后数据依然存在，旧pod名称及数据依然保留给新pod使用
- 删除PVC后，PV不会被删除，且状态由Bound变为Released，NFS Server对应数据被保留
- 重建sc后新建PVC会绑定新的pv，旧数据可以通过拷贝到新的PV中
第四种配置
archiveOnDelete: "ture"
reclaimPolicy: Delete
测试结果
- pod删除重建后数据依然存在，旧pod名称及数据依然保留给新pod使用
- sc删除重建后数据依然存在，旧pod名称及数据依然保留给新pod使用
- 删除PVC后，PV不会被删除，且状态由Bound变为Released，NFS Server对应数据被保留
- 重建sc后，新建PVC会绑定新的pv，旧数据可以通过拷贝到新的PV中
设置默认的Storage Class
在Kubernetes中，管理员可以为有不同存储需求的PVC创建相应的Storage Class来提供动态的存储资源（PV）供应，同时在集群级别设置一个默认的Storage Class，为那些未指定Storage Class的PVC使用。管理员要明确系统默认提供的Storage Class应满足和符合PVC的资源需求，同时注意避免资源浪费
要在集群中启用默认的Storage Class，就需要在kube-apiserver服务准入控制器–enableadmission-plugins中开启 DefaultStorageClass（从 Kubernetes 1.10版本开始默认开启）
--enable-admission-plugins=.. ., DefaultStorageClass
然后在Storage Class的定义中设置一个annotation
kind: Storageclass
apiVersion: storage.k8s.io/v1
metadata:name: gold
annotations:storageclass.beta.kubernetes.io/is-default-class="true"
provisioner: kubernetes.io/gce-pd
parameters:type: pd-ssd
存储绑定模式
Immediate绑定模式
存储绑定模式的默认值为Immediate，表示当一个PersistentVolumeClaim (PVC)创建出来时，就动态创建PV并进行PVC与PV的绑定操作。需要注意的是，对于拓扑受限 (Topology-limited) 或无法从全部Node访问的后端存储，将在不了解Pod调度需求的情况下完成PV的绑定操作，这可能会导致某些Pod无法完成调度
WaitForFirstConsumer绑定模式
WaitForFirstConsumer绑定模式表示PVC与PV的绑定操作延迟到第一个使用PVC的Pod创建出来时再进行。系统将根据Pod的调度需求，在Pod所在的Node上创建PV，这些调度需求可以通过以下条件（不限于）进行设置
- Pod对资源的需求
- Node Selector
- Pod亲和性和反亲和性设置
- Taint和Toleration设置
目前支持WaitForFirstConsumer绑定模式的存储卷包括：AWSElasticBlockStore、AzureDisk、GCEPersistentDisk。另外有些存储插件通过预先创建好的PV绑定支持WaitForFirstConsumer模式，比如AWSElasticBlockStore、 AzureDisk、 GCEPersistentDisk和Local
在使用WaitForFirstConsumer模式的环境中，如果仍然希望基于特定拓扑信息（Topology）进行PV绑定操作，则在Storage Class的定义中还可以通过allowedTopologies字段进行设置。下面的例子通过matchLabelExpressions设置目标Node的标签选择条件(zone=us-central1-a或us-central1-b)PV将在满足这些条件的Node上允许创建
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:name: standard
provisioner: kubernetes.io/gce-pd
parameters:type: pd-standard
volumeBindingMode: WaitForFirstConsumer
allowedTopologies:
- matchLabelExpressions:- key: failure-domain.beta.kubernetes.io/zone vallues:- us-central1-a- us-central1-b
