📚 课程目录第4章门禁压测沙盘架构设计

4. 变更门禁概念：什么是门禁、为什么需要门禁、门禁的触发条件

4.1 什么是变更门禁

在 Kubernetes 存储领域，变更门禁是一组自动化的前置检查规则与执行引擎，部署在 CI/CD 流水线或运维编排系统中。它拦截所有针对 PVC、StorageClass、PV 及其依赖组件的变更请求，在变更真正生效前完成一系列验证、压测与容量评估，只有通过全部检查的变更才能被放行。

  核心定义：变更门禁 = 准入控制 + 压测验证 + 容量预测 + 回滚预案。它不是单一工具，而是一套可编程的变更安全策略。

门禁系统通常以 Webhook、Operator 或 Pipeline Gate 的形式嵌入集群。下图展示了门禁在变更流程中的位置：

4.2 为什么需要变更门禁

K8s 存储变更的风险等级远高于普通应用变更。一次错误的 PVC 扩容、StorageClass 参数调整或 PV 回收策略修改，可能导致数据丢失、性能雪崩或整个存储池不可用。以下表格总结了无门禁环境下的典型事故模式：

变更类型	无门禁风险	影响范围	恢复难度
PVC 容量缩容	文件系统损坏、数据截断	单个应用	高（需从备份恢复）
StorageClass 参数变更	新 PVC 使用错误配置，性能不达标	集群级	中（需重建 PVC）
PV 回收策略切换	PV 被意外删除，底层存储卷丢失	跨命名空间	极高（数据不可恢复）
存储后端升级	IO 路径中断、协议不兼容	集群级	高（需回滚后端）
批量 PVC 创建	存储池容量耗尽，影响已有卷	集群级	中（需紧急扩容）

关键认知：存储变更的“回滚”通常不是简单的 kubectl apply -f 旧版本。PV 的底层数据、CSI 驱动的状态、存储后端的快照链都可能无法原子回滚。门禁的价值在于 阻止不可逆的变更进入集群。

除了防止事故，门禁还带来以下收益：

标准化变更流程：所有存储变更必须经过相同的检查集，消除人为疏漏。
容量风险前置：在变更前预测存储池容量变化，避免“变更后才发现磁盘满”。
性能基线保障：通过压测沙盘验证变更后的 IO 性能是否满足 SLO。
审计与合规：每次变更的检查结果、压测数据、审批记录自动留存。

4.3 门禁的触发条件

门禁不是对所有集群事件都触发。过度触发会导致流水线阻塞，触发不足则失去保护意义。合理的触发条件应覆盖以下维度：

4.3.1 按资源类型触发

K8s 资源	触发操作	门禁检查重点
PersistentVolumeClaim	CREATE / UPDATE / DELETE	容量合法性、StorageClass 存在性、AccessModes 兼容性
StorageClass	CREATE / UPDATE / DELETE	provisioner 可用性、参数合规、回收策略影响
PersistentVolume	CREATE / UPDATE / DELETE	容量与后端映射、回收策略、状态一致性
VolumeSnapshot / VolumeSnapshotClass	CREATE / DELETE	快照配额、后端兼容性、保留策略
CSI Driver / CSINode	UPDATE / DELETE	驱动版本兼容、节点拓扑影响

4.3.2 按变更特征触发

容量变更：PVC 扩容超过阈值（如单次扩容 > 100Gi）、缩容请求（默认拒绝）。
参数变更：StorageClass 的 allowVolumeExpansion、mountOptions、parameters 等关键字段变化。
批量变更：同一时间窗口内 PVC 创建/删除数量超过集群容忍上限（如 > 50 个/分钟）。
跨集群变更：涉及多个集群的存储配置同步，需要全局一致性检查。
非工作时段变更：在定义的变更窗口之外提交的存储变更，触发增强检查或人工审批。

4.3.3 按环境与上下文触发

上下文条件	触发门禁级别	典型配置
生产集群	强制（不可跳过）	全量检查 + 压测 + 容量预测 + 人工审批
预发/灰度集群	强制（可跳过部分检查）	全量检查 + 压测（可降级）
测试/开发集群	可选（默认开启）	基础检查 + 容量预测
紧急变更（hotfix）	强制（快速通道）	最小检查集 + 事后补压测

最佳实践：门禁触发条件应配置为 白名单模式——默认拦截所有存储变更，仅对明确标记为“安全”的变更放行。这比黑名单模式（仅拦截已知风险）更安全。

下图展示了门禁触发条件的决策树：

4.4 门禁触发条件配置示例

以下是一个基于 YAML 的门禁规则配置片段，展示了如何定义触发条件：

apiVersion: storage-gate.example.com/v1
kind: ChangeGate
metadata:
  name: pvc-change-gate
spec:
  # 触发资源类型
  targetResources:
    - apiGroup: ""
      resources: ["persistentvolumeclaims"]
      operations: ["CREATE", "UPDATE"]
    - apiGroup: "storage.k8s.io"
      resources: ["storageclasses"]
      operations: ["CREATE", "UPDATE", "DELETE"]

  # 触发特征条件
  conditions:
    - name: "capacity-change"
      field: "spec.resources.requests.storage"
      operator: "Change"
      threshold: "100Gi"  # 单次容量变更超过 100Gi 触发
    - name: "shrink-detection"
      field: "spec.resources.requests.storage"
      operator: "Decrease"  # 任何缩容操作都触发
    - name: "batch-create"
      field: "metadata.namespace"
      operator: "RateLimit"
      threshold: 50  # 每分钟超过 50 个 PVC 创建触发

  # 环境上下文
  environment:
    - name: "production"
      clusters: ["prod-*"]
      mode: "enforce"
      requireApproval: true
    - name: "staging"
      clusters: ["stg-*"]
      mode: "enforce"
      requireApproval: false
    - name: "development"
      clusters: ["dev-*"]
      mode: "optional"
      skipOnLabel: "gate.skip=true"

配置要点：

触发条件应分层设计：资源层 → 特征层 → 环境层，每层可独立配置。
容量缩容应默认拒绝，除非有明确的“强制缩容”标签和人工审批。
批量操作建议使用令牌桶算法限流，避免门禁系统自身被击穿。
生产环境门禁应设置为不可跳过（enforce），即使紧急变更也需走快速通道。