1、NFS PV PVC 介绍
NFS 即网络文件系统（Network File-System），可以通过网络让不同机器、不同系统之间可以实现文件共享。通过 NFS，可以访问远程共享目录，就像访问本地磁盘一样。NFS 只是一种文件系统，本身并没有传输功能，是基于 RPC（远程过程调用）协议实现的，采用 C/S 架构。
PersistentVolume（pv）和PersistentVolumeClaim（pvc）是k8s提供的两种API资源，用于抽象存储细节,用于实现持久化存储.
PersistentVolume（PV）是集群中由管理员配置的一段网络存储。
是由管理员设置的存储，它是群集的一部分。就像节点是集群中的资源一样，PV 也是集群中的资源。 PV 是 Volume 之类的卷插件，但具有独立于使用 PV 的 Pod 的生命周期。此 API 对象包含存储实现的细节，即 NFS、iSCSI 或特定于云供应商的存储系统
PersistentVolumeClaim（PVC）是由用户进行存储的请求。
它与 Pod 相似。Pod 消耗节点资源，PVC 消耗 PV 资源。Pod 可以请求特定级别的资源（CPU 和内存）。PVC声明可以请求特定的大小和访问模式（如:读写或只读）
PV支持的类型 https://kubernetes.io/docs/concepts/storage/persistent-volumes/#types-of-persistent-volumes
总结：Persistent Volume(持久化卷)简称PV, 是一个K8S资源对象，我们可以单独创建一个PV, 它不和Pod直接发生关系, 而是通过Persistent Volume Claim, 简称PVC来实现动态绑定, 我们会在Pod定义里指定创建好的PVC, 然后PVC会根据Pod的要求去自动绑定合适的PV给Pod使用。
访问模式(accessModes)
ReadWriteOnce – PV以 read-write 挂载到一个节点
ReadWriteMany – PV以 read-write方式挂载到多个节点
ReadOnlyMany – PV以 read-only方式挂载到多个节点
————————————————
版权声明：本文为CSDN博主「dz45693」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/ma_jiang/article/details/114266565
2、安装 NFS 软件包
#1安装nfs服务端 sudo apt install nfs-kernel-server -y #2. 创建目录 sudo mkdir -p /data/k8s/ #3. 使任何客户端均可访问 sudo chown nobody:nogroup /data/k8s/ #sudo chmod 755 /data/k8s/ sudo chmod 777 /data/k8s/ #4. 配置/etc/exports文件, 使任何ip均可访问(加入以下语句) vi /etc/exports /data/k8s/ *(rw,sync,no_subtree_check) #5. 检查nfs服务的目录 sudo exportfs -ra (重新加载配置) sudo showmount -e (查看共享的目录和允许访问的ip段) #6. 重启nfs服务使以上配置生效 sudo systemctl restart nfs-kernel-server #sudo /etc/init.d/nfs-kernel-server restart #查看nfs服务的状态是否为active状态:active(exited)或active(runing) systemctl status nfs-kernel-server #7. 测试nfs服务是否成功启动 #安装nfs 客户端 sudo apt-get install nfs-common #创建挂载目录 sudo mkdir /data/k8s/ #7.4 在主机上的Linux中测试是否正常 sudo mount -t nfs -o nolock -o tcp 192.168.100.11:/data/k8s/ /data/k8s/(挂载成功，说明nfs服务正常) #错误 mount.nfs: access denied by server while mounting
3创建pv（master上）vim mypv.yaml //内容如下
apiVersion: v1 kind: PersistentVolume metadata: name: pv001 spec: capacity: storage: 100M accessModes: - ReadWriteMany nfs: path: /data/k8s/ server: 192.168.100.11
kubectl create -f mypv.yaml
kubectl get pv
状态为Available，这是因为它还没有绑定到任何的pvc上面，当定义完pvc后，就可以自动绑定了。
4 创建pvc（master上）vim mypvc.yaml //内容如下
kind: PersistentVolumeClaim apiVersion: v1 metadata: name: myclaim spec: accessModes: - ReadWriteMany resources: requests: storage: 8M
kubectl create -f mypvc.yaml
kubectl get pvc
可以看到，pvc状态为Bound，它绑定了pv001
经过测试，发现在k8s，PVC 也是namespace隔离的。这里没有指定，就是默认的namespace。pvc是命名空间隔离的，pv可以全局共享，不用指定命名空间。pv是全局的,pvc可以指定namespace,在如下位置加入 namespace
metadata: name: myclaim #PVC的名称 namespace: go
5 定义pod vim pvpod.yaml //内容如下
apiVersion: v1 kind: Pod metadata: name: httpd-pvpod spec: containers: - image: httpd name: httpd-withpvc-pod imagePullPolicy: Always volumeMounts: - mountPath: "/usr/local/apache2/htdocs/" name: httpd-volume volumes: - name: httpd-volume persistentVolumeClaim: claimName: myclaim
kubectl create -f pvpod.yaml
kubectl describe pod httpd-pvpod //查看Volumes那部分里的ClaimName
6 验证
#1到NFS的共享目录下创建一个文件 cd /data/k8s/ echo "Test file" > 1.html #2进入到httpd-pod里 #kubectl exec -it httpd-pvpod bash kubectl exec -it httpd-pvpod /bin/sh cat /usr/local/apache2/htdocs/1.html #3删除httpd-pvpod kubectl delete pod httpd-pvpod cat /data/k8s/1.html #4重建httpd-pod kubectl create -f pvpod.yaml #5curl访问 kubectl get pod httpd-pvpod -o wide //查看其对应的IP
一般删除步骤为：先删pod再删pvc最后删pv
kubectl delete pvc xxx -n senyint #但是遇到pv始终处于“Terminating”状态，而且delete不掉。解决方法：直接删除k8s中的记录： kubectl patch pv xxx -p '{"metadata":{"finalizers":null}}' -n senyint #强制删除 pod kubectl delete pod PODNAME --force --grace-period=0 -n senyint #强制删除 namespace kubectl delete namespace NAMESPACENAME --force --grace-period=0 -n senyint
备注：
4. 过程问题整理
1) pvc一直处于Pending状态，使用命令查看详细信息
kubectl get pvc kubectl describe pvc myclaim #查找原因 #kubectl describe pvc myclaim -n xxx
如果遇到 问题 Normal FailedBinding 118s (x42 over 12m) persistentvolume-controller no persistent volumes available for this claim and no storage class is set【我上面的不会存在该问题】
创建PV、PVC二者后，如果能够自动绑定，说明NFS系统工作正常。在 PVC 绑定 PV 时通常根据两个条件来绑定，一个是存储的大小，另一个就是访问模式。PVC和PV的绑定，不是简单的通过Label来进行。而是要综合storageClassName，accessModes，matchLabels以及storage来进行绑定。根据PVC和PV绑定原理分析，是PV指定了storageClassName: nfs #存储类名称，PVC里面又没有指定storageClassName导致。
# cat pv.yaml apiVersion: v1 kind: PersistentVolume metadata: name: pv-data #pv的名称 spec: capacity: #容量 storage: 10Gi #pv可用的大小 accessModes: #访问模式 - ReadWriteOnce #PV以read-write挂载到一个节点 persistentVolumeReclaimPolicy: Recycle #持久卷回收策略 storageClassName: nfs #存储类名称 重要：需将来的PVC中定义的一样 nfs: path: /data/pvdata #NFS的路径 server: 172.22.22.215 #NFS的IP地址 ---------------- [root@kubernetes-master ~]# vi pvc.yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: mongo-storage #PVC的名称 如 nginx-log 一般指出用途 spec: accessModes: - ReadWriteOnce #PVC以read-write挂载到一个节点 storageClassName: nfs resources: requests: storage: 10Gi #PVC允许申请的大小 [root@kubernetes-master ~]#
2) nfs挂载报错unmatched host
查看nfs日志
cat /var/log/messages | grep mount
报错
Feb 4 03:19:26 storage1 dockerd: time=“2020-02-04T03:19:26.861842395+08:00” level=warning msg=“Using pre-4.0.0 kernel for overlay2, mount failures may require kernel update” storage-driver=overlay2
Feb 4 03:22:32 storage1 rpc.mountd[960]: refused mount request from 192.168.13.101 for /data/app/share (/data/app/share): unmatched host
三、PV的动态创建
Kubernetes对象之PersistentVolume，StorageClass和PersistentVolumeClaim
参考URL: https://www.jianshu.com/p/99e610067bc8
k8s使用nfs动态存储
参考URL: https://www.cnblogs.com/cuishuai/p/9152277.html
有两种PV提供的方式：静态和动态。
静态
集群管理员创建多个PV，它们携带着真实存储的详细信息，这些存储对于集群用户是可用的。它们存在于Kubernetes API中，并可用于存储使用。
动态
当管理员创建的静态PV都不匹配用户的PVC时，集群可能会尝试专门地供给volume给PVC。这种供给基于StorageClass：PVC必须请求这样一个等级，而管理员必须已经创建和配置过这样一个等级，以备发生这种动态供给的情况。请求等级配置为“”的PVC，有效地禁用了它自身的动态供给功能。
上文中我们通过PersistentVolume描述文件创建了一个PV。这样的创建方式我们成为静态创建。这样的创建方式有一个弊端，那就是假如我们创建PV时指定大小为50G，而PVC请求80G的PV，那么此PVC就无法找到合适的PV来绑定。因此产生了了PV的动态创建。
PV的动态创建依赖于StorageClass对象。我们不需要手动创建任何PV，所有的工作都由StorageClass为我们完成。
一个例子如下：
kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: slow provisioner: kubernetes.io/aws-ebs parameters: type: io1 zones: us-east-1d, us-east-1c iopsPerGB: "10"
这个例子使用AWS提供的插件（ kubernetes.io/aws-ebs）创建了一个基于AWS底层存储的StorageClass。这意味着使用这个StorageClass，那么所有的PV都是AWSElasticBlockStore类型的。
StorageClass的定义包含四个部分：
provisioner：指定 Volume 插件的类型，包括内置插件（如 kubernetes.io/aws-ebs）和外部插件（如 external-storage 提供的 ceph.com/cephfs）。
mountOptions：指定挂载选项，当 PV 不支持指定的选项时会直接失败。比如 NFS 支持 hard 和 nfsvers=4.1 等选项。
parameters：指定 provisioner 的选项，比如 kubernetes.io/aws-ebs 支持 type、zone、iopsPerGB 等参数。
reclaimPolicy：指定回收策略，同 PV 的回收策略。
手动创建的PV时，我们指定了storageClassName=slow的配置项，然后Pod定义中也通过指定storageClassName=slow，从而完成绑定。而通过StorageClass实现动态PV时，我们只需要指定StorageClass的metadata.name。
回到上文中创建PVC的例子，此时PVC指定了storageClassName=slow。那么Kubernetes会在集群中寻找是否存在metadata.name=slow的StorageClass，如果存在，此StorageClass会自动为此PVC创建一个accessModes = ReadWriteOnce，并且大小为8GB的PV。
通过StorageClass的使用，使我们从提前构建静态PV池的工作中解放出来。
参考：
https://www.cnblogs.com/luoahong/p/13570420.html