1. 持久化存储的核心挑战与K8s解决方案
在容器化应用部署中，数据持久化一直是个棘手的问题。容器本身具有"无状态"的特性，当Pod被重新调度或节点发生故障时，容器内的临时存储会随之消失。这对于数据库、文件存储等需要持久保存数据的应用场景来说简直是灾难性的。
我经历过一个典型的案例：某电商平台的订单服务最初直接使用容器本地存储，结果在一次集群节点故障后丢失了上千笔交易记录。这种教训让我们意识到，必须为关键业务数据提供独立于容器生命周期的存储方案。
Kubernetes给出的答案是PersistentVolume（PV）和PersistentVolumeClaim（PVC）这套组合拳。PV相当于集群中的一块"虚拟硬盘"，由管理员预先配置；PVC则是用户对存储资源的"申请单"，开发者无需关心底层存储细节。这种抽象层设计完美解耦了存储供应和消费，让运维和开发各司其职。
2. PV详解：集群中的持久化存储单元
2.1 PV的核心属性解析
每个PV本质上是对后端存储服务的抽象封装。创建PV时需要明确几个关键属性：
yaml复制apiVersion: v1
kind: PersistentVolume
metadata:
name: mysql-pv
spec:
capacity:
storage: 100Gi
volumeMode: Filesystem
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
storageClassName: fast-ssd
hostPath:
path: /mnt/data/mysql
- capacity：定义存储空间大小。注意这只是一个声明值，实际可用空间取决于后端存储系统
- accessModes：支持三种访问模式：
- ReadWriteOnce（RWO）：单节点读写
- ReadOnlyMany（ROX）：多节点只读
- ReadWriteMany（RWX）：多节点读写
- persistentVolumeReclaimPolicy：决定PV释放后的处理策略：
- Retain：保留数据（需手动清理）
- Recycle：自动擦除（已废弃）
- Delete：自动删除（仅支持云存储）
重要提示：hostPath仅适用于单节点测试环境，生产环境应使用NFS、Ceph、云存储等网络存储方案
2.2 主流PV类型对比
根据底层存储介质的不同，PV支持多种类型。以下是常见方案的特性对比：
| 存储类型 | 适用场景 | 多节点访问 | 性能 | 配置复杂度 | 成本 |
|---|---|---|---|---|---|
| hostPath | 开发测试 | 单节点 | 高 | 低 | 低 |
| NFS | 中小规模文件共享 | 支持 | 中 | 中 | 中 |
| CephFS | 大规模分布式存储 | 支持 | 高 | 高 |