6.2 PV与PVC：租一块永久用地

6.2 PV 与 PVC：租一块永久用地

本节摘要：持久化存储由三个对象协作：PersistentVolume 是集群里的地块（由管理员或 StorageClass 动态开辟），PersistentVolumeClaim 是租地申请，Pod 通过引用申请获得地块的使用权。申请绑定后，地块的生命周期独立于苗——苗换代、地块换茬，数据留存。本节走完申请、绑定、回收的全流程，讲清动态供地与回收策略。

数据要活得比苗久

上一节末尾留了个悬念：果树苗的"专属地块"从哪来？先看没有地块时的惨状——苗的容器层是张草席，铺在哪儿写到哪儿，苗一收席子就卷走。日志、数据库、上传的封面图，全都不能睡草席。第一章的需求清单里"存储管理"这条，此刻兑现。

Kubernetes 的答案是把"地"与"苗"彻底分开，中间立三个角色：

• PersistentVolume（PV）：地里实际的一块储备用地，可以由管理员事先开辟（静态供给），也可以按需现开（动态供给）。
• PersistentVolumeClaim（PVC）：租地申请单。写明要多大、什么用法（单读写还是多路读写），不写要哪块——挑地的事交给系统。
• StorageClass（SC）：地的等级目录。"快速盘""普通盘""冷存储"，每级对应一套开辟参数。有它在，申请单交上去，现开一块合适的地（动态供给）。

农事翻译：PV 是地，PVC 是租地合同，StorageClass 是地价目录。苗拿着合同用地，合同不随苗的生死作废。

图：一张租地申请的一生

动手：申请与使用一块地

书屋要给上传的封面图找个永久住处。申请单这么写：

# 租地申请：二十吉 单路读写 按目录里的快盘级现开
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: cover-images
  namespace: greenlib-prod
spec:
  accessModes:
    - ReadWriteOnce          # 单节点独占读写（块设备的常见姿势）
  storageClassName: fast-ssd # 对照哪个地价目录
  resources:
    requests:
      storage: 20Gi
​

kubectl apply -f cover-pvc.yaml -n greenlib-prod
# persistentvolumeclaim/cover-images created

kubectl get pvc -n greenlib-prod
# NAME           STATUS   VOLUME                                     CAPACITY   STORAGECLASS
# cover-images   Bound    pvc-3f8a92c1-e4d0-4f2a-9c1b-6d7e8f9a0b1c   20Gi       fast-ssd
# db-data-shelf-db-0   Bound   pvc-8b1c...（果树零号的地 上一节自动申的）
# STATUS 列 Bound 即签约成功

kubectl get pv | grep pvc-3f8a
# pvc-3f8a92c1...   20Gi   RWO   Delete   fast-ssd     Bound
# 地块本身的档案：用法 回收策略 等级 绑定状态
​

苗用地的方式是在播种单里引用申请（Deployment 或其他工作负载通用）：

# 播种单引用租地合同（节选）
      containers:
        - name: api
          image: greenlib/api:2.0.0
          volumeMounts:
            - name: covers
              mountPath: /var/greenlib/covers   # 封面图落在这块地上
      volumes:
        - name: covers
          persistentVolumeClaim:
            claimName: cover-images             # 引用合同号
​

从此这块地跟着合同走：苗滚动更新换代，地不动；删除苗重建，数据还在。合同（PVC）才是地的持有人，想让数据消失，得明确退租（删 PVC）。

用法模式与回收策略

accessModes 是申请单里最容易写错的一栏，三种取值对应三种地性：

注意 RWO 的"独占"按节点计：同一节点上的多株苗可以共用，跨节点不行。想多节点共写就得 RWX，而 RWX 要求底层是支持共享访问的文件系统（网络存储类），不是所有"地"都供得起。

回收策略管的是退租后地的下场：Delete（随 PVC 一并铲平，云盘常用）、Retain（地留着等人审查后手工处理，自建机房常用）。数据库这类要命的地，我会建议 StorageClass 配 Retain——宁可地闲着，不能数据没绑没了。存储池紧张时也可以先 Recycle 擦除再复用，不过该策略已淡出，了解即可。

⚠️ 常见坑：以为删掉 StatefulSet 数据就清干净了。不会——PVC 还在，数据都在地里。清理要连 PVC 一起删；反过来，只想换苗不想清数据时，千万别动 PVC。这两个方向的操作误会，是数据事故的高发地带。

容量只能加，很难减

PVC 有个反直觉的规矩：扩容通常允许，缩容基本不支持。存储卷的容量在多数底层实现上只能变大不能变小，想把二十吉的地缩成十吉，标准路径是新建小卷、迁数据、换引用。所以第一次申请就该想清楚容量：宁可按增长曲线分阶段扩，也别一步到位圈块巨大的"以后再说"。

备份是另一门功课

PVC 保护的是地块不丢，不等于数据可恢复。误删记录、逻辑损坏这类事故，要靠快照与备份体系：存储层快照（StorageClass 支持时）、应用层导出（第六章末那个 pg_dump 备份活正是干这个的）、异地归档，三件按数据身价配置。地块冗余防硬件故障，备份防人为失误，互补而不互替。

本节要点回顾

• 三角色：PV 是地，PVC 是租地合同，StorageClass 是地价目录（动态供给）
• 合同持有地：苗的生死不影响数据，退租才动数据
• accessModes 按节点计独占，共享读写需要 RWX 级的地基
• 回收策略 Delete 铲平 Retain 留查，要命的地配 Retain
• StatefulSet 的 volumeClaimTemplates 为每株果树自动签专属合同，同编号绑定