简介

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

测试结果

1. pod删除重建后数据依然存在，旧pod名称及数据依然保留给新pod使用
2. sc删除重建后数据依然存在，旧pod名称及数据依然保留给新pod使用
3. 删除PVC后，PV被删除且NFS Server对应数据被删除

第二种配置

archiveOnDelete: "false"
reclaimPolicy: Retain

测试结果

1. pod删除重建后数据依然存在，旧pod名称及数据依然保留给新pod使用
2. sc删除重建后数据依然存在，旧pod名称及数据依然保留给新pod使用
3. 删除PVC后，PV不会被删除，且状态由Bound变为Released，NFS Server对应数据被保留
4. 重建sc后，新建PVC会绑定新的pv，旧数据可以拷贝到新的PV中

第三种配置

archiveOnDelete: "ture" 
reclaimPolicy: Retain

测试结果

1. pod删除重建后数据依然存在，旧pod名称及数据依然保留给新pod使用
2. sc删除重建后数据依然存在，旧pod名称及数据依然保留给新pod使用
3. 删除PVC后，PV不会被删除，且状态由Bound变为Released，NFS Server对应数据被保留
4. 重建sc后新建PVC会绑定新的pv，旧数据可以通过拷贝到新的PV中

第四种配置

archiveOnDelete: "ture"
reclaimPolicy: Delete 

测试结果

1. pod删除重建后数据依然存在，旧pod名称及数据依然保留给新pod使用
2. sc删除重建后数据依然存在，旧pod名称及数据依然保留给新pod使用
3. 删除PVC后，PV不会被删除，且状态由Bound变为Released，NFS Server对应数据被保留
4. 重建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