持久存储卷(Persistent Volume,PV)
PV 是k8s管理员定义的好的物理存储或者说实际存储,对应用来说是透明的,应用只需要向着PVC申请即可,具体使用的创建好的那个PV是由PVC去匹配和绑定的。
- PV是集群中的定义的一块存储所以没有namespace限制
持久卷的类型
PV 持久卷是用插件的形式来实现的。Kubernetes 目前支持以下插件:
- csi – 容器存储接口 (CSI)
fc
– Fibre Channel (FC) 存储hostPath
– HostPath 卷 (仅供单节点测试使用;不适用于多节点集群;请尝试使用local
卷作为替代)iscsi
– iSCSI (SCSI over IP) 存储local
– 节点上挂载的本地存储设备nfs
– 网络文件系统 (NFS) 存储
访问模式
ReadWriteOnce
(RWO)卷可以被一个节点以读写方式挂载。 ReadWriteOnce 访问模式也允许运行在同一节点上的多个 Pod 访问卷。
ReadOnlyMany
(ROX)卷可以被多个节点以只读方式挂载。
ReadWriteMany
(RWX)卷可以被多个节点以读写方式挂载。
ReadWriteOncePod
(RWOP)特性状态: Kubernetes v1.27 [beta]
卷可以被单个 Pod 以读写方式挂载。 如果你想确保整个集群中只有一个 Pod 可以读取或写入该 PVC, 请使用 ReadWriteOncePod 访问模式。这只支持 CSI 卷以及需要 Kubernetes 1.22 以上版本。
回收策略
设置参数:
spec.persistentVolumeReclaimPolicy
目前的回收策略有:
- Retain – 手动回收
- Recycle – 简单擦除 (
rm -rf /thevolume/*
) - Delete – 删除关联存储资产
对于 Kubernetes 1.29 来说,只有 nfs
和 hostPath
卷类型支持回收(Recycle)
生命周期
每个持久卷会处于以下阶段(Phase)之一:
Available
卷是一个空闲资源,尚未绑定到任何申领
Bound
该卷已经绑定到某申领
Released
所绑定的申领已被删除,但是关联存储资源尚未被集群回收
Failed
卷的自动回收操作失败
kubectl describe persistentvolume <name>
查看已绑定到 PV 的 PVC 的名称
定义PV
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv0003
spec:
capacity:
storage: 5Gi
volumeMode: Filesystem
#指定访问模式
accessModes:
- ReadWriteOnce
#指定回收策略
persistentVolumeReclaimPolicy: Recycle
storageClassName: slow
mountOptions:
- hard
- nfsvers=4.1
nfs:
path: /tmp
server: 172.17.0.2
持久存储卷声明(Persistent Volume Claim,PVC)
PVC 存在namespace限制
PVC 和PV的关系是一对一的,
PVC配置PV时候主要是根据两个方面第一就是容量storage,第二个就是accessModes(访问模式),
PVC 是对**应用**使用的,表达的是用户对存储的请求,当程序或者应用需要使用持久化存储的时候,
-
需要事先在应用同名称空间定义一个PVC,
-
在yaml的容器中定义需要挂载的mounts
-
将在应用的yaml文件中定义mounts 指定到创建的pvc中
PVC 定义的对象
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: block-pvc
spec:
#指定访问模式
accessModes:
- ReadWriteOnce
#卷模式 Filesystem/Block
volumeMode: Filesystem
resources:
requests:
storage: 10Gi
使用PVC
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- name: myfrontend
image: nginx
volumeMounts:
- mountPath: "/var/www/html"
name: mypd
volumes:
- name: mypd
persistentVolumeClaim:
claimName: myclaim
StorageClass (动态制备卷)
每个 StorageClass 都包含 provisioner
、parameters
和 reclaimPolicy
字段, 这些字段会在 StorageClass 需要动态制备 PersistentVolume 时会使用到。
定义StorageClass
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: low-latency
annotations:
#是否是默认Class,一个集群只有一个DefaultClass
storageclass.kubernetes.io/is-default-class: "false"
#指定制备器
provisioner: csi-driver.example-vendor.example
#指定回收策略
reclaimPolicy: Retain # default value is Delete
allowVolumeExpansion: true
mountOptions:
- discard # this might enable UNMAP / TRIM at the block storage layer
#default Immediate ,WaitForFirstConsumer
volumeBindingMode: WaitForFirstConsumer
parameters:
guaranteedReadWriteLatency: "true" # provider-specific
volumeBindingMode
volumeBindingMode
字段控制了卷绑定和动态制备应该发生在什么时候。 当未设置时,默认使用 Immediate
模式。
Immediate
模式表示一旦创建了 PersistentVolumeClaim 也就完成了卷绑定和动态制备。 对于由于拓扑限制而非集群所有节点可达的存储后端,PersistentVolume 会在不知道 Pod 调度要求的情况下绑定或者制备。
集群管理员可以通过指定 WaitForFirstConsumer
模式来解决此问题。 该模式将延迟 PersistentVolume 的绑定和制备,直到使用该 PersistentVolumeClaim 的 Pod 被创建。 PersistentVolume 会根据 Pod 调度约束指定的拓扑来选择或制备。 这些包括但不限于资源需求、 节点筛选器、 Pod 亲和性和互斥性、 以及污点和容忍度。
制备器(Provisioner)
Kubernetes 建议使用 CephFS CSI 第三方存储驱动插件。
Container Storage Interface是由来自Kubernetes、Mesos、Docker等社区member联合制定的一个行业标准接口规范,旨在将任意存储系统暴露给容器化应用程序。
CSI规范定义了存储提供商实现CSI兼容的Volume Plugin的最小操作集和部署建议。CSI规范的主要焦点是声明Volume Plugin必须实现的接口。
指定Provisoner 动态制备PV,除了使用k8s内置的制备以外还可使用外置的制备器如NFS
卷插件 | 内置制备器 | 配置示例 |
---|---|---|
AzureFile | ✓ | Azure File |
CephFS | – | – |
FC | – | – |
FlexVolume | – | – |
iSCSI | – | – |
NFS | – | NFS |
RBD | ✓ | Ceph RBD |
VsphereVolume | ✓ | vSphere |
PortworxVolume | ✓ | Portworx Volume |
原文地址:https://blog.csdn.net/luojiqiangtyj/article/details/135978850
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。
如若转载,请注明出处:http://www.7code.cn/show_65243.html
如若内容造成侵权/违法违规/事实不符,请联系代码007邮箱:suwngjj01@126.com进行投诉反馈,一经查实,立即删除!