k8s之持久化存储PV、PVC

最新推荐文章于 2024-04-28 15:17:59 发布

芒地狠

最新推荐文章于 2024-04-28 15:17:59 发布

阅读量816

点赞数 3

文章标签： kubernetes java linux

本文链接：https://blog.csdn.net/m0_71521555/article/details/127804802

版权

3.2 根据上述五个阶段，PV的状态有以下4种

二、基于nfs创建静态PV资源和PVC资源

三、搭建StorageClass + NFS

1、创建集群角色

2、使用 Deployment 来创建 NFS Provisioner

3、创建NFS Provisioner

4、创建 StorageClass

5、创建 PVC 和 Pod 测试

6、查看 NFS 服务器上是否生成对应的目录

7、进入 Pod 在挂载目录 /mnt 下写一个文件，然后查看 NFS 服务器上是否存在该文件

一、PV和PVC

1、PV概念

① PersistentVolume(PV)是集群中由管理员配置的一段网络存储。集群中的资源就像一个节点是一个集群资源，可以从远程的NFS或分布式对象存储系统中创建得来（PV存储空间大小、访问方式）。
② PV是诸如卷之类的卷插件，但是只有独立于使用PV的任何单个pod的生命周期。
③ 该API对象捕获存储的实现细节，即NFS，ISCSI或云提供商特定的存储系统
④ PV就是从存储设备中的空间创建出一个存储资源。

2、PVC概念

① PersistentVolumeClaim（PVC）是用户存储的请求。PVC的使用逻辑：在pod中定义一个存储卷（该存储卷类型为PVC），定义的时候直按指定大小，PVC必须与对应的PV建立关系，PVC会根据定义去PV申请，而PV是由存储空间创建出来的。PV和PVC是kubernetes抽象出来的一直存储资源。
② 虽然PersistentVolumeClaims允许用户使用抽象存储资源，但是常见的需求是，用户需要根据不同的需求去创建PV，用于不同的场景。而此时需要集群管理员提供不同需求的PV，③ 而不仅仅是PV的大小和访问模式，但又不需要用户了解这些卷的实现细节。
对于这样的需求，此时可以采用storageclass资源

3、PV与PVC之间的关系

pv是集群中的资源，PVC是对这些资源的请求，也是对资源的索引检查

3.1 PV和PVC的生命周期

PV和PVC之间的相互作用遵循这个生命周期：

Provisioning（配置）----Binding（绑定）----Using（使用）----Releasing（释放）----Recycling（回收）

① Provisioning：即PV的创建，可以直接创建PV（静态方式），也可以使用StorageClass动态创建
② Binding：将PV分配给PVC
③ Using：Pod通过PVC使用该Volume，并可以通过准入控制StorageProtection（1.9及以前版本为PVCProtection），阻止删除正在使用的PVC
④ Releasing：Pod释放Volume并删除PVC
⑤ Recycling：回收PV，可以保留PV以便下次使用，也可以直接从云存储中删除

3.2 根据上述五个阶段，PV的状态有以下4种

Available（可用）：表示可用状态，还未被任何PVC绑定
Bound（已绑定）：表示PV已经绑定到PVC
Released（已释放）：表示PVC被删掉，但是资源尚未被集群回收
Failed（失败）：表示该PV的自动回收失败

3.3 一个PV从创建到销毁的具体流程

一个PV创建完后状态会变成Available，等待被PVC绑定

一旦被PVC绑定，PV的状态就会变成Bound，就可用被定义了相应PVC的Pod使用。

Pod使用完后会释放PV，PV的状态变成Released。

变成Released的PV会根据定义的回收策略做相应的回收工作。

3.4 三种回收策略

有三种回收策略，Retain、Delete和Recycle。

① Retain就是保留现场，K8S集群什么也不做，等待用户手动去处理PV里的数据，处理完后，再手动删除PV。
② Delete策略，K8S会自动删除该PV及里面的数据。
③ Recycle方式，K8S会讲PV里的数据删除，然后把PV的状态变成Available，又可以被新的PVC绑定使用。

3.5 查看PV、PVC的定义方式、规格

查看PV的定义方式

kubectl explain pv

FIELDS:
   apiVersion: v1
   kind: PersistentVolume
   metadata: #由于 PV 是集群级别的资源，即 PV 可以跨 namespace 使用，所以 PV 的 metadata 中不用配置 namespace
   name:
   spec

spec:
nfs:（定义存储类型）
path:（定义挂载卷路径）
server:（定义服务器名称）
accessModes:（定义访问模型，有以下三种访问模型，以列表的方式存在，也就是说可以定义多个访问模式）
- ReadWriteOnce #（RWO）存储可读可写，但只支持被单个 Pod 挂载
- ReadOnlyMany #（ROX）存储可以以只读的方式被多个 Pod 挂载
- ReadWriteMany #（RWX）存储可以以读写的方式被多个 Pod 共享
#nfs 支持全部三种；iSCSI 不支持 ReadWriteMany（iSCSI 就是在 IP 网络上运行 SCSI 协议的一种网络存储技术）；HostPath 不支持 ReadOnlyMany 和 ReadWriteMany。
capacity:（定义存储能力，一般用于设置存储空间）
storage: 2Gi （指定大小）
storageClassName: （自定义存储类名称，此配置用于绑定具有相同类别的PVC和PV）
persistentVolumeReclaimPolicy: Retain #回收策略（Retain/Delete/Recycle）
#Retain（保留）：当删除与之绑定的PVC时候，这个PV被标记为released（PVC与PV解绑但还没有执行回收策略）且之前的数据依然保存在该PV上，但是该PV不可用，需要手动来处理这些数据并删除该PV。
#Delete（删除）：删除与PV相连的后端存储资源（只有 AWS EBS, GCE PD, Azure Disk 和 Cinder 支持）
#Recycle（回收）：删除数据，效果相当于执行了 rm -rf /thevolume/* （只有 NFS 和 HostPath 支持）

查看PVC的定义方式

kubectl explain pvc

KIND: PersistentVolumeClaim
VERSION: v1
FIELDS:
apiVersion   <string>
kind   <string>
metadata   <Object>
spec   <Object>

PV和PVC的spec关键字段要匹配，比如存储（storage）大小、访问模式（accessModes）、存储类名称（storageClassName）

kubectl explain pvc.spec
spec:
accessModes: （定义访问模式，必须是PV的访问模式的子集）
resources:
requests:
storage: （定义申请资源的大小）
storageClassName: （定义存储类名称，此配置用于绑定具有相同类别的PVC和PV）