2、持久卷（PersistentVolume）：PV的生命周期、静态供给与动态供给机制

2.1 持久卷（PV）与持久卷声明（PVC）的核心概念

在 Kubernetes 存储架构中，持久卷（PersistentVolume，PV） 是集群管理员预置或由存储系统动态分配的存储资源抽象，独立于任何 Pod 的生命周期。持久卷声明（PersistentVolumeClaim，PVC） 则是用户对存储资源的请求，包括存储大小、访问模式等需求。PV 与 PVC 的绑定机制实现了存储供给与消费的解耦。

关键设计思想： 将“存储资源的提供”与“存储资源的使用”分离。管理员关注 PV 的容量、类型和回收策略；用户只需在 PVC 中声明需求，无需关心底层存储实现细节。

2.2 PV 的生命周期

一个 PV 从创建到销毁会经历以下四个阶段，每个阶段对应不同的状态与操作：

阶段 状态 说明 典型操作
供给（Provisioning） Available PV 已创建，尚未与任何 PVC 绑定，可供集群使用。 静态创建 YAML 或动态供给触发
绑定（Binding） Bound PV 与 PVC 成功匹配并绑定，状态变为 Bound。绑定是一对一的独占关系。 PVC 创建后自动匹配
使用（Using） Bound Pod 通过 PVC 挂载 PV 进行读写操作。PV 在此期间保持绑定状态。 Pod 创建/删除
回收（Reclaiming） Released → Available / Failed PVC 被删除后，PV 进入 Released 状态，根据回收策略决定后续命运。 删除 PVC、执行回收策略
注意： PV 的 status.phase 字段会实时反映当前生命周期阶段。管理员可通过 kubectl get pv 查看所有 PV 的状态。

2.3 静态供给机制

静态供给（Static Provisioning） 是最传统的 PV 创建方式。集群管理员预先手动创建 PV 对象，并配置好后端存储的详细信息（如 NFS 路径、Ceph RBD 镜像、云磁盘 ID 等）。用户创建 PVC 时，Kubernetes 调度器会根据 PVC 的容量、访问模式等条件，从 Available 状态的 PV 池中寻找匹配项进行绑定。

静态供给的工作流程

  1. 管理员创建 PV： 定义 YAML 文件，指定存储类型、容量、访问模式、挂载选项及回收策略。
  2. 用户创建 PVC： 在 YAML 中声明所需存储大小、访问模式（如 ReadWriteOnce）。
  3. 控制平面匹配绑定： Kubernetes 的 PersistentVolumeController 遍历所有 Available 的 PV，找到满足 PVC 请求的 PV 并绑定。
  4. Pod 使用： Pod 通过 PVC 名称引用该存储卷，调度到节点后挂载使用。
静态供给的局限性： 如果集群中没有满足 PVC 请求的 PV（例如容量不足或访问模式不匹配），PVC 将一直处于 Pending 状态，直到管理员手动创建合适的 PV。这在大规模动态环境中容易造成资源浪费或供给延迟。

静态供给 PV 示例（NFS）

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-nfs-static
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  nfs:
    path: /data/shared
    server: 192.168.1.100

2.4 动态供给机制

动态供给（Dynamic Provisioning） 解决了静态供给的痛点。当用户创建 PVC 时，如果集群中没有匹配的 PV，Kubernetes 会根据 PVC 中指定的 StorageClass 自动调用对应的存储后端插件（Provisioner）来动态创建 PV。整个过程无需管理员干预，实现了存储的按需供给。

动态供给的核心组件

  • StorageClass： 定义存储的“模板”，包括 Provisioner 名称、参数（如磁盘类型、IOPS、回收策略）和绑定模式。
  • Provisioner： 后端存储的驱动程序，负责实际创建和删除存储卷。常见的有 kubernetes.io/aws-ebs、kubernetes.io/gce-pd、nfs.csi.k8s.io 等。
  • PVC 中的 StorageClass 引用： PVC 通过 spec.storageClassName 字段指定要使用的 StorageClass。

动态供给的工作流程

  1. 管理员创建 StorageClass： 定义存储模板，例如指定使用 AWS EBS 的 gp3 类型，回收策略为 Delete。
  2. 用户创建 PVC： 在 PVC 中引用该 StorageClass，并声明容量和访问模式。
  3. 控制平面检测无匹配 PV： PersistentVolumeController 发现没有可用的 PV 满足请求。
  4. 触发动态供给： 根据 StorageClass 配置，调用对应的 Provisioner 在存储后端创建卷。
  5. 自动创建 PV 并绑定： Provisioner 返回卷信息后，系统自动生成 PV 对象并与 PVC 绑定。
  6. Pod 使用： 与静态供给相同，Pod 通过 PVC 挂载使用。

