📚 课程目录第2章 K8s存储基础回顾

2. K8s存储基础回顾：PV、PVC、StorageClass概念与生命周期，以及它们与变更门禁的关系

2.1 为什么存储是变更门禁的第一道关卡

在Kubernetes集群中，存储资源（PersistentVolume、PersistentVolumeClaim、StorageClass）是有状态应用的基石。任何对存储配置的变更——无论是扩容、迁移、回收策略调整，还是StorageClass参数修改——都直接影响数据安全与业务连续性。变更门禁系统必须首先理解这三类资源的生命周期与依赖关系，才能设计出有效的校验与回滚策略。

  核心观点：PV/PVC/StorageClass 构成了 K8s 存储的“声明式供给链”。变更门禁需要在这条链的每个环节插入校验点，防止“改一个参数导致数据丢失”或“扩容后无法回滚”。

2.2 三大核心概念速览

概念	全称	本质	生命周期关键点
PV	PersistentVolume	集群级别的存储资源（由管理员或存储插件预置）	创建 → Available → Bound → Released → Failed
PVC	PersistentVolumeClaim	用户对存储的请求（大小、访问模式、StorageClass）	创建 → Pending → Bound → 删除（释放PV）
SC	StorageClass	存储模板（定义 provisioner、参数、回收策略、绑定模式）	创建 → 动态供给PVC时引用 → 删除（影响未绑定PVC）

门禁视角：PV 的 ReclaimPolicy（Retain/Delete/Recycle）是回滚判断的关键——如果 PV 被删除且策略为 Delete，底层存储可能已销毁，回滚将无法恢复数据。

2.3 生命周期与状态机

PV 和 PVC 的生命周期是绑定驱动的。变更门禁必须跟踪以下状态转换：

PV 状态机：Available → Bound → Released → Failed（Failed 状态通常意味着底层存储异常，此时应阻止任何写入变更）。
PVC 状态机：Pending → Bound → Lost（Lost 表示绑定的 PV 被删除或异常，此时 PVC 无法再使用）。
StorageClass 影响：动态供给时，PVC 引用 SC 自动创建 PV；静态供给时，PV 需手动匹配 PVC 的 label/selector。

2.4 变更门禁在存储生命周期中的校验点

基于上述生命周期，变更门禁系统应在以下关键节点插入校验逻辑：

变更类型	校验点	门禁动作	回滚可行性
PV 扩容	PV 状态必须为 Bound，且底层存储支持在线扩容	校验 CSI 驱动能力，拒绝扩容不兼容的 PV	高（保留旧容量快照）
PVC 删除	检查 PV 的 ReclaimPolicy	若为 Delete，强制备份或阻止删除	低（数据可能已销毁）
StorageClass 参数修改	检查是否有未绑定的 PVC 引用该 SC	允许修改，但标记旧 PVC 为“待迁移”	中（需重建 PVC）
PV 回收策略变更	PV 状态必须为 Released 或 Available	禁止在 Bound 状态下修改 ReclaimPolicy	高（策略可回退）

常见陷阱：很多团队在变更门禁中只校验 PVC 的 storage 字段是否增大，却忽略了 PV 的 volumeMode（Filesystem vs Block）和 accessModes（ReadWriteOnce vs ReadWriteMany）是否兼容。这些参数一旦变更，回滚时可能无法重新绑定旧 PV。

2.5 存储变更回滚的三大原则

数据优先：任何存储变更前，必须确保有可恢复的备份或快照。回滚操作不能依赖“改回 YAML”就恢复数据。
状态可逆：只允许对处于 Bound 或 Released 状态的 PV 执行回滚；Failed 状态的 PV 需要人工介入。
依赖链完整：回滚 PV 时，必须同时回滚引用它的 PVC 和 Pod，否则会出现“PV 已回滚但 Pod 仍挂载旧路径”的不一致状态。

2.6 实战示例：变更门禁校验 StorageClass 参数

以下是一个简化的门禁校验逻辑（伪代码），展示如何拦截不合规的 StorageClass 变更：

# 变更门禁校验函数：StorageClass 参数修改
def validate_storageclass_change(old_sc, new_sc):
    # 1. 检查 provisioner 是否变更（通常不允许）
    if old_sc.provisioner != new_sc.provisioner:
        return False, "provisioner 不可变更，请创建新的 StorageClass"
    
    # 2. 检查 reclaimPolicy 是否从 Retain 改为 Delete
    if old_sc.reclaimPolicy == "Retain" and new_sc.reclaimPolicy == "Delete":
        # 检查是否有已绑定的 PVC
        bound_pvcs = get_bound_pvcs_by_sc(old_sc.name)
        if bound_pvcs:
            return False, f"存在 {len(bound_pvcs)} 个已绑定 PVC，禁止将回收策略从 Retain 改为 Delete"
    
    # 3. 检查 allowVolumeExpansion 是否从 true 改为 false
    if old_sc.allowVolumeExpansion and not new_sc.allowVolumeExpansion:
        return False, "不允许关闭卷扩容，已有 PVC 可能正在扩容中"
    
    return True, "校验通过"

课程提示：在实际生产环境中，StorageClass 的 parameters 字段（如 type、iopsPerGB）变更后，已创建的 PV 不会自动更新。门禁系统需要额外校验“是否所有引用该 SC 的 PV 都已迁移到新 SC”，否则会导致存储性能或容量不匹配。

2.7 本章小结

PV、PVC、StorageClass 是 K8s 存储的三大支柱，变更门禁必须理解它们的生命周期状态机。
每个状态转换（Available→Bound→Released→Failed）都是潜在的校验点和回滚边界。
回滚判断的核心是数据可恢复性和依赖链完整性，而非简单的 YAML 版本回退。
StorageClass 参数变更影响范围最广，门禁系统应优先拦截高风险变更（如回收策略从 Retain 改为 Delete）。