k8s——pv(静态+动态storageclass)与pvc

本文介绍了Kubernetes中PersistentVolume(PV)和PersistentVolumeClaim(PVC)的概念及其关系,详细阐述了如何基于NFS创建静态PV资源和PVC资源,以及如何利用动态StorageClass创建PV和PVC。通过示例展示了PV与PVC的生命周期,以及StorageClass在解决PVC匹配PV需求中的作用。

PVC和PV

PV概念

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

PVC概念

  1. PersistentVolumeClaim (Pvc)是用户存储的请求。Pvc的使用逻辑:在podt中定义一个存储卷(该存储卷类型为pvc),定义的时候直按指定大小,pvc必须与对应的pv建立关系,pvc会根据定义去pv申请,而pv是由存储空间创建出来的。pr和pvc是kubernetes抽象出来的一种存储资源
  2. 虽然PersistentVolumeClaims允许用户使用抽象存储资源,但是常见的需求是,用户需要根据不同的需求去创建v,用于不同的场景。而此时需要集群管理员提供不同需求的Pv,而不仅仅是Pv的大小和访问模式,但又不需要用户了解这些卷的实现细节
  3. 对于这样的需求,此时可以采用storageclass资源

PV与PVC之间的关系

PVv是集群中的资源。Pvc是对这些资源的请求,也是对资源的索引检查。PV和Pvc之间的相互作用遵循这个生命周期:Provisioning(配置)—> Binding(绑定)—>Using(使用)—>Releasing(释放)—>Recycling(回收)

两种PV的提供方式

1.这里有两种PV的提供方式:静态或者动态
2.静态-->直接固定存储空间:
集群管理员创建一些PV。它们携带可供集群用户使用的真实存储的详细信息。它们存在于Ktbernetes API中,可用于消费
3.动态-->通过存储类进行动态创建存储空间:
当管理员创建的静态PV都不匹配用户的 PvC时,集群可能会尝试动态地为 Pvc配置卷。此配置基于StorageClasses: PvC必须请求存储类,并且管理员必须已创建并配置该类才能进行动态配置。要求该类的声明有效地为自己禁用动态配置

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

img

配置nfs存储(192.168.80.14)

1.mkdir -p /data/v{
   
   1..5}
