на него нужно права выдавать
Сдал аттестацию на Certified Kubernetes Administrator
можешь ранчером пользоваться.

Я бы посмотрел

Rancher свободен для распространения.

Есть helm-chart, состоящий из пары веб-приложений (деплоймент), сервиса, ингреса. А ещё там Secret и ConfigMap, которые тянутся в envFor подов и содержат конфигурирующие переменные окружения.

Прикручиваю к этим волшебным веб-приложениям схема-миграции базы данных, использую helm hook: pre-install,pre-upgrade + Job. Т.к. миграциям тоже нужны конфиги — им тоже нужны configmap и secret. Конфигмапы создаются уже после pre-install,pre-upgrade, поэтому нужно немного магии

Добавил в конфиг-мап тоже запуск по хуку с отрицательным весом, мол, загрузись перед миграцией, а убейся перед следующей миграцией:

  
annotations:
    "helm.sh/hook": pre-install,pre-upgrade
    "helm.sh/hook-weight": "-10"
    "helm.sh/hook-delete-policy": before-hook-creation

Всё бы хорошо, да с такими настройками helm прибивает созданный конфигмап и поды самого приложения не разворачиваются с ошибкой CreateContainerConfigError

В дебаге хельма видна такая последовательность:
- пытается удалить конфигмап, не находит его
- создаёт конфиг-мап
- удаляет джобу старой миграции
- запускает джобу новой миграции
- удаляет конфиг-мап (???)
- пытается накатить оставшуюся часть приложения и падает по таймауту

Может быть у кого есть идеи куда копать? helm 3. Выглядит как частый сценарий — упаковать веб-приложение в хельм, положить миграции на хук, переменные в конфигмапе пошарить между ресурсами. Интернет гуглил, ничего полезного найти не смог:
https://github.com/helm/helm/issues/2622
https://helm.sh/docs/topics/charts_hooks/

Оркестратор оркестратора выходит

Верно :)

Для больших исталляций

1. не используйте helm для таких вещей. Как шаблонизатор ещё ничего, как только начинаете копать в сторону хуков и зависмостей - жопа
2. Если вам нужны миграции - то они должны выполняться ПОЛНОСТЬЮ в том же самом окружении, то есть те же конфиги, версии и тд. Обратная совместимость должна соблюдаться в обе стороны на протяжении нескольких версий: старая версия приложения работает с новой схемой, новая версия приложения работает со старой схемой

Я со всем согласен, кроме специфики вопроса — вопрос про работу с хуками в хельме. С миграциями я обойду-пройду, но вылезет в другом месте проблема)

по поводу самой проблемы: делайте полный останов и руками обновляйте базу и приложение. Не надо пытаться натянуть на это helm

даже если сейчас получится, потом какое-нибудь говно вылезет

Спасибо за мнение)

я думаю, я просто подтвердил то, что крутится у вас в голове. :)

Нет, я всё ещё ищу ответа на конкретный вопрос, просто пытаюсь понять где и как его лучше задать, чтобы получить нужный ответ)

helm изначально пытается следовать идеологии k8s, то есть он не грохнет вам все сразу поды из старого revision деплоя, а только по частям. То есть у вас миграция должна не просто в хуке каком то пройти а в процессе смены образа в deployment. Вы как думаете, у вас получится?

или у вас старая версия умеет с новой схемой работать?

+

если так, запихайте миграцию в init container и не парьтесь