1. 课程导论与背景：为什么需要存储变更门禁？灰度发布在 K8s 中的挑战与价值
1.1 存储变更：Kubernetes 中最危险的“静默操作”
在 Kubernetes 生产环境中，存储配置（PersistentVolumeClaim、StorageClass、ConfigMap 挂载路径、StatefulSet volumeClaimTemplates）的变更，是导致数据丢失、Pod 启动失败、IO 性能抖动的头号风险源。与无状态应用的回滚不同，存储变更一旦错误下发，往往无法通过简单的 kubectl rollout undo 恢复——因为底层数据卷的格式、大小、访问模式已经改变。
⚠️ 典型事故场景：某团队在灰度发布中修改了 StatefulSet 的 volumeClaimTemplates.storageClassName，导致新 Pod 绑定了错误的存储后端，旧数据无法挂载，数据库集群半数节点离线 47 分钟。
1.2 为什么需要“存储变更门禁”？
传统 CI/CD 流水线对存储变更缺乏专项校验。Helm Chart 中的 values.yaml 或模板逻辑可能引入以下隐患：
| 隐患类型 | 具体表现 | 后果等级 |
|---|---|---|
| StorageClass 不存在 | PVC 一直 Pending，无法调度 | 严重 |
| 访问模式降级 | ReadWriteOnce → ReadOnlyMany 导致应用崩溃 | 严重 |
| 存储容量缩容 | PVC 无法缩小，Helm 升级失败 | 中等 |
| 卷挂载路径冲突 | 多个容器挂载同一路径覆盖数据 | 严重 |
| fsGroup / 权限变更 | 已有数据无法写入，Pod CrashLoopBackOff | 中等 |
存储变更门禁是一组在 Helm 安装/升级前执行的准入检查规则，它拦截上述隐患，确保只有经过验证的存储配置才能进入灰度发布流程。
1.3 灰度发布在 K8s 中的核心挑战
Kubernetes 原生支持 Deployment 的滚动更新，但灰度发布（Canary / Blue-Green）在存储层面面临独特难题：
- 有状态副本集无法简单灰度：StatefulSet 的 Pod 名称和 PVC 绑定是固定的，灰度新版本无法直接使用旧 PVC，容易造成数据分裂。
- Helm 升级的原子性不足：
helm upgrade默认一次性替换所有资源，无法按百分比逐步推送存储变更。 - 回滚成本极高：存储变更一旦写入 etcd，回滚时需要手动清理 PVC、恢复快照，无法通过
helm rollback自动完成。 - 多环境配置漂移：开发/测试/生产环境的 StorageClass 名称、卷大小、回收策略不同，灰度发布时容易误用环境特定配置。
💡 核心价值：本课程将构建一套 Helm 预检 + 准入 Webhook + 灰度策略引擎 的组合方案，在存储变更进入集群之前完成校验，并在灰度发布过程中动态控制变更范围。
1.4 存储变更门禁在灰度发布中的位置
下图展示了存储变更门禁在 Helm 灰度发布流水线中的关键位置：
1.5 本课程的技术栈与交付物
| 模块 | 技术组件 | 交付物 |
|---|---|---|
| 存储变更门禁 | Helm 插件 + OPA Rego 策略 | 可复用的策略库（10+ 规则） |
| 灰度发布引擎 | Flagger / Argo Rollouts + Helm Hooks | 灰度发布模板与 Pipeline 配置 |
| 准入 Webhook | ValidatingAdmissionPolicy / Kyverno | 集群级准入检查 YAML 清单 |
| 监控与告警 | Prometheus + Grafana + Alertmanager | 存储变更事件仪表盘 |
1.6 谁应该学习本课程？
- SRE / 平台工程师：需要为有状态工作负载设计安全的变更流程。
- Kubernetes 管理员：希望强化集群的存储安全基线，防止误操作。
- DevOps 工程师：正在构建或优化 Helm 驱动的 CI/CD 流水线。
- 架构师：评估灰度发布方案在存储密集型场景下的可行性。
📌 前置要求：熟悉 Helm 基本操作（install/upgrade/rollback）、Kubernetes 存储原语（PVC/PV/StorageClass）、以及基本的 YAML 编写能力。无需精通 OPA 或 Flagger，课程会从零搭建。