📚 课程目录第4章动态供给 vs 静态供给

4. 动态供给 vs 静态供给：动态PV创建流程、静态PV手动绑定场景、优缺点对比

在 Kubernetes 持久化存储体系中，动态供给（Dynamic Provisioning）与静态供给（Static Provisioning）是两种截然不同的 PersistentVolume（PV）生命周期管理方式。动态供给依赖 StorageClass 自动创建 PV，而静态供给由管理员预先手动创建 PV 并等待 Pod 绑定。理解两者的差异是设计生产级存储方案的基础。

4.1 动态供给：自动 PV 创建流程

动态供给的核心思想是按需分配：当用户创建 PersistentVolumeClaim（PVC）时，系统根据 PVC 指定的 StorageClass 自动调用对应的存储后端（如 AWS EBS、GCE PD、NFS 等）创建实际存储卷，并生成 PV 对象与之绑定。整个过程无需管理员干预。

  关键流程步骤：
  管理员预先创建 StorageClass，定义存储后端驱动（provisioner）及参数（如磁盘类型、IOPS、回收策略）。
用户创建 PVC，指定 storageClassName 指向该 StorageClass，并声明所需容量和访问模式。
Kubernetes 控制平面中的 PersistentVolumeController 检测到未绑定的 PVC，根据 storageClassName 找到对应 StorageClass。
Controller 调用 StorageClass 中定义的 provisioner（如 kubernetes.io/aws-ebs），向云存储 API 发起创建卷请求。
存储后端创建实际卷（如 AWS EBS 卷），返回卷 ID 和挂载信息。
系统自动生成 PV 对象，填充容量、访问模式、卷源信息，并与 PVC 完成绑定。
Pod 通过 PVC 挂载该 PV，开始使用持久化存储。

4.2 静态供给：手动 PV 绑定场景

静态供给是 Kubernetes 早期版本及部分特殊场景下的存储供给方式。管理员预先创建一批 PV 对象，每个 PV 对应一个已存在的存储卷（如预先分配的 NFS 共享、iSCSI LUN、本地磁盘等）。用户创建 PVC 后，系统根据容量、访问模式等匹配规则将 PVC 与某个可用 PV 手动或自动绑定。

适用场景：

本地存储：使用本地 SSD 或 HDD 的节点，需要预先规划磁盘分区并创建 PV。
遗留存储系统：已有 NAS/SAN 环境，存储卷已提前分配，只需在 Kubernetes 中注册。
存储配额管控：需要严格限制存储总量，避免动态供给导致的资源超分。
离线或受限环境：无法访问云存储 API 或 provisioner 不可用的私有数据中心。

4.3 核心差异对比

对比维度	动态供给	静态供给
PV 创建方式	自动，由 Provisioner 按需创建	手动，管理员预先创建
依赖组件	StorageClass + Provisioner 驱动	无，仅需 PV 定义
存储资源利用率	高，按需分配，避免浪费	低，可能预分配过多或不足
运维复杂度	低，自动化管理	高，需人工规划与维护 PV 池
适用环境	云原生、动态伸缩场景	本地存储、遗留系统、离线环境
回收策略	由 StorageClass 定义（Delete/Retain）	由 PV 自身定义，通常为 Retain
绑定速度	中等，需等待存储后端创建卷	快，PV 已存在，匹配即绑定

4.4 优缺点深度分析

动态供给

优点：
- 自动化程度高，减少人工操作失误。
- 存储资源按需分配，避免预分配导致的浪费。
- 支持弹性伸缩，PVC 创建即用，删除即回收。
- 与云存储 API 深度集成，支持多种存储类型（SSD、HDD、归档）。
缺点：
- 依赖 StorageClass 和 Provisioner 的可用性与正确配置。
- 云存储 API 调用可能产生额外费用或延迟。
- 在离线或受限环境中无法使用。
- 存储卷的精细控制（如指定特定磁盘路径）较困难。

静态供给

优点：
- 完全可控，管理员可精确指定每个 PV 的后端存储路径。
- 不依赖外部 API 或 Provisioner，适合离线环境。
- 绑定速度快，PV 已预先存在。
- 适合需要固定存储标识（如特定 LUN 或磁盘）的场景。
缺点：
- 运维负担重，需要手动管理 PV 的生命周期。
- 存储资源利用率低，容易造成碎片或浪费。
- 扩展性差，大规模集群下 PV 管理困难。
- PVC 可能因容量或模式不匹配而长时间处于 Pending 状态。

生产建议：在云原生或支持动态供给的环境中，优先使用动态供给。仅在本地存储、遗留系统或严格配额管控场景下使用静态供给。混合部署时，可通过 StorageClass 的 allowedTopologies 和 mountOptions 实现精细控制。

4.5 代码示例：动态与静态配置对比

以下展示动态供给（使用 StorageClass）与静态供给（手动 PV）的典型 YAML 配置差异。

# 动态供给：StorageClass + PVC
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp3
  fsType: ext4
reclaimPolicy: Delete
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: dynamic-pvc
spec:
  storageClassName: fast-ssd
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

# 静态供给：手动创建 PV + PVC
apiVersion: v1
kind: PersistentVolume
metadata:
  name: static-pv
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  nfs:
    path: /data/share1
    server: 192.168.1.100
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: static-pvc
spec:
  storageClassName: ""  # 必须为空字符串，不使用动态供给
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

注意静态供给中 storageClassName: "" 的显式声明，避免系统误用默认 StorageClass 进行动态供给。