3. PersistentVolume (PV) 详解:PV 定义、生命周期、静态供给与回收策略
PersistentVolume (PV) 是 Kubernetes 存储体系中的核心资源对象,它代表集群中由管理员预先配置或通过存储类动态供给的一块存储后端。PV 独立于 Pod 的生命周期,为有状态应用提供了持久化数据存储能力。本章将深入剖析 PV 的定义结构、完整生命周期、静态供给模式以及关键的回收策略。
3.1 PV 资源定义与核心字段
PV 是一个 API 资源,通过 YAML 清单定义。其核心字段决定了存储的容量、访问模式、回收策略以及后端存储驱动的具体配置。
| 字段路径 | 类型 | 说明 | 示例值 |
|---|---|---|---|
spec.capacity.storage |
Quantity | PV 的存储容量,不可变更 | 10Gi |
spec.volumeMode |
string | 文件系统 (Filesystem) 或块设备 (Block) |
Filesystem |
spec.accessModes |
[]string | 支持的访问模式列表 | ReadWriteOnce |
spec.persistentVolumeReclaimPolicy |
string | 释放后对后端存储的处理策略 | Retain |
spec.storageClassName |
string | 绑定到指定 StorageClass,用于动态供给匹配 | standard |
spec.<driver> |
Object | 后端存储驱动配置,如 nfs、hostPath、csi |
nfs.server |
关键约束: PV 的
capacity 和 accessModes 在创建后不可修改。如果应用需要扩容或切换访问模式,必须创建新的 PV 并迁移数据。
以下是一个基于 NFS 的静态 PV 定义示例:
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv-nfs-data
labels:
type: nfs
spec:
capacity:
storage: 50Gi
volumeMode: Filesystem
accessModes:
- ReadWriteMany
persistentVolumeReclaimPolicy: Retain
storageClassName: ""
nfs:
server: 192.168.1.100
path: "/exports/app-data"
readOnly: false
3.2 PV 生命周期:从创建到释放
PV 的生命周期包含四个明确的阶段,每个阶段都对应着资源在集群中的状态变化。
- Available(可用):PV 已被管理员创建,尚未与任何 PersistentVolumeClaim (PVC) 绑定。
- Bound(已绑定):PV 成功匹配并绑定到一个 PVC,此时 PV 的状态变为
Bound,PVC 也进入Bound状态。绑定是一对一的独占关系。 - Released(已释放):绑定的 PVC 被删除,PV 从
Bound变为Released。此时 PV 中的数据可能仍然存在,但不能再被新的 PVC 直接使用。 - Failed(失败):当 PV 在
Released状态下执行自动回收(如Delete策略)失败时,进入Failed状态,需要管理员手动介入。
实践建议: 在
Released 状态下,管理员可以手动检查数据完整性,然后根据回收策略决定是清理数据、保留数据还是重新使用该 PV。
3.3 静态供给:管理员预置存储
静态供给是指集群管理员预先创建好 PV 资源,并将其与后端存储(如 NFS 共享、Ceph RBD 块设备、本地磁盘)关联。应用开发者通过创建 PVC 来请求存储,Kubernetes 控制平面负责将 PVC 与满足条件的 PV 进行匹配绑定。
静态供给的匹配规则基于以下三个核心条件:
- 容量匹配:PVC 请求的容量必须小于或等于 PV 的容量。
- 访问模式匹配:PVC 请求的访问模式必须是 PV 支持的访问模式之一。
- StorageClass 匹配:如果 PVC 指定了
storageClassName,则 PV 必须具有相同的storageClassName;如果 PVC 未指定,则 PV 的storageClassName必须为空字符串。
注意: 静态供给模式下,如果集群中没有 PV 能满足 PVC 的请求,PVC 将一直处于
Pending 状态,直到管理员创建匹配的 PV 或部署动态供给程序。
3.4 回收策略:数据持久化与清理
当 PVC 被删除后,PV 进入 Released 状态,此时集群会根据 PV 上配置的 persistentVolumeReclaimPolicy 来决定如何处理后端存储资源。
| 回收策略 | 行为描述 | 适用场景 | 数据安全 |
|---|---|---|---|
| Retain(保留) | PV 进入 Released 状态后,后端存储数据保留,PV 不会自动清理。管理员需手动删除 PV 并处理数据。 | 需要手动备份、审计或迁移数据的场景;生产环境默认推荐。 | 最高 |
| Delete(删除) | PV 释放后,关联的后端存储资源(如云磁盘、卷)会被自动删除。PV 对象也会被移除。 | 动态供给的临时存储、测试环境、无需保留数据的场景。 | 低 |
| Recycle(回收) | PV 释放后,会执行一个清理脚本(如 rm -rf /volume/*),然后 PV 重新变为 Available 状态。 |
已弃用(Deprecated),建议使用动态供给替代。 | 中 |
最佳实践: 对于生产环境的关键数据,始终使用
Retain 策略。即使 PVC 被误删,数据仍然安全地保留在后端存储中,管理员有充足的时间进行恢复或迁移。对于非关键或可重建的数据,可以使用 Delete 策略以简化运维。
3.5 静态供给 vs 动态供给
理解静态供给与动态供给的差异,有助于在架构设计中选择合适的存储供给模式。
| 对比维度 | 静态供给 | 动态供给 |
|---|---|---|
| 管理员操作 | 需预先创建 PV 并配置后端存储 | 只需创建 StorageClass,PV 自动创建 |
| 资源利用率 | 可能造成 PV 资源浪费或不足 | 按需分配,利用率高 |
| 灵活性 | 低,PV 容量和类型固定 | 高,PVC 可指定参数动态调整 |
| 适用场景 | 已有固定存储设备、需要精细控制存储布局 | 云环境、大规模集群、自动化运维 |
架构决策: 在混合部署场景中,可以同时使用静态供给(为关键数据库提供专用高性能存储)和动态供给(为无状态应用提供通用存储),以平衡成本与性能。