什么是 StorageClass?它如何实现动态供给 (Dynamic Provisioning)?
这是一个非常核心的 Kubernetes 存储概念。简单来说,StorageClass 是 Kubernetes 中用于描述存储“类型”或“服务质量”的模板,它是实现动态供给(Dynamic Provisioning)的关键机制。
为了让你彻底理解,我们分两部分来讲:首先是 StorageClass 的概念,然后是它背后的工作流程。
一、 什么是 StorageClass?
在没有 StorageClass 之前(或者在使用静态供给时),管理员需要手动创建每一个存储卷(PV),这就像去餐厅吃饭,厨师(管理员)必须提前把所有菜(PV)都做好摆在那里,顾客(用户/PVC)来了只能选现成的。
StorageClass 就像是一份“菜单”。
管理员不需要提前创建存储卷,而是定义好几种“套餐”:
- Gold Class: 高性能 SSD,价格贵。
- Silver Class: 普通硬盘,价格适中。
- Bronze Class: 廉价存储,用于备份。
当用户需要存储时,只需要在申请单(PVC)里写上“我要一份 Gold 套餐”,Kubernetes 就会根据 StorageClass 的定义,自动去后台(如 AWS、阿里云、Ceph)创建一个对应的存储卷。
StorageClass 的核心字段(YAML 示例)
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: fast-ssd # 菜单的名字
provisioner: kubernetes.io/aws-ebs # 谁来负责做这道菜(供给者)
parameters: # 做菜的具体参数
type: gp2
fsType: ext4
reclaimPolicy: Delete # 吃完后盘子怎么处理(回收策略)
volumeBindingMode: WaitForFirstConsumer # 什么时候开始做菜(绑定模式)
- Provisioner(供给者): 指定使用哪个存储插件来创建卷(例如 AWS EBS、GCE PD、CSI 驱动等)。
- Parameters(参数): 传递给后端存储的具体参数(如 IOPS、副本数、磁盘类型)。
- ReclaimPolicy(回收策略): 当用户删除 PVC 时,底层的 PV 和物理存储怎么处理?通常是
Delete(删除)或Retain(保留)。 - VolumeBindingMode: 决定何时创建和绑定 PV。
Immediate(立即创建)或WaitForFirstConsumer(等到 Pod 被调度后再创建,这对跨可用区部署很重要)。
二、 它如何实现动态供给 (Dynamic Provisioning)?
动态供给是指:当用户创建 PVC 时,集群自动创建 PV 并配置底层存储资源的过程。
工作流程图解
假设用户部署了一个 Pod,需要 10GB 的存储,指定使用名为 fast-ssd 的 StorageClass。
步骤如下:
用户提交请求 (Create PVC):
用户创建一个PersistentVolumeClaim(PVC),在 YAML 中指定storageClassName: fast-ssd和resources.requests.storage: 10Gi。Kubernetes 发现请求:
Kubernetes 的 PersistentVolumeController(运行在 Controller Manager 中)监控到有一个新的 PVC 被创建了,而且它的状态是Pending(未绑定)。查找 StorageClass:
Controller 根据 PVC 中指定的storageClassName找到集群中对应的StorageClass对象(即上面的fast-ssd)。调用 Provisioner (供给者):
Controller 看到 StorageClass 中定义的provisioner(例如 AWS EBS CSI 驱动)。它会向该 Provisioner 发送指令:“嘿,有人要 10GB 的 gp2 磁盘,参数我都给你了,快去创建。”执行物理创建:
Provisioner(通常是 CSI 插件)调用底层云厂商或存储系统的 API(例如调用 AWS API 创建一个 EBS Volume)。创建 PV 对象:
底层存储创建成功后,Provisioner 会在 Kubernetes 集群中自动创建一个 PersistentVolume (PV) 对象。这个 PV 代表了刚才创建的物理磁盘,并且 PV 的 Spec 中会记录它是属于哪个 StorageClass 的。绑定 (Binding):
PersistentVolumeController 发现有一个新的 PV 被创建出来了,而且它完美匹配那个处于 Pending 状态的 PVC。于是,它将 PVC 和 PV 进行绑定(状态变为Bound)。挂载使用:
Pod 启动,通过 PVC 找到 PV,最终将底层的物理磁盘挂载到容器内部。
三、 总结:为什么要用 StorageClass?
| 特性 | 静态供给 (Static Provisioning) | 动态供给 (Dynamic Provisioning) |
|---|---|---|
| 管理员工作量 | 高。必须预先手动创建大量 PV,猜测用户需求。 | 低。只需配置一次 StorageClass,之后全自动。 |
| 资源利用率 | 低。预创建的 PV 如果没人用就是浪费。 | 高。按需创建(On-demand),用多少建多少。 |
| 用户体验 | 差。用户得去查有哪些 PV 可用,或者等管理员干活。 | 好。用户自助服务,申请即得。 |
| 灵活性 | 差。参数固定。 | 强。可以通过参数灵活定义不同的存储层级。 |
一句话总结:
StorageClass 是存储的模板,动态供给是利用这个模板自动化创建存储卷的机制,它们共同实现了 Kubernetes 存储的“自助服务”。