K8s PV和PVC(静态)

k8s存储卷直接使用问题

  • 配置信息透明化,存在安全隐患
  • 存储定义信息对于用户角度来说复杂且没有必要,用户对于存储就是使用即可

PV和PVC
为了实现用户和集群管理员的解耦,添加了一个抽象层(也就是由管理员配置好,用户直接绑定使用)PV和PVC是一对一的关系

  • PV(Persistent Volume):定义存储资源持久化,由管理员配置的关于存储类型的相关信息
  • PVC(Persistent Volume Claim):定义PV绑定,PVC可以根据PV定义的容量、匹配模式进行绑定

Pod根据PVCname名称进行挂载

在这里插入图片描述
创建PV
主要还是理解spec定义字段解释

命令查看:kubectl explain PersistentVolume.spec

通用字段

  • capacity:定义PV容量
  • accessModes:访问模式,需要根据底层存储设备的支持选择(看下图)
    • ReadWriteOnce:可以被一个节点以读写方式挂载(命令查询显示:RWO)
    • ReadOnlyMany:可以被多个节点以只读方式挂载(命令查询显示:ROM)
    • ReadWriteMany:可以被多个节点以读写方式挂载(命令查询显示:RWM)

每个卷只能同一时刻只能以一种访问模式挂载,即使该卷能够支持 多种访问模式

在这里插入图片描述

  • persistentVolumeReclaimPolicy:存储卷回收机制(PVC 释放卷的时候 PV 该如何操作)
    • Retain:手动回收(默认)
    • Recycle:基本擦除 (rm -rf /thevolume/*),也就是删除目录(只有 NFS 和 HostPath 支持)
    • Delete:删除存储卷,诸如 AWS EBS、GCE PD、Azure Disk 或 OpenStack Cinder
      卷这类关联存储资产也被删除
  • volumeMode:指定使用文件系统(Filesystem)还是块设备,默认为文件系统
  • storageClassName:PV动态供给的类名称,后面单独讲解
  • mountOptions:也就是mount -o选项参数(hard、ro、soft等等),mount -t nfs -o hard 192.168.0.10:/nfs /nfs

回收机制删除pvc情况

  • Retain:删除pvc后,pv状态为Released,pv无法被pvc进行绑定,除了原有的pvc
    • 再次被使用需要删除pv,清理数据,如果基于存储卷就要删除,重新创建(比如RBD系统上的image)
  • Recycle:数据自动被清除,pv可以再次被绑定
  • Delete:pvc被删除pv也会被移除,同样还有数据,动态PV供给默认就是delete,大多数情况下针对数据安全考虑需要更改策略
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv1
spec:
  capacity:
    storage: 1Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Recycle
  mountOptions:
    - hard
    - nfsvers=4.1
  nfs:
    path: /nfs_share
    server: 192.168.12.10
    

查看pv是可用状态,还没有被绑定
在这里插入图片描述
创建PVC
PVC绑定一般都是基于访问模式和容量进行绑定

命令查看:kubectl explain PersistentVolumeClaim.spec

扫描二维码关注公众号,回复: 12785456 查看本文章
  • accessModes:访问模式与PV相同
  • resources:PVC存储卷需要申请的容量
  • selector:绑定时进一步过滤,只有标签与选择算符相匹配的卷能够绑定到申领上(分2种)
    • matchLabels:常见的标签匹配
    • matchExpressions:匹配标签表达式

如果指定2种,关系是与,同时满足2个

  • storageClassName:PV定义存储类,加上类才能实现动态供给,后面单独讲解
  • volumeName:直接通过PV名称匹配
  • volumeMode:指定使用文件系统(Filesystem)还是块设备,默认为文件系统

存在相同的参数,PV代表是Pod,而pvc代表的是容器,PV定义了也就是后面的pvc就无效了

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: myclaim
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 1Gi

查看pv和pvc,状态已经变成绑定,clatm默认为default命名空间
在这里插入图片描述

PV不属于任何的命名空间而PVC需要归属到命名空间上,默认不写为default

查看容器
在这里插入图片描述
注意大小还是本身nfs的容量

疑惑
之前考虑以为PV类似openstack的cinder功能,这样看下来其实不是,pv无法像cinder管理后端存储,所以capacity字段并不是定义容量大小限制,这块我理解错了,我以为PV会帮我创建一个1G的容量给容器

pvc删除(我的回收策略是Recycle)

kubectl delete  pvc  myclaim

在这里插入图片描述查看PV状态Released,不是可用状态,这个其实是要等一会时间的,自动会变成Available

在这里插入图片描述
在这里插入图片描述
修改一下pvc的名称加了个1。再次绑定,状态为Pending,describe查看错误信息

再状态还不行Available下再次绑定是会失败的

在这里插入图片描述等一会时间pv状态正常后,再次绑定就成功了(符合Recycle回收策略)

在这里插入图片描述在这里插入图片描述nfs的原有的文件已经被删除,因为我的回收策略是Recycle

参考:https://kubernetes.io/zh/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims
参考:书籍-kubernetes进阶实战-马永亮

猜你喜欢

转载自blog.csdn.net/yangshihuz/article/details/113061088