Helm3升级报错存在进行中操作，但上次部署已成功

通过helm 2to3 convert -t tiller-admin my-dev将my-app从Helm2迁移至Helm3后，出现以下异常：每次执行Helm3升级时，首次操作会报错**“存在另一个安装/升级/回滚操作正在进行”**，但helm history和helm list均显示上次部署已成功；重试相同升级操作则可成功，且该现象每次发布都会出现。

操作步骤及相关信息 #

1. 查看Helm历史 #

执行命令：

# Step 1 - Print helm history
$ helm history --max 20 -n my-dev -o=json my-dev

返回结果显示存在失败版本，但最新版本（revision 16）状态为deployed：

[
  {
    "revision": 1,
    "updated": "2024-05-07T22:16:45.173783972Z",
    "status": "superseded",
    "chart": "my-app-0.0.81",
    "app_version": "0.0.81",
    "description": "Install complete"
  },
  {
    "revision": 2,
    "updated": "2024-05-07T23:40:22.72498084Z",
    "status": "failed",
    "chart": "my-app-0.0.81",
    "app_version": "0.0.81",
    "description": "Upgrade \"my-dev\" failed: cannot patch \"app-job\" with kind Job: Job.batch \"app-job\" is invalid: spec.template: Invalid value: .... field is immutable"
  },
  ...
  {
    "revision": 16,
    "updated": "2024-05-09T23:57:31.753789231Z",
    "status": "deployed",
    "chart": "my-app-0.0.81",
    "app_version": "0.0.81",
    "description": "Upgrade complete"
  }
]

2. 执行Helm升级 #

执行命令：

# Step 2 - Helm upgrade
$ helm upgrade --namespace=my-dev --version=0.0.81 --values=my-dev/values.yaml --install my-dev org/my-app --debug --cleanup-on-fail --wait --timeout='7200s' --history-max 20

报错信息：

upgrade.go:142: [debug] preparing upgrade for my-dev
Error: UPGRADE FAILED: another operation (install/upgrade/rollback) is in progress
helm.go:84: [debug] another operation (install/upgrade/rollback) is in progress
helm.sh/helm/v3/pkg/action.init
    helm.sh/helm/v3/pkg/action/action.go:62
...
runtime.goexit
    runtime/asm_amd64.s:1581

3. 查看Helm列表 #

➜  ~ helm list -a -n my-dev
NAME    NAMESPACE REVISION  UPDATED                                   STATUS    CHART           APP VERSION
my-dev  my-dev    16        2024-05-09  23:57:31.753789231 +0000 UTC    deployed    my-app-0.0.81     0.0.81

4. 相关Secret信息 #

➜  ~ kubectl get secret -n my-dev
NAME                                          TYPE                 DATA   AGE
sh.helm.release.v1.my-dev.v1    helm.sh/release.v1   1      2d2h
sh.helm.release.v1.my-dev.v2    helm.sh/release.v1   1      2d1h
...
sh.helm.release.v1.my-dev.v16   helm.sh/release.v1   1      51m

疑问 #

• 为何Helm认为存在进行中操作？
• 应从何处排查？
• 为何首次失败重试却成功？

问题原因及排查方案 #

1. 核心原因：Helm状态锁残留 #

Helm 3通过sh.helm.release.v1.<release-name>.v<revision>类型的Secret存储发布状态，迁移过程中可能存在未正确清理的半状态锁：

• 检查最新release Secret的状态字段，确认是否有中间状态残留：

  kubectl get secret sh.helm.release.v1.my-dev.v16 -n my-dev -o jsonpath='{.data.release}' | base64 -d | jq '.info.status'
  

• 迁移时Helm 2to3工具可能未完全同步Helm 2的历史状态，导致部分失败版本的锁标记未被清理。

2. 排查及修复步骤 #

（1）清理失败版本的状态记录

历史中存在revision 2这类失败升级记录，会干扰Helm的状态判断，可手动清理：

# 回滚到最新成功版本并清理失败状态
helm rollback my-dev 16 -n my-dev --cleanup-on-fail

# 或直接删除旧的失败版本Secret
kubectl delete secret sh.helm.release.v1.my-dev.v2 -n my-dev

（2）修复Job资源的immutable字段冲突

从历史报错看，曾出现Job的spec.template字段不可变错误，这会导致升级中断且状态未正确回滚：

• 修改Chart中的Job定义，避免升级时修改spec.template字段；
• 或为Job添加基于版本号的唯一后缀，让每次升级创建新Job而非修改旧Job；
• 紧急情况下可使用helm upgrade --force强制覆盖（需注意资源冲突风险）。

3. 重试成功的原因 #

首次升级时，Helm检测到残留的状态锁或中间状态，触发安全拦截；重试时，Helm会重新校验状态，自动清理过期锁标记或同步状态，因此操作可以成功。

内容的提问来源于stack exchange，提问作者Sumitk