Эта статья относится к: Helm v3.8.0
Helm помогает управлять приложениями Kubernetes – диаграммы Helm помогают определить, установить и обновить даже самое сложное приложение Kubernetes. Более подробную информацию о Helm и командах можно найти в официальной документации.
Если вы используете Helm для обработки релизов, вы можете столкнуться с ситуацией, когда релиз застрянет в состоянии ожидания, а все последующие релизы будут неудачными.
Это может произойти, если:
- вы запустили команду обновления из cli и случайно (или нет) прервали ее или
- у вас одновременно запущены два деплоя (например, в Github Actions).
В принципе, любое прерывание, произошедшее в процессе установки/обновления, может привести вас к состоянию, когда вы больше не сможете установить другой релиз.
В журналах релиза неудачное обновление покажет ошибку, подобную следующей:
Error: UPGRADE FAILED: release <name> failed, and has been rolled back due to atomic being set: timed out waiting for the condition
Error: Error: The process '/usr/bin/helm3' failed with exit code 1
Error: The process '/usr/bin/helm3' failed with exit code 1
А статус будет заблокирован: PENDING_INSTALL или PENDING_UPGRADE в зависимости от запущенной команды.
Из-за этого состояния ожидания, когда вы выполните команду для списка всех релизов, она вернется пустой:
> helm list --all
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
Итак, что мы можем сделать сейчас? В этой статье мы рассмотрим два описанных ниже варианта. Имейте в виду, что в зависимости от вашей установки это может быть другая проблема, но я надеюсь, что эти два варианта помогут вам начать.
- Откатитесь к предыдущей рабочей версии с помощью команды
helm rollback. - Удалите секрет helm, связанный с релизом, и повторно выполните команду обновления.
Итак, давайте рассмотрим каждый вариант подробнее.
Первый вариант: Откат к предыдущей рабочей версии с помощью команды helm rollback.
Из официальной документации:
Эта команда откатывает релиз до предыдущей ревизии.
Первым аргументом команды rollback является имя релиза, а вторым – номер ревизии (версии). Если этот аргумент опущен, произойдет откат к предыдущему релизу.
Итак, в данном случае давайте получим историю релизов:
helm history <releasename> -n <namespace>
В выводе вы увидите СТАТУС вашего релиза с: pending-upgrade:
REVISION UPDATED STATUS CHART APP VERSION DESCRIPTION
1 Wed May 25 11:45:40 2022 DEPLOYED api-0.1.0 1.16.0 Upgrade complete
2 Mon May 30 14:32:46 2022 PENDING_UPGRADE api-0.1.0 1.16.0 Preparing upgrade
Теперь давайте выполним откат, выполнив следующую команду:
helm rollback <release> <revision> --namespace <namespace>
Итак, в нашем случае мы выполняем:
> helm rollback api 1 --namespace api
Rollback was a success.
После того, как мы получим подтверждение, что откат прошел успешно, мы выполним команду, чтобы снова получить историю.
Теперь мы видим, что у нас есть два релиза и что наш откат был успешным, а статус STATUS следующий: deployed.
> helm history api -n api
REVISION UPDATED STATUS CHART APP VERSION DESCRIPTION
1 Wed May 25 11:45:40 2022 SUPERSEEDED api-0.1.0 1.16.0 Upgrade complete
2 Mon May 30 14:32:46 2022 SUPERSEEDED api-0.1.0 1.16.0 Preparing upgrade
3 Mon May 30 14:45:46 2022 DEPLOYED api-0.1.0 1.16.0 Rollback to 1
Итак, что делать, если решение выше не сработало?
Второй вариант: Удалить секрет штурвала, связанный с релизом, и повторно выполнить команду обновления
Сначала мы получим все секреты для пространства имен, выполнив команду:
kubectl get secrets -n <namespace>
В результатах вы увидите список секретов в следующем формате:
NAME TYPE DATA AGE
api Opaque 21 473d
sh.helm.release.v1.api.v648 helm.sh/release.v1 1 6d5h
sh.helm.release.v1.api.v649 helm.sh/release.v1 1 5d1h
sh.helm.release.v1.api.v650 helm.sh/release.v1 1 57m
Что же содержится в секрете?
Helm3 использует объект Kubernetes Secrets для хранения любой информации о релизе. Эти секреты в основном используются Helm для хранения и чтения состояния при каждом запуске: helm list, helm history или helm upgrade в нашем случае.
Именование секретов уникально для каждого пространства имен.
Формат соответствует следующему соглашению:
По умолчанию хранится не более 10 секретов, но вы можете изменить это значение, установив флаг --history-max в команде обновления helm.
–history-max int ограничивает максимальное количество ревизий, сохраняемых в одном релизе. Используйте 0 для отсутствия ограничения (по умолчанию 10)
Теперь, когда мы знаем, для чего используются эти секреты, давайте удалим секрет helm, связанный с ожидающим релизом, выполнив следующую команду:
kubectl delete secret sh.helm.release.v1.<release_name>.v<release_version> -n <namespace>
Наконец, мы повторно запускаем команду обновления helm (либо из командной строки, либо из рабочего процесса развертывания), которая, если до сих пор все было хорошо, должна пройти успешно.
Существует открытая проблема с Helm, поэтому, надеюсь, эти обходные пути больше не понадобятся. Но он открыт с 2018 года.
Конечно, могут быть и другие случаи или проблемы, но я надеюсь, что это хорошее место для начала. Если вы столкнулись с чем-то подобным, я буду рад прочитать вашу информацию о том, что это была за проблема и как вы ее решили, особенно потому, что я не нашел сообщение об ошибке интуитивно понятным.
Спасибо, что прочитали!