持久卷(PV)与持久卷声明(PVC)

PV 是集群层面的存储资源，PVC 是应用对存储的“申请单”。Kubernetes 会把 PVC 绑定到合适的 PV。

核心概念

• PV：由管理员或存储系统提供
• PVC：由应用声明需求
• 绑定：PVC 与 PV 一对一

常见流程

1. 创建 PVC
2. 自动或手动绑定 PV
3. Pod 通过 PVC 挂载

小建议

• 尽量使用 StorageClass 做动态供给
• 关注访问模式：ReadWriteOnce vs ReadWriteMany

实操要点

• 先做快速盘点：kubectl get nodes、kubectl get pods -A、kubectl get events -A。
• 对比“期望状态”和“实际状态”，kubectl describe 往往能解释漂移或失败原因。
• 名称、Label、Selector 要一致，避免 Service 或控制器找不到 Pod。

快速检查清单

• 资源定义与业务意图一致。
• Namespace、权限、镜像与环境匹配。
• 上线前具备健康探针与可观测日志。

存储模型与绑定关系

Kubernetes 将“需求”和“实现”分离：PVC 描述需求，PV 描述具体存储，StorageClass 描述供给方式。PV/PVC 决定了存储如何创建、如何绑定到 Pod。

访问模式与回收策略

访问模式决定卷的使用方式：RWO 适合单写入，RWX 适合共享读写，ROX 适合只读共享。回收策略决定 PVC 删除后的行为，Delete 会移除底层卷，Retain 会保留数据。生产环境务必谨慎选择。

扩容与快照

很多存储后端支持在线扩容，但仍需确认文件系统是否需要额外扩展步骤。快照用于备份与克隆，建议用于升级演练与灾备验证。

性能与成本

存储往往是瓶颈。SSD 类更快但更贵，网络存储更灵活但延迟更高。选择 StorageClass 要基于真实 IOPS 与吞吐需求，而不是仅看容量。持续监控使用率能避免过度预留。

拓扑与可用区

部分存储只支持单可用区。要让调度与绑定一致，需配置合适的绑定模式和拓扑约束。若出现 Pending，检查可用区与卷绑定配置。

数据一致性与备份窗口

备份和快照需要考虑一致性。数据库类工作负载建议在低峰或配合一致性机制进行快照，并定期验证恢复流程，确认实际恢复时间。

运维流程

先确认 PVC 已绑定，再启动业务。监控磁盘使用与 inode 压力。迁移时预留数据复制窗口，并演练恢复流程。存储具备持久性，因此资源下线时也要清理遗留 PVC 与底层卷。

kubectl get pv
kubectl get pvc -n demo
kubectl describe pvc data-demo -n demo

收个尾：PVC Pending 时，先别怪 Pod

存储相关问题最典型的现象就是：Pod 一直 Pending。很多人会盯着 Pod 看半天，其实根因在 PVC/PV：

• StorageClass 不存在或参数不对
• 绑定模式/可用区约束不满足
• 后端存储配额到了

还有一句老话：PVC 不是备份。数据要靠快照/备份体系，别把“卷还在”当成灾备。

参考链接

• 持久卷
• PVC