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

3. StorageClass 与动态供给：原理、Provisioner 类型与工作流程

在 Kubernetes 存储体系中，StorageClass 是连接管理员存储资源与用户动态需求的桥梁。它定义了存储的“类别”和“供给策略”，使得用户无需预先创建 PV，而是通过 PVC 声明需求后，系统自动完成 PV 的创建与绑定。这一机制被称为动态供给（Dynamic Provisioning），是云原生环境下实现存储弹性与成本优化的核心基础。

3.1 StorageClass 原理与核心字段

StorageClass 是一个集群级别的 API 资源，它描述了管理员可提供的存储类型及其行为参数。当 PVC 指定了某个 StorageClass 时，Kubernetes 会调用对应的 Provisioner 插件，按照 StorageClass 中定义的规则动态创建 PV。

字段	说明	典型值 / 示例
`provisioner`	指定用于创建 PV 的存储后端插件	`kubernetes.io/aws-ebs`, `rook-ceph.rbd.csi.ceph.com`
`parameters`	传递给 Provisioner 的存储参数，如类型、IOPS、副本数	`type: gp3`, `replication: 3`
`reclaimPolicy`	PV 被释放后的回收策略	`Delete`（默认）, `Retain`
`allowVolumeExpansion`	是否允许后续扩容 PVC 的存储容量	`true`, `false`
`mountOptions`	挂载时附加的选项	`["discard"]`, `["noatime"]`
`volumeBindingMode`	控制 PV 绑定与调度的时机	`Immediate`, `WaitForFirstConsumer`

成本优化提示： 在生产环境中，建议为不同性能与成本层级定义多个 StorageClass。例如：fast-ssd（高 IOPS，用于数据库）、standard-hdd（低成本，用于日志归档）、encrypted-gp3（加密盘，用于合规场景）。通过 PVC 选择不同的 StorageClass，实现按需付费。

3.2 Provisioner 类型与生态

Provisioner 是 StorageClass 的核心执行组件，负责与底层存储系统交互并创建实际的存储卷。根据部署位置和实现方式，Provisioner 主要分为以下三类：

内置 Provisioner（In-Tree）： 随 Kubernetes 核心组件一起发布，如 kubernetes.io/aws-ebs、kubernetes.io/gce-pd、kubernetes.io/azure-disk。优点是开箱即用，但更新迭代较慢，逐渐被 CSI 取代。
CSI Provisioner（Container Storage Interface）： 通过 CSI 驱动实现，是当前主流标准。例如 ebs.csi.aws.com、rbd.csi.ceph.com、nfs.csi.k8s.io。支持热插拔、功能丰富、社区活跃。
第三方 / 自定义 Provisioner： 基于 Kubernetes 的 Provisioner 接口自行开发，适用于私有存储或特殊协议。例如 rook-ceph.rbd.csi.ceph.com、openebs.io/local。

类型	代表 Provisioner	适用场景	维护方式
内置（In-Tree）	`kubernetes.io/aws-ebs`	传统集群、快速验证	Kubernetes 社区
CSI	`ebs.csi.aws.com`	生产环境、多云、高级功能	云厂商 / 存储厂商
自定义	`openebs.io/local`	本地存储、边缘、私有云	第三方社区 / 自研

迁移建议： 从 Kubernetes 1.21 开始，In-Tree 卷插件逐步被弃用。新集群应优先使用 CSI Provisioner，以获得更好的稳定性、快照、扩容和加密支持。

3.3 动态创建 PV 的工作流程

当用户创建一个指定了 StorageClass 的 PVC 时，Kubernetes 内部会触发一个完整的工作流，从 PVC 提交到 PV 就绪。下图展示了这一流程的核心步骤：

上述流程可拆解为以下关键步骤：