StorageClass 与 PVC 示例

# StorageClass 定义
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp3
  fsType: ext4
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
---
# PVC 引用 StorageClass
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-dynamic
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi
  storageClassName: fast-ssd

2.5 静态供给与动态供给对比

对比维度 静态供给 动态供给
创建方式 管理员手动创建 PV 系统根据 StorageClass 自动创建 PV
灵活性 低，需要预先规划容量 高，按需分配，弹性伸缩
运维成本 高，需要持续管理 PV 池 低，自动化供给与回收
适用场景 固定存储设备、NFS 共享、测试环境 云环境、大规模生产集群、需要快速扩缩容
回收策略 Retain / Recycle / Delete（需手动配置） 由 StorageClass 统一管理，通常为 Delete
PVC 绑定失败 PVC 一直 Pending，需管理员介入 自动触发创建，极少出现 Pending

2.6 PV 生命周期与供给机制总览

下图展示了从 PV 创建到回收的完整生命周期，以及静态供给与动态供给两条路径的交互关系：

PV 生命周期与供给机制总览 管理员创建 PV PV 状态：Available PVC 匹配与绑定 PV 状态：Bound 回收策略执行 用户创建 PVC（含 StorageClass） 检测无匹配 PV Provisioner 动态创建卷 自动生成 PV 并绑定 回收策略执行（通常 Delete） 或 关键区别 • 静态：管理员预创建 PV • 动态：PVC 触发自动创建 • 动态依赖 StorageClass 回收策略 • Retain：保留数据，需手动清理 • Delete：自动删除后端存储

2.7 回收策略详解

当 PVC 被删除后，PV 进入 Released 状态，其后续行为由 persistentVolumeReclaimPolicy 决定。三种策略的对比：

回收策略 行为 数据安全性 适用场景
Retain（保留） PV 保留，数据完整，但不可被其他 PVC 直接绑定。管理员需手动删除 PV 并清理后端存储后，才能重新使用。 最高 需要备份数据、审计需求、重要数据库
Delete（删除） PV 和后端存储卷（如云磁盘、EBS 卷）会被自动删除。 低 临时数据、开发测试环境、动态供给默认策略
Recycle（回收） PV 会被清空（执行 rm -rf /volume/*），然后重新变为 Available 状态。此策略已废弃，推荐使用动态供给替代。 中 仅适用于支持清理的卷插件（如 NFS），不推荐新集群使用
最佳实践： 在生产环境中，对于有状态应用（如数据库）建议使用 Retain 策略，并配合定期备份。对于无状态或临时存储，使用 Delete 策略以自动化清理资源，避免存储泄漏。

2.8 绑定模式：Immediate 与 WaitForFirstConsumer

StorageClass 中的 volumeBindingMode 控制 PV 绑定的时机，直接影响 Pod 调度与存储位置的亲和性。

  • Immediate（立即绑定）： 一旦 PVC 创建，立即尝试寻找或创建 PV 并绑定。适用于所有节点都能访问的共享存储（如 NFS、CephFS）。
  • WaitForFirstConsumer（延迟绑定）： 直到第一个使用该 PVC 的 Pod 被调度到某个节点后，才进行 PV 的创建与绑定。这保证了 PV 与 Pod 所在节点的拓扑亲和性（例如 AWS EBS 必须与 Pod 在同一可用区）。
延迟绑定的优势： 避免因 PV 与 Pod 不在同一可用区导致的挂载失败或性能损失。在云环境中，强烈建议将 volumeBindingMode 设置为 WaitForFirstConsumer。

2.9 访问模式（Access Modes）

PV 和 PVC 都支持三种访问模式，决定了卷的挂载能力：

访问模式 缩写 说明 典型存储
ReadWriteOnce RWO 卷可以被单个节点以读写方式挂载。 云磁盘（EBS、GCE PD）、HostPath
ReadOnlyMany ROX 卷可以被多个节点以只读方式挂载。 NFS、CephFS、ConfigMap
ReadWriteMany RWX 卷可以被多个节点以读写方式挂载。 NFS、GlusterFS、Azure File
注意： 访问模式是卷的能力限制，而非权限控制。即使 PV 支持 RWX，Pod 内的容器仍可通过挂载选项设置为只读。PVC 请求的访问模式必须被 PV 支持，否则无法绑定。
← 上一章 📖 返回目录 下一章 →