如何在K8s中利用Helm升级应用与回滚历史版本的操作

在 Kubernetes 中用 Helm 升级应用和回滚版本，核心是围绕 release 的生命周期管理：每次 helm upgrade 会生成新版本（revision），Helm 自动保留历史记录，helm rollback 则按 revision 号恢复到指定状态。

升级应用：helm upgrade 常用方式

升级本质是用新 Chart 或新参数覆盖当前 release。关键点在于是否创建新 revision：

默认行为：执行 helm upgrade myapp ./mychart -f values-prod.yaml 会生成新 revision（如从 3 → 4），旧版本保留在历史中 强制跳过校验：加 –force 可替换失败的 release（例如因资源冲突卡住），但不推荐日常使用 跳过 pre-upgrade hook：加 –no-hooks 避免重复执行初始化任务（如数据库迁移） 仅更新值文件：用 –reuse-values 保留上次安装时的 values，只覆盖传入的新 values 文件

查看版本历史：helm history 与 status

每个 release 的修订记录是回滚的前提，需先确认可用 revision：

helm history myapp 显示所有 revision、状态（deployed/superseded/failed）、更新时间及描述 helm status myapp 查看当前部署状态、所用 Chart 版本、values 摘要，以及最近一次操作的 revision 号 注意：revision 是单调递增整数，但“superseded”状态表示该版本已被后续升级覆盖，仍可回滚

回滚到指定版本：helm rollback 实操要点

回滚不是“撤销升级”，而是重新部署某个历史 revision 对应的 Chart 和 values：

基本命令：helm rollback myapp 2 回滚到 revision 2（对应当时部署的 Chart + values） 限制重试次数：加 –timeout 300 设置等待 Pod 就绪超时（单位秒） 跳过 hooks：加 –no-hooks 避免再次触发 post-install 类 hook（防止重复清理或通知） 回滚后自动产生新 revision：比如从 r5 回滚到 r3，结果是 r6 = r3 的完整复现，r5 状态变为 superseded

清理旧版本（可选）：控制历史保留数量

revision 过多会增大 Tiller/Release 存储压力（尤其 Helm 2）；Helm 3 默认存于 kube-apiserver，也建议合理限制：

安装/升级时设置：helm install myapp ./chart –history-max 10 或 helm upgrade myapp ./chart –history-max 10 全局配置（Helm 3）：在 $HELM_CONFIG_HOME/settings.yaml 中设 history_max: 10 手动清理不可用 revision：目前无直接命令删除某 revision，只能靠 –history-max 自动轮转淘汰