k8sk8s存储之持久卷(pv)持久卷声明(pvc)nfs持久化存储示例
Posted dezasseis
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了k8sk8s存储之持久卷(pv)持久卷声明(pvc)nfs持久化存储示例相关的知识,希望对你有一定的参考价值。
一、pv与pvc
01_区别
-
持久卷(PersistentVolume,PV)是集群中的一块存储,可以由管理员事先供应,或者 使用存储类(Storage
Class)来动态供应。 持久卷是集群资源,就像节点也是集群资源一样。PV 持久卷和普通的 Volume 一样,也是使用
卷插件来实现的,只是它们拥有独立于任何使用 PV 的 Pod 的生命周期。 此 API 对象中记述了存储的实现细节,无论其背后是NFS、iSCSI 还是特定于云平台的存储系统。 -
持久卷声明(PersistentVolumeClaim,PVC)表达的是用户对存储的请求。概念上与 Pod 类似。 Pod
会耗用节点资源,而 PVC 申领会耗用 PV 资源。Pod 可以请求特定数量的资源(CPU 和内存);同样 PVC
申领也可以请求特定的大小和访问模式 (例如,可以要求 PV 卷能够以 ReadWriteOnce、ReadOnlyMany 或
ReadWriteMany 模式之一来挂载,参见访问模式)。
02_声明周期
PV 卷是集群中的资源。PVC 声明是对这些资源的请求,也被用来执行对资源的申领检查。
pv卷的提供方式:
- 静态:集群管理员创建若干 PV 卷。这些卷对象带有真实存储的细节信息,并且对集群 用户可用(可见)。PV 卷对象存在于Kubernetes API 中,可供用户消费(使用)
- 动态:当管理员创建的静态PV都不匹配用户的PVC时,集群可能会尝试专门地供给volume给PVC。这种供给基于StorageClass
绑定:
- PVC与PV的绑定是一对一的映射。没找到匹配的PV,那么PVC会无限期得处于unbound未绑定状态。
使用:
- Pod使用PVC就像使用volume一样。集群检查PVC,查找绑定的PV,并映射PV给Pod。对于支持多种访问模式的PV,用户可以指定想用的模式。一旦用户拥有了一个PVC,并且PVC被绑定,那么只要用户还需要,PV就一直属于这个用户。用户调度Pod,通过在Pod的volume块中包含PVC来访问PV。
释放:
- 当用户使用PV完毕后,他们可以通过API来删除PVC对象。当PVC被删除后,对应的PV就被认为是已经是“released"
了,但还不能再给另外一个PVC使用。 前一个PVC的属于还存在于该PV中,必须根据策略来处理掉。
回收:
- PV的回收策略告诉集群,在PV被释放之后集群应该如何处理该PV。当前,PV可以被Retained (保留) 、Recycled
(再利用)或者Deleted(删除)。保留允许手动地再次声明资源。对于支持删除操作的PV卷,删除操作会从Kubemetes中移除PV对象,还有对应的外部存储(如AWS、EBS,GCE PD,Azure Disk,或者 Cinder volume)。动态供给的卷总是会被删除。
二、pv持久卷
每个 PV 对象都包含:
- spec :卷的规约
- status :卷的状态。
01_容量 capacity
- 一般而言,每个 PV 卷都有确定的
存储容量
。 容量属性是使用 PV 对象的 capacity 属性来设置的。 - 目前,存储大小是可以设置和请求的唯一资源。 未来可能会包含 IOPS、吞吐量等属性。
02 卷模式 volumeModes
针对 PV 持久卷,Kuberneretes 支持两种卷模式(volumeModes):
- Filesystem(文件系统) (默认):volumeMode 属性设置为 Filesystem 的卷会被 Pod 挂载(Mount)
到某个目录。 如果卷的存储来自某块设备而该设备目前为空,Kuberneretes 会在第一次挂载卷之前 在设备上创建文件系统。 - Block(块):可以将 volumeMode 设置为 Block,以便将卷作为原始块设备来使用。 这类卷以块设备的方式交给 Pod使用,其上没有任何文件系统。 这种模式对于为 Pod 提供一种使用最快可能方式来访问卷而言很有帮助,Pod 和卷之间不存在文件系统层。另外,Pod 中运行的应用必须知道如何处理原始块设备。
03_访问模式 accessModes
PersistentVolume 卷可以用资源提供者所支持的任何方式挂载到宿主系统上。 如下表所示,提供者(驱动)的能力不同,每个 PV 卷的访问模式都会设置为 对应卷所支持的模式值。 例如,NFS 可以支持多个读写客户,但是某个特定的 NFS PV 卷可能在服务器 上以只读的方式导出。每个 PV 卷都会获得自身的访问模式集合,描述的是 特定 PV 卷的能力。
访问模式有:
- ReadWriteOnce -该volume只能被单个节点以读写的方式映射
- ReadOnlyMany --该volume可以被多个节点以只读方式映射
- ReadWriteMany -该volume可以被多个节点以读写的方式映射
在命令行中,访问模式可以简写为:
- RWO - ReadWriteOnce
- ROX - ReadOnlyMany
- RWX - ReadWriteMany
04 _类 storageClassName
每个 PV 可以属于某个类(Class),通过将其 storageClassName 属性设置为某个 StorageClass 的名称来指定。 特定类的 PV 卷只能绑定到请求该类存储卷的 PVC 申领。 未设置 storageClassName 的 PV 卷没有类设定,只能绑定到那些没有指定特定 存储类的 PVC 申领。
05_回收策略
persistentVolumeReclaimPolicy
- Retain:保留,需要手动回收
- Recycle:回收,自动删除卷中敬据
- Delete:删除,相关联的存储资产,如AWS EBS, GCE PD, Azure Disk, or OpenStack Cinder卷都会被删除
当前,只有 NFS 和 HostPath 支持回收利用,AWS EBS, GCE PD, Azure Disk 和 OpenStack Cinder卷支持删除(Delete)操作。
06_状态
- Available(可用):空闲的资源,尚未绑定给PVC
- Bound(已绑定):绑定给了某个PVC
- Released(已释放):PVC已经删除了,但是PV资源尚未被集群回收
- Failed(失败):卷的自动回收操作失败
命令行可以显示PV绑定的PVC名称。
三、 pvc持久卷声明
每个 PV 对象都包含:
- spec :卷的规约
- status :卷的状态。
访问模式 (accessModes)
- 申领在请求具有特定访问模式的存储时,使用与卷相同的访问模式约定。
卷模式 (volumeModes)
- 申领使用与卷相同的约定来表明是将卷作为文件系统还是块设备来使用。
资源 (resources)
- 申领和 Pod 一样,也可以请求特定数量的资源。在这个上下文中,请求的资源是存储。 卷和申领都使用相同的 资源模型
四、nfs持久化存储示例
- 在nfs服务器建立目录 /nfsdata/pv1、/nfsdata/pv2、/nfsdata/pv3,并写入测试页
- 创建pv
pv1:5Gi,RWO模式,Recycle模式,/nfsdata/pv1
pv2:10Gi,RWM模式,Recycle模式,/nfsdata/pv2
pv3:20Gi,ROM模式,Recycle模式,/nfsdata/pv3
vim pv.yml
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv1
spec:
capacity: # 容量
storage: 5Gi
volumeMode: Filesystem # 卷模式
accessModes: # 访问模式
- ReadWriteOnce
persistentVolumeReclaimPolicy: Recycle #回收策略
storageClassName: nfs #类
nfs: # nfs服务器
path: /nfsdata/pv1 # 挂载位置
server: 172.25.2.1 #服务器地址
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv2
spec:
capacity:
storage: 10Gi
volumeMode: Filesystem
accessModes:
- ReadWriteMany
persistentVolumeReclaimPolicy: Recycle
storageClassName: nfs
nfs:
path: /nfsdata/pv2
server: 172.25.2.1
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv3
spec:
capacity:
storage: 20Gi
volumeMode: Filesystem
accessModes:
- ReadOnlyMany
persistentVolumeReclaimPolicy: Recycle
storageClassName: nfs
nfs:
path: /nfsdata/pv3
server: 172.25.2.1
- 创建pvc
pvc1:5Gi,RWO(pvc1满足pv1的条件)
pvc2:10Gi,RWM(pvc2满足pv2的条件)
vim pvc.yml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc1
spec:
storageClassName: nfs
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc2
spec:
storageClassName: nfs
accessModes:
- ReadWriteMany
resources:
requests:
storage: 10Gi
- 创建pod:在容器挂载的node节点宿主机一定要安装 nfs-utils
test-pd-1:挂载pvc1
test-pd-2:挂载pvc2
vim test-pd.yml
apiVersion: v1
kind: Pod
metadata:
name: test-pd-1
spec:
containers:
- image: myapp:v1
name: nginx
volumeMounts:
- mountPath: /usr/share/nginx/html
name: nfs-pv-1
volumes:
- name: nfs-pv-1
persistentVolumeClaim:
claimName: pvc1
---
apiVersion: v1
kind: Pod
metadata:
name: test-pd-2
spec:
containers:
- image: myapp:v1
name: nginx
volumeMounts:
- mountPath: /usr/share/nginx/html
name: nfs-pv-2
volumes:
- name: nfs-pv-2
persistentVolumeClaim:
claimName: pvc2
- 测试成功!数据共享成功!
- 删除pvc,发现pv的状态变为已释放,过一会会后,资源被回收变为可利用(Available)
以上是关于k8sk8s存储之持久卷(pv)持久卷声明(pvc)nfs持久化存储示例的主要内容,如果未能解决你的问题,请参考以下文章