kubernetes(k8s)存储方案(PV、PVC)- NFS

一、认识PV/PVC/StorageClass

kubernetes PV和PVC持久卷
参考URL: https://baiyongjie.com/?p=552

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方式挂载到多个节点

二、PV/PVC结合NFS使用实践(持久存储)

1. 安装NFS

  1. 安装NFS
#安装依赖包
yum -y install nfs-utils rpcbind

#创建要存放文件的目录
mkdir -p  /data/app/share
chown -R nfsnobody.nfsnobody /data/app/share


#开机启动,
systemctl enable rpcbind.service 
systemctl enable nfs-server.service
systemctl start rpcbind.service #端口是111
systemctl start nfs-server.service # 端口是 2049 
  1. 修改配置文件
# 将要共享的目录输入到 /etc/exports 配置文件
echo "/data/app/share 0.0.0.0/0(rw,sync,all_squash)" >> /etc/exports

#root_squash:在登入 NFS 主机使用分享之目录的使用者如果是 root 时,那么这个使用者的权限将被压缩成为匿名使用者,通常他的 UID 与 GID 都会变成 nobody 那个系统账号的身份。
#no_root_squash:登入 NFS 主机使用分享目录的使用者,如果是 root 的话,那么对于这个分享的目录来说,他就具有 root 的权限!这个项目『极不安全』,不建议使用!
#all_squash:登入 NFS 主机使用分享目录的使用者,所有用户均被压缩成为匿名使用者,即已nobody用户的身份登录。
#anonuid和anongid:明确指定匿名使用者使用指定的id值用户的权限,访问分享的目录。
#secure:限制客户端只能从小于1024的tcp/ip端口连接nfs服务器(默认设置)。
#insecure:允许客户端从大于1024的tcp/ip端口连接服务器。

  1. 重新加载配置
exportfs -rv

# 查看配置
exportfs

上面是linux搭建nfs过程,这里我们需要测试k8s pv,所以改一下共享目录名,重新共享出去:

mkdir /data/pvdata
chown nfsnobody:nfsnobody /data/pvdata

echo "/data/pvdata  0.0.0.0/0(rw,sync,all_squash)" >> /etc/exports
exportfs -rv
cat /etc/exports
exportfs
# 修改完成后再重启一下nfs
systemctl start rpcbind.service   #端口是111
systemctl start nfs-server.service   # 端口是 2049 
# 查看共享文件
[root@storage1 ~]# showmount -e 127.0.0.1
Export list for 127.0.0.1:
/data/pvdata    0.0.0.0/0
/data/app/share 0.0.0.0/0
[root@storage1 ~]# 

查看挂载相关日志

cat /var/log/messages | grep mount

查看当前client端挂载的配置信息,可以通过如下命令:

$ mount|grep nfs

取消mount挂载:

$ umount /xxx/xxxx(client端的挂载目录)

2. 建立PV

vi pv.yaml 创建yaml文件

# 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 pv.yaml
[root@kubernetes-master ~]# kubectl apply -f pv.yaml 
persistentvolume/pv-data created
[root@kubernetes-master ~]# kubectl get pv
NAME      CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
pv-data   10Gi       RWO            Recycle          Available           nfs                     10s
[root@kubernetes-master ~]# 

3. 建立PVC

在使用 PVC 之前,我们还得把其他节点上的 nfs 客户端给安装上,使用kubectl get nodes查看所有节点

kubectl get nodes
yum -y install  nfs-utils rpcbind

vi pvc.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-nfs  #PVC的名称
spec:
  accessModes:
    - ReadWriteOnce #PVC以read-write挂载到一个节点
  resources:
    requests:
      storage: 10Gi #PVC允许申请的大小
# kubectl apply  -f pvc.yaml 
persistentvolumeclaim/pvdata created

# kubectl get pvc
NAME        STATUS   VOLUME    CAPACITY   ACCESS MODES   STORAGECLASS   AGE
nginx-log   Bound    pv-data   10Gi       RWO                           18m

