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
- 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进阶实战-马永亮