2. Helm 基础回顾：Chart 结构、Release 概念、Helm install/upgrade/rollback 命令

在深入 Serverless 回退策略之前，必须重新夯实 Helm 的核心基础。Helm 是 Kubernetes 的包管理工具，它将应用及其依赖打包为 Chart，并通过 Release 机制管理部署的生命周期。理解这三者——Chart 结构、Release 概念、核心命令——是后续实现精细化回退的前提。

2.1 Chart 目录结构

一个标准的 Helm Chart 是一个遵循特定布局的目录集合。以下是最小化且最常用的结构：

my-serverless-app/
├── Chart.yaml          # 元数据：名称、版本、API 版本、描述
├── values.yaml         # 默认配置值，用户可覆盖
├── values.schema.json  # (可选) values.yaml 的 JSON Schema 校验
├── charts/             # (可选) 子 Chart 依赖
├── templates/          # 核心：Go 模板文件，渲染后生成 Kubernetes 资源
│   ├── deployment.yaml
│   ├── service.yaml
│   ├── _helpers.tpl    # (可选) 模板辅助函数
│   └── tests/          # (可选) 测试 Pod 模板
└── README.md           # (可选) 使用说明

2.2 Release 概念

Release 是 Helm 管理的核心抽象。它代表 Chart 在 Kubernetes 集群中的一次独立部署实例。每次执行 helm install 或 helm upgrade 都会创建一个新的 Release 版本（Revision）。

2.3 核心命令：install / upgrade / rollback

这三个命令构成了 Helm 部署与回退的完整闭环。下面通过一个 Serverless 函数部署示例来演示：

2.3.1 helm install

首次部署一个 Serverless 函数到集群：

# 安装名为 "my-fn" 的 Release，使用 ./chart 目录，覆盖副本数为 2
helm install my-fn ./chart --set replicaCount=2 --set image.tag=v1.0.0

2.3.2 helm upgrade

更新已存在的 Release。这是回退发生前的“正常操作”：

# 升级 my-fn 到 v1.1.0，并增加环境变量
helm upgrade my-fn ./chart --set image.tag=v1.1.0 --set env.DEBUG=true

每次 upgrade 都会创建一个新的 Revision（例如从 1 变为 2）。

2.3.3 helm rollback

回退到之前的某个 Revision。这是本课程的核心操作：

# 回退到 Revision 1（即 v1.0.0 的状态）
helm rollback my-fn 1

2.4 Helm 回退流程示意图

下图展示了从安装到回退的完整 Revision 生命周期：

2.5 回退时的关键行为

• Revision 递增： 回退操作本身也会创建一个新的 Revision（例如从 Rev 2 回退到 Rev 1，会生成 Rev 3）。这保证了历史记录的完整性。
• Values 恢复： 回退会完全恢复目标 Revision 的 values.yaml 内容。如果目标 Revision 使用了 --set 参数，这些参数也会被恢复。
• Pod 重建： 默认情况下，helm rollback 会触发 Deployment 的滚动更新，导致 Pod 重建。可以使用 --recreate-pods 强制重建。
• 回退失败处理： 如果回退后的 Pod 无法启动（例如镜像拉取失败），Helm 会标记 Release 为 FAILED 状态，需要手动干预。