Helm 3 GA: Tiller ушёл навсегда, начинаем планировать миграцию

13 ноября вышел Helm 3 GA. Без RC, без «почти готово» - стабильный релиз, production ready. Мы ждали этого с августа, когда гоняли alpha в dev-кластере и убедились, что архитектура без Tiller работает именно так, как должна. Теперь это официально стабильно, и вопрос «когда мигрировать» из теоретического стал практическим.

Что изменилось в GA по сравнению с alpha

В августе мы писали про alpha - тогда главной новостью было исчезновение Tiller. GA подтвердил курс и доделал несколько вещей, которые в alpha были сырыми.

Трёхсторонний strategic merge patch. В Helm 2 обновление чарта делалось через diff между старым и новым манифестом - без учёта того, что реально живёт в кластере. Если кто-то руками делал kubectl edit между деплоями, Helm 2 это не замечал и иногда перезатирал, иногда игнорировал - зависело от типа поля. Helm 3 делает трёхсторонний diff: старый манифест из чарта, новый манифест из чарта, текущее состояние в кластере. Это то, как работает kubectl apply - теперь Helm ведёт себя похоже.

State переехал в Secrets в правильные namespace. В Helm 2 вся история релизов хранилась в ConfigMap-ах в том namespace, где жил Tiller - обычно kube-system. Если хочешь посмотреть историю деплоев своего приложения, у тебя должен быть доступ к kube-system. Логично? Нет. В Helm 3 история каждого релиза хранится в Secret-ах в том же namespace, что и само приложение. Доступ к namespace - доступ к истории. Это просто.

Chart API v2 и зависимости в Chart.yaml. Отдельного requirements.yaml больше нет - зависимости описываются прямо в Chart.yaml. Чарты с apiVersion: v1 Helm 3 понимает, так что не всё надо переписывать сразу.

Почему нельзя просто обновить бинарник

Казалось бы: удалил /usr/local/bin/helm, положил новый - готово. Нет.

Helm 3 не видит релизы Helm 2. Разные форматы хранения, разные namespace, разная структура. Если просто поменять бинарник, helm list покажет пустоту там, где раньше были десятки релизов. Тихо и без предупреждений - просто пустой список.

Существует плагин helm-2to3 - мы его тестировали последние несколько дней. Он делает две вещи: конвертирует конфигурацию Helm 2 и мигрирует релизы, перенося информацию о них в формат Helm 3. Работает, но требует аккуратности.

Как мы собираемся мигрировать

Подход, который сложился после тестов - параллельная работа двух версий на переходный период. Это не «запустим и посмотрим», а осознанное решение: менять инструмент деплоя в продакшне быстро и целиком неудобно.

Схема выглядит так: Helm 2 с Tiller остаётся, пока за него держатся существующие релизы. Новые релизы и миграция старых идут через Helm 3. Для этого переименовываем бинарники - helm2 и helm3 - чтобы скрипты и CI/CD-пайплайны явно знали, с чем работают.

На managed-инфраструктуре у нас несколько кластеров с разным числом релизов. Порядок миграции планируем от простого к сложному:

• dev и staging кластеры первыми - там потеря релиза некритична, зато понятно, что конвертация работает корректно.
• Helm-чарты без зависимостей мигрируем в первую очередь - проще проверить результат.
• Чарты с requirements.yaml требуют отдельного шага: либо конвертировать в Chart.yaml-формат, либо оставить v1 и мигрировать позже.

Tiller можно оставить до конца миграции и убрать только тогда, когда helm2 list возвращает пустоту. Торопиться некуда - он просто висит в kube-system и ничего не делает, пока новые деплои идут через Helm 3.

Что нас беспокоит

Два момента, на которые обращаем внимание.

Права доступа в CI/CD. В Helm 2 CI-система вызывала helm upgrade, а сам Tiller имел нужные права. Теперь права нужны у service account, от имени которого работает CI. Для некоторых пайплайнов это изменение нетривиальное - надо пройтись и добавить нужные RoleBinding, иначе деплой начнёт падать с 403.

Кастомные хуки и post-install-задачи. Несколько наших чартов используют Helm hooks для миграции БД и инициализации. В alpha мы видели, что семантика хуков немного изменилась - в GA это поправили, но всё равно нужно проверять каждый хук вручную до включения в продакшн.

Итого

Сам факт GA - хорошая новость: API зафиксировали, обратная совместимость гарантирована. Архитектурное решение по удалению Tiller правильное, мы убедились ещё в августе. Теперь дело за плавной миграцией без горящих дедлайнов.

Плагин helm-2to3 работает, параллельный запуск двух версий технически решаем. Главное - не торопиться и не мигрировать продакшн в пятницу вечером.