动态存储分配用StorageClass消除人工预分配这个中间层

[[PersistentVolume与Claim的双向声明设计分离运维与开发的关注点]]描述的 静态存储分配（Static Provisioning）有个自动化短板：Pod挂载某个Volume 时要求它必须真实存在，而Kubernetes能自动扩缩Pod数量，一旦自动扩出新 Pod，却没办法让它自动挂载一个还没被分配的PersistentVolume——要么让 多个Pod共用同一个PVC（牺牲隔离性），要么要求管理员提前手工建好所有 可能用到的PV（牺牲自动化），两条路都不符合工业级编排系统的定位。2017 年Kubernetes 1.6引入动态存储分配（Dynamic Provisioning）：用户声明 存储需求时，不再靠系统撮合一个人工预置好的PV，而是由StorageClass资源 指定的资源分配器（Provisioner）自动在存储池或云存储系统里按需创建 符合要求的PV。管理员的工作从”手工建好一堆PV等着被认领”变成”配置好 StorageClass告诉系统该用哪个Provisioner”；用户依然通过PVC声明需求， 但要指明用哪个StorageClass处理。这样PersistentVolume这个概念对最终 用户变得完全不可见——它只是处理过程里的中间产物，用户只需要知道PVC 描述需求、StorageClass满足需求，这正是”只描述意图、不关心中间过程” 这条声明式API精髓的具体体现。动态分配还带来更精细的可管理性——比如 回收策略不再依赖粗暴的Recycle（rm -rf），而是交给Provisioner的代码 去实现更精细的删除逻辑，Kubernetes官方现已建议废弃Recycle策略。静态 分配没有被完全取代，只是收缩到管理员能手工管理的小型集群这个场景里， 更像是对历史的一种兼容而非并列的解决方案。

结构图：

flowchart LR
    A[管理员配置StorageClass] --> B[用户创建PVC并指定StorageClass]
    B --> C[StorageClass接管撮合工作]
    C --> D[调用Provisioner自动在存储系统创建PV]
    D --> E[PV挂载给Pod, 对用户不可见]