K8S中PV和PVC之间的关系

Persistent Volume (PV) 和 Persistent Volume Claim (PVC) 是 Kubernetes 中管理存储的焦点抽象概念，二者的关系可以类比为 存储资源提供方 和 存储资源斲丧方。以下是具体表明：
焦点关系

对象脚色生命周期利用者Persistent Volume (PV)存储资源的实体（如 NFS、云磁盘、当地磁盘等）独立于 Pod 和 PVC，需手动或动态创建由集群管理员设置Persistent Volume Claim (PVC)用户对存储资源的哀求（声明须要的存储特性）与 Pod 绑定，由用户创建和烧毁开发者或应用运维职员

---

交互流程

•         管理员创建 PV
  
  
  
  •                 界说存储资源的容量、访问模式（如 ReadWriteOnce）、存储范例等。
    
  •                 示例 PV 设置（静态供应）：
           
    2. apiVersion: v1
    3. kind: PersistentVolume
    4. metadata:
    5.   name: my-pv
    6. spec:
    7.   capacity:
    8.    storage: 10Gi
    9.   accessModes:
    10.    - ReadWriteOnce
    11.   persistentVolumeReclaimPolicy: Retain  # 回收策略（Retain/Delete/Recycle）
    12.   storageClassName: manual              # 关联的 StorageClass
    13.   hostPath:
    14.    path: /data                         # 使用本地存储（仅示例）

    复制代码
           
    
         
  
•         用户创建 PVC
  
  
  
  •                 声明须要的存储容量、访问模式、存储类（StorageClass）。
    
  •                 示例 PVC 设置：
           
    2. apiVersion: v1
    3. kind: PersistentVolumeClaim
    4. metadata:
    5.   name: my-pvc
    6. spec:
    7.   storageClassName: manual
    8.   accessModes:
    9.    - ReadWriteOnce
    10.   resources:
    11.    requests:
    12.      storage: 5Gi

    复制代码
           
    
         
  
•         Kubernetes 绑定 PV 和 PVC
  
  
  
  •                 体系根据 PVC 的哀求（容量、访问模式、StorageClass）匹配可用 PV。
    
  •                 若匹配乐成，PVC 进入 Bound 状态，与 PV 创建一对一绑定。
    
  •                 若没有可用 PV，且启用了动态供应（通过 StorageClass），则会自动创建新 PV。
    
         
  
•         Pod 挂载 PVC
  
  
  
  •                 在 Pod 中通过 volumes 字段引用 PVC：
           
    2. apiVersion: v1
    3. kind: Pod
    4. metadata:
    5.   name: my-pod
    6. spec:
    7.   containers:
    8.    - name: app
    9.      image: nginx
    10.      volumeMounts:
    11.        - name: data
    12.          mountPath: /var/www/html
    13.   volumes:
    14.    - name: data
    15.      persistentVolumeClaim:
    16.        claimName: my-pvc  # 使用已绑定的 PVC

    复制代码
           
    
         
  

---

关键特性对比

特性PVPVC界说者集群管理员应用开发者创建方式手动创建或动态供应（通过 StorageClass）用户手动创建绑定关系一个 PV 只能绑定到一个 PVC一个 PVC 只能绑定到一个 PV接纳计谋支持 Retain、Delete、Recycle无，随 PV 的接纳计谋处理处罚动态供应依靠 StorageClass 和 Provisioner通过指定 StorageClass 触发动态创建 PV

---

生命周期与接纳计谋

•         PV 的接纳计谋（persistentVolumeReclaimPolicy）
  
  
  
  •                 Retain（默认）：删除 PVC 后，PV 保存数据，需手动清算。
    
  •                 Delete：删除 PVC 后，自动删除 PV 及底层存储（如云磁盘）。
    
  •                 Recycle（已废弃）：删除数据并标志 PV 为可用（仅实用于部门存储范例）。
    
         
  
•         PVC 删除后的举动
  
  
  
  •                 若 PV 的接纳计谋为 Retain，则 PV 进入 Released 状态，需管理员手动清算后重新绑定。
    
  •                 若为 Delete，则 PV 和底层存储资源会被自动删除。
    
         
  

---

动态供应（Dynamic Provisioning）

当利用 StorageClass 时，PVC 可以直打仗发 PV 的自动创建，无需管理员预先设置 PV。

•         示例 StorageClass（AWS EBS）：
  
  2. apiVersion: storage.k8s.io/v1
  3. kind: StorageClass
  4. metadata:
  5.   name: aws-gp2
  6. provisioner: kubernetes.io/aws-ebs  # 指定存储驱动
  7. parameters:
  8.   type: gp2
  9. reclaimPolicy: Delete              # 动态创建的 PV 默认回收策略

  复制代码
  
  
•         用户创建 PVC 时指定 StorageClass：
  
  2. spec:
  3.   storageClassName: aws-gp2  # 动态创建符合要求的 PV
  4.   accessModes: [ReadWriteOnce]
  5.   resources:
  6.    requests:
  7.      storage: 20Gi

  复制代码
  
  

---

总结

•         PV 是现实的存储资源，PVC 是用户对存储需求的抽象。
  
•         PVC 通过匹配 PV 的规格（容量、访问模式、StorageClass）来绑定存储资源。
  
•         动态供应 通过 StorageClass 实现按需自动创建 PV，大幅简化存储管理。
  
•         二者的分离使得存储资源的提供方（管理员）和利用方（开发者）职责清楚，提拔机动性和可维护性。
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

继续阅读请点击广告