经过测试,发现在k8s,PVC 也是namespace隔离的。这里没有指定,就是默认的namespace。pvc是命名空间隔离的,pv可以全局共享,不用指定命名空间。

pv是全局的,pvc可以指定namespace,在如下位置加入 namespace

metadata:
  name: pvc-nfs  #PVC的名称
  namespace: mongo

4. 过程问题整理

1) pvc一直处于Pending状态

[root@kubernetes-master ~]# kubectl get pvc
NAME            STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
mongo-storage   Pending   

使用命令查看详细信息

[root@kubernetes-master ~]# kubectl get pvc
NAME            STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
mongo-storage   Pending                                                     10m
[root@kubernetes-master ~]#  kubectl describe pvc mongo-storage
Name:          mongo-storage
Namespace:     default
StorageClass:  
Status:        Pending
Volume:        
Labels:        <none>
Annotations:   kubectl.kubernetes.io/last-applied-configuration:
                 {"apiVersion":"v1","kind":"PersistentVolumeClaim","metadata":{"annotations":{},"name":"mongo-storage","namespace":"default"},"spec":{"acce...
Finalizers:    [kubernetes.io/pvc-protection]
Capacity:      
Access Modes:  
VolumeMode:    Filesystem
Mounted By:    <none>
Events:
  Type    Reason         Age                  From                         Message
  ----    ------         ----                 ----                         -------
  Normal  FailedBinding  118s (x42 over 12m)  persistentvolume-controller  no persistent volumes available for this claim and no storage class is set
[root@kubernetes-master ~]# 

原因分析:
理论上,根据网上信息
并没有在 pvc-nfs 中指定关于 pv 的什么标志,它们之间是怎么就关联起来了的呢?
解答:其实这是系统自动帮我们去匹配的,它会根据我们的声明要求去查找处于 Available 状态的 PV,如果没有找到的话那么PVC 就会一直处于 Pending 状态,找到了的话当然就会把当前的 PVC 和目标 PV 进行绑定,这个时候状态就会变成 Bound 状态了。

根据网上描述:
创建PV、PVC二者后,如果能够自动绑定,说明NFS系统工作正常。在 PVC 绑定 PV 时通常根据两个条件来绑定,一个是存储的大小,另一个就是访问模式。

这里我一直是Pending。

k8s 如何关联pvc到特定的pv?
参考URL: https://www.jianshu.com/p/99e610067bc8

通过上面参考URL的分析,我们可以看到PVC和PV的绑定,不是简单的通过Label来进行。而是要综合storageClassName,accessModes,matchLabels以及storage来进行绑定。

根据PVC和PV绑定原理分析,我这里是PV指定了storageClassName: nfs #存储类名称,PVC里面又没有指定storageClassName导致。

因此,

[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 ~]# 

先删除刚才没有绑定的pvc,在用新yaml生成新的pvc,命令如下:

[root@kubernetes-master ~]# kubectl get pvc
NAME            STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
mongo-storage   Pending                                                     76m
[root@kubernetes-master ~]# kubectl delete pvc mongo-storage
persistentvolumeclaim "mongo-storage" deleted
[root@kubernetes-master ~]# kubectl apply  -f pvc.yaml 
persistentvolumeclaim/mongo-storage created
[root@kubernetes-master ~]# kubectl get pvc
NAME            STATUS   VOLUME    CAPACITY   ACCESS MODES   STORAGECLASS   AGE
mongo-storage   Bound    pv-data   10Gi       RWO            nfs            2s
[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池的工作中解放出来。

参考

Linux安装配置NFS方法
https://jingyan.baidu.com/article/e5c39bf5f3a8df39d660335e.html

已标记关键词 清除标记
相关推荐
©️2020 CSDN 皮肤主题: 编程工作室 设计师:CSDN官方博客 返回首页
实付 29.90元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值