存储类(StorageClass)
让 PVC 自动触发存储创建。
StorageClass 让 PVC 自动触发底层存储创建，避免手动准备 PV。
关键字段
provisioner：存储插件parameters：存储参数reclaimPolicy：回收策略
简化示例
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: fast
provisioner: csi.example.com
parameters:
type: ssd
reclaimPolicy: Delete
建议
- 区分 fast/standard 两类即可
- 生产要考虑回收策略与备份
实操要点
- 先做快速盘点：
kubectl get nodes、kubectl get pods -A、kubectl get events -A。 - 对比“期望状态”和“实际状态”，
kubectl describe往往能解释漂移或失败原因。 - 名称、Label、Selector 要一致，避免 Service 或控制器找不到 Pod。
快速检查清单
- 资源定义与业务意图一致。
- Namespace、权限、镜像与环境匹配。
- 上线前具备健康探针与可观测日志。
存储模型与绑定关系
Kubernetes 将“需求”和“实现”分离：PVC 描述需求，PV 描述具体存储，StorageClass 描述供给方式。StorageClass 决定了存储如何创建、如何绑定到 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
收个尾：StorageClass 定的是“默认玩法”
StorageClass 选得好不好，决定了你后面会不会天天遇到 PVC Pending、或者一不小心把数据删了。
我建议你至少确认三件事：
- 集群里有没有默认 StorageClass（没有的话 PVC 会卡住）
- 回收策略是 Delete 还是 Retain（生产数据别随手 Delete）
- 绑定模式/可用区是否匹配你的调度方式
另外，IOPS/吞吐别拍脑袋，最好用压测或线上指标反推，不然就是“看起来更快，实际更贵”。