📚 课程目录第4章 StorageClass与动态供给

4. StorageClass 与动态供给：定义、Provisioner 参数与回收策略

在 Kubernetes 中，StorageClass 是连接集群管理员与开发者的存储抽象层。它定义了存储的“类型模板”，使得 PersistentVolumeClaim（PVC）可以自动获得匹配的 PersistentVolume（PV），而无需管理员预先手动创建 PV。这一机制称为动态供给（Dynamic Provisioning）。

核心价值： 动态供给将存储管理从“预分配”模式转变为“按需分配”模式，大幅降低存储运维成本，提升集群存储资源利用率。

4.1 StorageClass 的定义结构

一个标准的 StorageClass 资源定义包含以下关键字段：

字段	类型	说明
`provisioner`	string	指定存储后端驱动，决定由哪个插件创建 PV
`parameters`	map[string]string	传递给 provisioner 的特定配置参数
`reclaimPolicy`	string	PV 被释放后的处理策略：`Delete` 或 `Retain`
`volumeBindingMode`	string	控制 PVC 与 PV 的绑定时机：`Immediate` 或 `WaitForFirstConsumer`
`allowVolumeExpansion`	bool	是否允许后续扩容卷
`mountOptions`	[]string	挂载时附加的选项（如 `noatime`）

以下是一个完整的 StorageClass 定义示例：

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp3
  fsType: ext4
  iopsPerGB: "10"
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
mountOptions:
  - noatime
  - nodiratime

4.2 Provisioner 参数详解

Provisioner 是 StorageClass 的核心，它决定了存储后端的类型和创建行为。不同的云厂商或存储系统提供不同的 provisioner 名称和参数集。

4.2.1 常见 Provisioner 一览

Provisioner 名称	后端类型	典型场景
`kubernetes.io/aws-ebs`	AWS EBS	EC2 集群块存储
`kubernetes.io/gce-pd`	GCE Persistent Disk	GKE 集群块存储
`disk.csi.azure.com`	Azure Disk	AKS 集群块存储
`csi.vsphere.vmware.com`	vSphere	vSphere 虚拟化环境
`nfs.csi.k8s.io`	NFS	共享文件存储
`rook-ceph.rbd.csi.ceph.com`	Ceph RBD	自建 Ceph 块存储

4.2.2 参数传递机制

每个 provisioner 定义自己的参数键值对。例如，AWS EBS 的 type 参数可设置为 gp3、io2 等；Ceph RBD 的 pool 参数指定存储池名称。参数直接写入 StorageClass 的 parameters 字段，由 provisioner 在创建 PV 时解析。

  最佳实践： 为不同性能层（如 SSD、HDD、高 IOPS）分别定义 StorageClass，并在 parameters 中明确指定对应的后端配置。避免在 PVC 中硬编码存储细节。

4.3 回收策略（Reclaim Policy）

回收策略决定了当 PVC 被删除后，对应的 PV 及其后端存储如何处理。StorageClass 中定义的回收策略会作为该 StorageClass 动态创建的 PV 的默认策略。

策略	行为	适用场景
Delete	PVC 删除后，自动删除 PV 及其后端存储卷	临时数据、无状态应用、开发测试环境
Retain	PVC 删除后，PV 保留，后端存储卷不被删除，但 PV 状态变为 `Released`	需要数据持久保留、生产数据库、审计日志

注意： 使用 Retain 策略时，管理员需要手动清理或回收 PV 资源。PV 处于 Released 状态后，无法被新 PVC 直接绑定，需要手动删除 PV 并重新创建，或修改 PV 的 claimRef 字段。

4.4 动态供给流程与绑定模式

动态供给的完整流程涉及 StorageClass、PVC、Provisioner 和 PV 之间的协作。下图展示了从 PVC 创建到 PV 就绪的核心步骤：

4.5 绑定模式：Immediate vs WaitForFirstConsumer

volumeBindingMode 控制 PVC 与 PV 的绑定时机，对存储拓扑感知和调度行为有重要影响。

绑定模式	行为	优势	劣势
Immediate	PVC 创建后立即尝试绑定 PV	绑定速度快，PVC 立即可用	可能绑定到与 Pod 调度节点不同可用区的 PV，导致 Pod 调度失败
WaitForFirstConsumer	延迟到第一个使用 PVC 的 Pod 被调度后才绑定	保证 PV 与 Pod 调度节点在同一可用区，避免跨区调度问题	PVC 状态在 Pod 调度前一直为 Pending

推荐： 在多可用区集群中，始终使用 WaitForFirstConsumer 模式，配合拓扑约束（topology.kubernetes.io/zone）确保存储与计算资源同位置，避免 Pod 因卷挂载失败而无法调度。

4.6 默认 StorageClass 与多 StorageClass 管理

集群中可以存在多个 StorageClass，但只能有一个被标记为 默认（default）。当 PVC 未指定 storageClassName 时，系统自动使用默认 StorageClass。

设置默认 StorageClass 的方法：

kubectl patch storageclass <storageclass-name> -p \
  '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

多 StorageClass 管理的最佳实践：

按性能分层： 定义 fast（SSD）、standard（HDD）、archive（冷存储）等不同 StorageClass。
按后端隔离： 为不同存储系统（如 Ceph、NFS、云厂商块存储）分别定义 StorageClass。
按回收策略区分： 生产环境使用 Retain，开发环境使用 Delete。
命名规范： 使用 <后端类型>-<性能等级> 格式，如 ceph-ssd、aws-gp3。

4.7 动态供给的故障排查要点

当动态供给失败时，常见原因及排查方向如下：

现象	可能原因	排查命令/方法
PVC 一直 Pending	StorageClass 名称错误、Provisioner 未部署、配额不足	`kubectl describe pvc <name>` 查看 Events
PV 创建成功但无法挂载	拓扑约束不匹配、节点驱动未安装	检查 `volumeBindingMode` 和节点 CSI 驱动状态
回收策略未生效	PV 手动修改了 reclaimPolicy	`kubectl get pv <name> -o yaml` 检查实际策略
扩容失败	`allowVolumeExpansion` 未启用或后端不支持	确认 StorageClass 和存储后端均支持在线扩容

  总结： StorageClass 是 Kubernetes 动态存储供给的“配方”。通过合理配置 provisioner、parameters、reclaimPolicy 和 volumeBindingMode，可以实现存储资源的自动化、标准化和拓扑感知管理，是构建生产级云原生存储体系的基础。