ubuntu kubernetes中使用NFS创建pv_pvc

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