全景定位
Kubernetes 存储是分层对象组合：Pod 里声明 Volume（引用具体卷类型或 PVC），PVC 表达申请，PV 表示实际存储，StorageClass 描述动态供应方式，CSI 驱动负责与底层存储对接。适用平台是 Kubernetes。排障时的价值在于「按链路上溯」：Pod 挂载 → PVC 绑定 → PV 状态 → 存储侧，每一层都有明确的对象与事件可看，不必在错误的一层反复改配置。
基本信息
| 适用平台 | Kubernetes，存储相关的多层 API 对象 |
|---|---|
| 对象归属 | Volume 与 PVC 属命名空间，PV 与 StorageClass 属集群 |
| 供应方式 | 静态（管理员建 PV）与动态（StorageClass 触发制备） |
| 对接实现 | CSI 驱动由控制器组件与节点组件两部分组成 |
典型使用场景
- 新业务设计存储：先明确数据是否需要留存、是否跨节点共享，再选卷类型
- 故障定位：沿链路从 Pod 查到存储侧，避免跳层排查
- 容量审计：统计 PVC 申请量与 PV 实际提供量，识别浪费与不足
- 迁移评估：换存储后端时确认 StorageClass 与驱动能力差异
- 权限与回收治理：梳理哪些卷是 Delete、哪些是 Retain
调用链
调用链
# 调用链：Pod -> PVC -> StorageClass -> 动态制备 PV -> 底层存储
kubectl get pod web-x -o jsonpath='{.spec.volumes}' # 1 Pod 声明了什么卷
kubectl get pvc mysql-data # 2 PVC 是否 Bound
kubectl get pvc mysql-data -o jsonpath='{.spec.volumeName}' # 3 对应哪个 PV
kubectl get pv <pv-name> -o jsonpath='{.spec.csi}' # 4 底层驱动与参数
kubectl get pv <pv-name> -o jsonpath='{.spec.persistentVolumeReclaimPolicy}'
kubectl get sc # 5 供应模板与默认类对象与职责
| 对象 | 角色 | 由谁创建 |
|---|---|---|
| Volume（Pod 内） | Pod 可直接使用的挂载声明（含 emptyDir、configMap 等） | 应用清单 |
| PV | 集群中一块存储的抽象 | 管理员静态创建或制备器动态创建 |
| PVC | 使用者对容量与模式的申请 | 应用或管理员 |
| StorageClass | 动态供应的模板（provisioner 与参数） | 集群管理员 |
| CSI 驱动 | 对接具体存储的实现（控制器与节点组件） | 集群管理员或云平台 |
排障按链路上溯：Pod 挂载 → PVC 绑定 → PV 状态 → 存储侧，别在错误的层反复改配置。
对象职责不同：删 Pod 不影响 PVC；删 PVC 是否影响 PV 取决于回收策略，Delete 会连带删除底层存储，Retain 会保留为 Released 状态。