1. 概述
在 Kubernetes 中，持久卷（Persistent Volume，PV）的访问模式是配置存储资源时必须理解的核心概念之一。特别是在运行数据库、文件服务等有状态应用时，选择合适的访问模式将直接影响到应用的可用性、数据一致性和性能。
本文将深入讲解 Kubernetes 中 PV 的访问模式，包括其适用场景、使用限制以及配置时的常见注意事项。✅掌握这些内容有助于我们在部署应用时做出更合理、更高效的存储配置决策。
2. 持久卷（Persistent Volume，PV）
2.1 定义与作用
PV 是 Kubernetes 集群中独立于 Pod 生命周期的存储资源。它为应用提供持久化存储能力，即使 Pod 被删除或重建，数据依然保留在 PV 中。这使得 PV 成为运行有状态服务（如 MySQL、Redis、Elasticsearch）不可或缺的组件。
2.2 与普通 Volume 的区别
- 普通 Volume：生命周期与 Pod 绑定，Pod 被删除后 Volume 数据也可能丢失。
- PV：独立存在，Pod 删除后数据仍保留，支持跨 Pod 共享，适用于长期存储。
3. 持久卷声明（Persistent Volume Claim，PVC）
3.1 功能与角色
PVC 是用户对存储资源的申请请求。通过 PVC，用户可以请求特定大小和访问模式的存储，而无需关心底层存储的具体实现方式（如 NFS、Ceph、云盘等）。
3.2 PVC 与 PV 的关系
- PV：实际的存储资源。
- PVC：对 PV 的“声明”，类似于“租用”行为。
- 绑定机制：Kubernetes 会自动将 PVC 与匹配的 PV 进行绑定，实现资源动态分配。
4. 持久卷的类型
Kubernetes 支持多种类型的 PV，每种适用于不同的场景：
| 类型 | 说明 | 适用场景 |
|---|---|---|
local |
使用节点本地磁盘 | 对 I/O 要求高的应用 |
hostPath |
挂载节点文件系统路径 | 本地测试，不适用于生产 |
nfs |
基于 NFS 协议共享存储 | 多节点共享读写 |
iscsi |
块存储协议 | 需要块设备支持的应用 |
csi |
基于 CSI 标准的插件 | 支持第三方存储系统 |
cephfs |
Ceph 分布式文件系统 | 高可用共享存储 |
fc |
光纤通道存储 | 高性能企业级存储 |
rbd |
Ceph 块设备 | 提供块级读写支持 |
5. 存储类（StorageClass）
StorageClass 定义了存储的“类别”，包括性能、回收策略、供给方式等参数。它用于动态创建 PV，使得 PVC 可以根据定义的类自动获取合适的存储资源。
示例配置如下：
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: fast
provisioner: kubernetes.io/aws-ebs
parameters:
type: io1
iopsPerGB: "10"
fsType: ext4
reclaimPolicy: Retain
6. 持久卷访问模式详解
访问模式决定了 PV 可以被多少节点以何种方式挂载。Kubernetes 支持以下四种访问模式：
6.1 ReadWriteOnce (RWO)
- 说明：卷只能被单个节点以读写方式挂载。
- 适用场景：单实例数据库、有状态应用（如 MySQL、PostgreSQL）。
- 限制：不支持多节点并发写入。
✅典型用例：MySQL 数据目录。
6.2 ReadOnlyMany (ROX)
- 说明：卷可以被多个节点以只读方式挂载。
- 适用场景：共享配置文件、静态资源目录。
- 限制：只读访问，无法写入。
✅典型用例：前端应用共享静态资源。
6.3 ReadWriteMany (RWX)
- 说明：卷可以被多个节点以读写方式挂载。
- 适用场景：分布式协作系统、共享缓存。
- 限制：需要底层存储支持并发写入（如 NFS、CephFS）。
✅典型用例：NFS 共享目录用于多个 Pod 写入日志。
6.4 ReadWriteOncePod (RWOP)
- 说明：卷只能被单个 Pod 以读写方式挂载。
- 适用场景：严格控制写入权限的场景。
- 限制：比 RWO 更细粒度的控制。
✅典型用例：需要确保数据独占写入的微服务。
7. PV 与 PVC 生命周期管理
7.1 创建（Provisioning）
可以手动创建 PV，也可以通过 PVC 触发动态创建。
apiVersion: v1
kind: PersistentVolume
metadata:
name: example-pv
spec:
capacity:
storage: 5Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
storageClassName: standard
hostPath:
path: /mnt/data
7.2 绑定（Binding）
PVC 会自动绑定到匹配的 PV：
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: example-pvc
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
storageClassName: standard
7.3 使用（Using）
Pod 通过 PVC 使用 PV：
apiVersion: v1
kind: Pod
metadata:
name: example-pod
spec:
containers:
- name: my-container
image: nginx
volumeMounts:
- mountPath: "/usr/share/nginx/html"
name: my-storage
volumes:
- name: my-storage
persistentVolumeClaim:
claimName: example-pvc
7.4 回收（Reclaiming）
根据 persistentVolumeReclaimPolicy 设置，PV 可被保留、删除或回收：
apiVersion: v1
kind: PersistentVolume
metadata:
name: example-pv
spec:
capacity:
storage: 5Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Delete
storageClassName: standard
hostPath:
path: /mnt/data
8. 最佳实践
8.1 明确指定 StorageClass
避免使用默认类，确保存储特性可控。
8.2 合理规划存储容量
PV 通常不支持在线扩容，需提前规划容量。
8.3 优先使用动态供给
动态供给简化运维，减少手动配置。
8.4 设置合适的回收策略
Retain：保留数据，适合重要数据。Delete：删除 PV 和底层存储。Recycle：清理后重用（已不推荐）。
8.5 使用 RBAC 控制权限
通过角色权限控制 PVC/PV 的访问权限，提升安全性。
9. 总结
Kubernetes 的 PV 访问模式是构建有状态服务的关键配置项。选择合适的访问模式不仅能提升应用性能，还能保障数据一致性与安全性。
本文介绍了四种主要访问模式及其适用场景，并通过 YAML 示例演示了 PV/PVC 的基本使用方式。希望你在实际部署中能根据业务需求灵活选择，避免踩坑。✅
随着 Kubernetes 的不断发展，存储生态也在持续演进。建议关注官方文档更新，保持对存储方案的敏感度，持续优化集群存储架构。