chmod 777 -R /data/*

2.vim /etc/exports
/data/v1 192.168.10.0/24(rw,no_root_squash,sync)
/data/v2 192.168.10.0/24(rw,no_root_squash,sync)
/data/v3 192.168.10.0/24(rw,no_root_squash,sync)
/data/v4 192.168.10.0/24(rw,no_root_squash,sync)
/data/v5 192.168.10.0/24(rw,no_root_squash,sync)

3.systemctl start rpcbind
  systemctl start nfs

4.showmount -e

5.hostnamectl set-hostname nfs01
su

6.echo '11111' > /data/v1/index.html
echo '22222' > /data/v2/index.html
echo '33333' > /data/v3/index.html
echo '44444' > /data/v4/index.html
echo '55555' > /data/v5/index.html

img
img

k8s的master节点定义PV

//这里定义5个Pv,并且定义挂载的路径以及访问模式,还有pv划分的大小
vim pv-demo.yaml
==========================================================
apiVersion: v1
kind
<think>好的,我现在需要解释Kubernetes中的PVCPVStorageClass之间的区别。首先,我应该回忆这些概念的基本定义和作用,然后找出它们的联系和不同之处。 用户可能已经对Kubernetes的存储管理有初步了解,但需要更清晰的区分。我需要确保每个概念都被正确解释,并且它们之间的关系明确。 首先,PV(Persistent Volume)是集群中的存储资源,由管理员预先配置,或者通过StorageClass动态供应。它独立于Pod的生命周期,可以被多个Pod挂载。PV的配置包括存储容量、访问模式等细节。 然后是PVC(Persistent Volume Claim),这是用户对存储资源的请求。用户通过PVC声明需要的存储大小和访问模式,Kubernetes会根据PVC的要求找到合适的PV进行绑定。PVC使得用户不需要关心底层存储的具体实现,只需要提出需求即可。 接下来是StorageClass,它用于定义动态供应的存储类型。StorageClass允许管理员描述他们提供的存储类型,不同的StorageClass可以对应不同的存储后端(如AWS EBS、GCE PD等)或者不同的参数配置(如性能等级)。当用户创建PVC时,如果指定了StorageClass,Kubernetes会自动创建对应的PV,无需手动预先配置。 现在需要明确这三者的区别。PV是实际的存储资源,PVC是用户对存储的请求,而StorageClass动态生成PV的模板。PVPVC之间是一对一绑定的关系,而StorageClass使得PVC可以按需动态创建PV,无需手动管理。 可能需要用比喻来帮助理解,比如将PV比作硬盘,PVC是申请硬盘的请求单,StorageClass则是自动化生产硬盘的工厂,根据需求自动生成合适的硬盘。 还要注意它们的生命周期。PV可以是静态的(预先配置好)或动态的(通过StorageClass创建)。PVC一旦被创建,就会寻找合适的PV绑定,绑定后除非释放,否则不能被其他PVC使用。删除PVC时,对应的动态PV可能会被回收,具体取决于回收策略。 需要检查是否有遗漏的关键点,比如访问模式、回收策略、绑定过程等。确保术语准确,比如StorageClass中的provisioner字段指定了存储插件,不同的存储后端需要不同的provisioner。 最后,总结三者之间的关系:用户创建PVC,指定所需的StorageClass,Kubernetes根据StorageClass动态创建PV,并将PVCPV绑定,供Pod使用。这样实现了存储的抽象和动态管理,简化了用户的存储配置工作。</think>在 Kubernetes 中,PVCPVStorageClass 是管理存储资源的三个核心概念,它们的关系如同 **订单、商品、商品工厂** 的协作流程: --- ### 一、核心概念比喻 | 概念 | 比喻 | 特点 | |----------------|--------------------------|----------------------------------------------------------------------| | **PV** | 现成的商品(如硬盘) | 预先准备好的存储资源,有明确的容量/性能参数,需要手动创建 | | **PVC** | 用户下单(商品需求单) | 用户声明需要的存储规格(容量/访问方式),系统自动匹配或生产商品 | | **StorageClass** | 商品工厂(自动化生产线) | 定义如何按需生产商品(PV),支持不同生产线(AWS EBS、NFS 等) | --- ### 二、详细区别对照表 | | PV (Persistent Volume) | PVC (Persistent Volume Claim) | StorageClass | |------------------|-------------------------------------------------|-------------------------------------------------|---------------------------------------| | **定位** | 存储资源实体 | 存储资源申请单 | 存储资源生产模板 | | **创建者** | 管理员手动创建 / StorageClass 自动创建 | 用户/开发者创建 | 管理员预先配置 | | **生命周期** | 独立于 Pod(可长期存在) | 跟随应用部署( Pod 同生命周期) | 长期存在(存储策略模板) | | **绑定关系** | PVC 一对一绑定 | 通过 StorageClass 动态匹配 PV | 定义 PV 的生产规则 | | **核心配置参数** | 容量、访问模式、存储类型、回收策略 | 容量、访问模式、StorageClass 名称 | 供应商类型、Provisioner、回收策略等 | | **典型使用场景** | 静态供应(预先准备存储资源) | 动态供应(按需自动创建存储资源) | 标准化存储资源配置(如区分SSD/HDD) | --- ### 三、工作流程示例 假设要部署一个需要 10GB 存储的 MySQL 数据库: 1. **静态供应场景**(传统方式): - 管理员预先创建好一个 10GB 的 PV(如 NFS 存储卷) - 用户创建 PVC 申请 10GB 存储,Kubernetes 自动将 PVC PV 绑定 - Pod 挂载 PVC 使用存储 2. **动态供应场景**(现代主流方式): - 用户创建 PVC 并指定 StorageClass `ssd-storage` - Kubernetes 根据 `ssd-storage` 的配置(如 AWS EBS 类型),自动创建 PV 并绑定 PVC - Pod 挂载 PVC 直接使用新创建的存储卷 --- ### 四、关键联动特性 - **自动绑定**:PVC 会根据 `.spec.storageClassName` 找到匹配的 StorageClass动态生成 PV - **生命周期解耦**:PV 的删除/保留策略(`persistentVolumeReclaimPolicy`)决定 PVC 释放后是否保留数据 - **多层级抽象**: ```bash Pod --> PVC (申明需求) --> StorageClass (生产规则) --> 实际存储系统(如云盘、NAS) ``` --- ### 五、实际 YAML 片段对比 **PV(手动静态创建)**: ```yaml apiVersion: v1 kind: PersistentVolume metadata: name: manual-pv spec: capacity: { storage: 10Gi } accessModes: [ ReadWriteOnce ] nfs: # 实际存储类型 server: 192.168.1.100 path: "/data" ``` **PVC动态请求存储)**: ```yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: mysql-pvc spec: storageClassName: "ssd-storage" # 指向 StorageClass accessModes: [ ReadWriteOnce ] resources: requests: { storage: 10Gi } ``` **StorageClass(定义生产规则)**: ```yaml apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: ssd-storage provisioner: kubernetes.io/aws-ebs # 指定供应商插件 parameters: type: gp2 # AWS EBS 类型为通用型SSD reclaimPolicy: Retain # PVC删除后保留数据 ``` --- ### 六、总结选择建议 - **需要固定存储卷** ➜ 使用静态 PV + PVC(适合传统存储) - **按需动态创建存储** ➜ PVC + StorageClass(云环境首选) - **统一管理存储策略** ➜ 为不同场景(开发/生产)定义多个 StorageClass
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值