После helm upgrade с ошибочным значением в values.yaml релиз Kubernetes-приложения застрял в состоянии pending-upgrade, и повторные попытки helm upgrade с исправленными значениями завершаются ошибкой another operation (install/upgrade/rollback) is in progress. Что означает это состояние, как из него безопасно выйти, и как работает helm rollback для возврата к последней рабочей версии?

Короткий ответ

Состояние pending-upgrade означает, что Helm начал операцию upgrade, записал в свою историю релиза (Secrets/ConfigMaps в кластере) новую ревизию как "в процессе", но сама операция не была доведена до конца (например, упал pre/post-upgrade hook или процесс был прерван); чтобы выйти из застрявшего состояния, в современных версиях Helm 3 используется helm rollback <release> <revision>, который переводит релиз на конкретную прошлую ревизию, либо (если rollback невозможен из-за битой истории) аккуратно правится статус релиза в secret Helm вручную — но такой ручной способ рискованный и используется только как последнее средство.

Как это работает подробнее

Helm хранит историю релизов как отдельные объекты (по умолчанию Kubernetes Secrets) с манифестом и статусом каждой ревизии; при upgrade создаётся новая ревизия со статусом pending-upgrade, и только по завершении применения манифестов и всех хуков статус меняется на deployed, а предыдущая ревизия — на superseded; если процесс прерывается до этого перехода, статус pending-upgrade остаётся висеть и блокирует новые операции до тех пор, пока явно не выполнить rollback (который создаёт новую ревизию с манифестом старой) или не вмешаться вручную.

Пример кода

commands.shКопировать

$ helm upgrade myapp ./chart -f values.yaml
Error: UPGRADE FAILED: another operation (install/upgrade/rollback) is in progress
$ helm history myapp
REVISION  STATUS           CHART
3         pending-upgrade  myapp-1.4.0
2         deployed         myapp-1.3.0
$ helm rollback myapp 2
Rollback was a success! Happy Helming!
$ helm upgrade myapp ./chart -f values-fixed.yaml --atomic --timeout 5m

Что использовать на практике

• Практика. перед следующим upgrade после сбоя полезно посмотреть helm history <release> и helm status <release>, чтобы понять, какая ревизия последняя рабочая, и явно откатиться на неё, а не пытаться сразу накатить новый upgrade поверх зависшего состояния; для критичных релизов стоит использовать --atomic (автоматический rollback при неудачном upgrade) и --timeout, чтобы Helm сам откатывался при сбое, не оставляя релиз в подвешенном состоянии.

Подводные камни

• Ошибка. частая ошибка — пытаться повторно запустить helm upgrade многократно, игнорируя сообщение о блокировке, вместо того чтобы сначала разобраться в причине (сбойный hook, таймаут) и выполнить rollback; другая ошибка — не использовать --atomic/wait в CI-пайплайне деплоя, из-за чего пайплайн считает деплой успешным сразу после отправки манифестов, не дождавшись реальной готовности подов, и пропускает момент, когда upgrade фактически завис.