用户提交 PVC： 在 PVC 的 spec.storageClassName 字段中指定一个已存在的 StorageClass。
API Server 持久化： PVC 对象被写入 etcd，状态为 Pending。
PV Controller 检测： 集群中的 PV Controller 持续 watch 未绑定的 PVC，发现该 PVC 没有匹配的现成 PV，且指定了 StorageClass。
调用 Provisioner： Controller 根据 StorageClass 中的 provisioner 字段，调用对应的 Provisioner 插件，并传入 parameters 中的参数。
存储后端创建卷： Provisioner 与底层存储系统（如 AWS EBS、Ceph RBD、NFS 服务器）通信，创建实际的存储卷，并返回卷的唯一标识（VolumeHandle）。
创建 PV 并绑定： Controller 自动创建一个 PV 对象，其 spec.csi.volumeHandle 指向刚创建的卷，并将该 PV 与 PVC 绑定。PVC 状态变为 Bound。
Pod 使用： Pod 通过 PVC 挂载该卷，开始读写数据。

3.4 关键参数详解：volumeBindingMode

volumeBindingMode 控制 PV 的创建和绑定时机，对调度性能和存储成本有直接影响。

模式	行为	适用场景	成本影响
`Immediate`	PVC 创建后立即创建 PV 并绑定，不考虑 Pod 调度	所有节点都能访问的共享存储（如 NFS）	可能创建了 PV 但 Pod 尚未调度，造成闲置计费
`WaitForFirstConsumer`	延迟到第一个使用该 PVC 的 Pod 被调度时，才创建 PV 并绑定	拓扑受限存储（如 AWS EBS 只能挂载到同可用区节点）	避免闲置卷，精准匹配 Pod 所在节点，降低浪费

  成本优化最佳实践： 对于云厂商的块存储（如 AWS EBS、Azure Disk），务必使用 WaitForFirstConsumer 模式。这可以确保 PV 与 Pod 在同一可用区创建，避免跨可用区数据传输费用，同时减少因 Pod 未调度而提前创建卷导致的闲置成本。

3.5 实战示例：定义并使用 StorageClass

以下是一个完整的 YAML 示例，展示如何定义 StorageClass、创建 PVC 并触发动态供给：

---
# 1. 定义 StorageClass
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
provisioner: ebs.csi.aws.com
parameters:
  type: gp3
  iops: "3000"
  throughput: "125"
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer
---
# 2. 创建 PVC 引用该 StorageClass
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-data
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 100Gi
  storageClassName: fast-ssd
---
# 3. Pod 使用 PVC
apiVersion: v1
kind: Pod
metadata:
  name: mysql
spec:
  containers:
  - name: mysql
    image: mysql:8.0
    volumeMounts:
    - mountPath: /var/lib/mysql
      name: data
  volumes:
  - name: data
    persistentVolumeClaim:
      claimName: mysql-data

执行 kubectl apply -f 后，系统会自动完成 PV 的创建与绑定。通过 kubectl get pv 可以查看动态创建的 PV 及其关联的 StorageClass。

验证命令：
kubectl get sc — 查看集群中所有 StorageClass
kubectl describe sc fast-ssd — 查看 StorageClass 详情
kubectl get pvc mysql-data — 查看 PVC 状态（应显示 Bound）
kubectl get pv | grep fast-ssd — 查看动态创建的 PV

3.6 成本优化要点总结

多级 StorageClass 设计： 按性能、容量、加密需求定义多个 StorageClass，让不同工作负载选择最合适的存储层级，避免“一刀切”导致成本浪费。
合理设置 reclaimPolicy： 对于临时数据或开发环境，使用 Delete 策略，PVC 删除时自动清理 PV，避免残留卷产生费用。对于重要数据，使用 Retain 策略手动处理。
启用 allowVolumeExpansion： 允许 PVC 在线扩容，避免因容量预估不足而频繁重建 PV，减少存储碎片和运维成本。
使用 WaitForFirstConsumer： 避免提前创建 PV 导致的闲置计费，同时优化拓扑亲和性，减少跨可用区流量费用。