症状
本篇指南处理“Helm 升级失败 — 发布卡在 pending-upgrade”。请从症状出发，按顺序执行诊断，在推进前确认每个假设；随后通过修复与验证步骤闭环。
可观察到的症状包括：
- helm upgrade 失败并提示 “another operation (install/upgrade/rollback) is in progress”
- 发布状态显示 pending-upgrade 或 pending-install
- 上一次升级被中断（超时或被杀）。
诊断
先在隔离环境中复现故障，再按顺序执行以下检查，逐步缩小范围。
步骤 1
helm history <release> -n <ns> && helm status <release> -n <ns>历史会显示需被回滚或取代的 pending 修订。
步骤 2
helm rollback <release> <last-good-revision> -n <ns> --wait回滚到上一个已部署修订可清除锁并恢复已知状态。
常见诱因（按出现频率排序）：
- 先前的升级把发布锁在 pending 状态
- 升级等待资源超时且从未标记完成
- 并发的 CI 任务对同一发布执行了升级
根因
Helm 把发布状态记录在 secret/configmap 中，并在操作处于 pending 时拒绝新操作。被中断的升级会留下 pending 状态，后续操作会被阻塞，直到回滚或解决。
修复
回滚到上一个良好修订，随后使用 –atomic –wait 让失败的升级自动回滚，设置超时，并串行化升级以避免并发任务冲突。
注意：手动删除 pending 发布的 secret 可能破坏 Helm 状态；应优先回滚或受控卸载。
# inspect and recover
helm history myapp -n prod
helm rollback myapp 3 -n prod --wait
# upgrade safely: auto-rollback on failure, wait for readiness
helm upgrade myapp ./chart -n prod \
--atomic --wait --timeout 5m
# serialize upgrades in CI to avoid concurrent locks
# (use a concurrency group / lock in your pipeline)验证
再次运行升级并确认完成；验证 helm history 显示新修订为 deployed。
修复后补充一条回归测试，复现原始症状，防止问题再次出现。
这类故障通常是环境问题而非纯逻辑错误，因此在缺陷记录中应写明完整命令、环境变量与工作目录。请用最小的脚本复现，待最小用例清楚后再扩大范围。为这类故障准备一份简短的排查清单，能显著减少下次排障时间。