Миграция с Helm v2 на v3

В этом руководстве описано, как мигрировать с Helm v2 на v3. Helm v2 должен быть установлен и управлять релизами в одном или нескольких кластерах.

Обзор изменений в Helm 3

Полный список изменений между Helm 2 и 3 задокументирован в FAQ. Ниже приведено краткое изложение некоторых изменений, о которых пользователю следует знать до и во время миграции:

1. Удаление Tiller:
   • Архитектура клиент/сервер заменена на клиент/библиотека (только бинарный файл helm)
   • Безопасность теперь реализована на уровне пользователя (делегирована системе безопасности кластера Kubernetes)
   • Релизы теперь хранятся как Secrets внутри кластера, и метаданные объекта релиза изменились
   • Релизы сохраняются в namespace релиза, а не в namespace Tiller
2. Обновления репозитория чартов:
   • helm search теперь поддерживает как поиск по локальным репозиториям, так и запросы к Artifact Hub
3. Версия apiVersion чарта обновлена до "v2" для следующих изменений спецификации:
   • Динамически связанные зависимости чартов перенесены в Chart.yaml (requirements.yaml удалён, requirements --> dependencies)
   • Чарты-библиотеки (вспомогательные/общие чарты) теперь можно добавлять как динамически связанные зависимости
   • У чартов появилось поле метаданных type для определения типа чарта: application или library. По умолчанию — application, что означает возможность рендеринга и установки
   • Чарты Helm 2 (apiVersion=v1) по-прежнему можно устанавливать
4. Добавлена спецификация директорий XDG:
   • Домашняя директория Helm удалена и заменена спецификацией директорий XDG для хранения файлов конфигурации
   • Больше не нужно инициализировать Helm
   • Команды helm init и helm home удалены
5. Дополнительные изменения:
   • Упрощена установка/настройка Helm:
     • Только клиент Helm (бинарный файл helm), без Tiller
     • Парадигма «запустил и работает»
   • Репозитории local и stable не настраиваются по умолчанию
   • Хук crd-install удалён и заменён директорией crds в чарте, где все CRD устанавливаются перед рендерингом чарта
   • Значение аннотации хука test-failure удалено, test-success объявлено устаревшим. Используйте test вместо них
   • Команды удалены/заменены/добавлены:
     • delete --> uninstall: по умолчанию удаляет всю историю релиза (раньше требовался флаг --purge)
     • fetch --> pull
     • home (удалена)
     • init (удалена)
     • install: требует имя релиза или аргумент --generate-name
     • inspect --> show
     • reset (удалена)
     • serve (удалена)
     • template: аргумент -x/--execute переименован в -s/--show-only
     • upgrade: добавлен аргумент --history-max, ограничивающий максимальное количество сохраняемых ревизий на релиз (0 — без ограничений)
   • Go-библиотека Helm 3 значительно изменилась и несовместима с библиотекой Helm 2
   • Бинарные файлы релизов теперь размещаются на get.helm.sh

Сценарии миграции

Возможны следующие сценарии миграции:

1. Helm v2 и v3 управляют одним кластером:

   • Этот сценарий рекомендуется только если вы планируете постепенно отказаться от Helm v2 и не нуждаетесь в управлении v3 релизами, развёрнутыми через v2. Все новые релизы должны развёртываться через v3, а существующие релизы v2 обновляются/удаляются только через v2
   • Helm v2 и v3 могут без проблем управлять одним кластером. Версии Helm можно установить на одной или разных системах
   • Если вы устанавливаете Helm v3 на ту же систему, необходим дополнительный шаг для сосуществования обеих версий клиента до удаления клиента Helm v2. Переименуйте бинарный файл Helm v3 или поместите его в другую папку для избежания конфликта
   • В остальном конфликтов между версиями нет благодаря следующим различиям:
     • Хранилища релизов (истории) v2 и v3 независимы друг от друга. Изменения включают ресурс Kubernetes для хранения и метаданные объекта релиза. Релизы также привязаны к namespace пользователя, а не к namespace Tiller (например, namespace Tiller по умолчанию в v2 — kube-system). v2 использует "ConfigMaps" или "Secrets" в namespace Tiller с владельцем TILLER. v3 использует "Secrets" в namespace пользователя с владельцем helm. Релизы инкрементальны как в v2, так и в v3
     • Единственная проблема может возникнуть, если в чарте определены кластерные ресурсы Kubernetes (например, clusterroles.rbac). В этом случае развёртывание v3 завершится ошибкой, даже если ресурс уникален в namespace, поскольку ресурсы будут конфликтовать
     • Конфигурация v3 больше не использует $HELM_HOME и вместо этого использует спецификацию директорий XDG. Она создаётся по мере необходимости и независима от конфигурации v2. Это актуально только при установке обеих версий на одной системе

2. Миграция с Helm v2 на Helm v3:

   • Этот сценарий применяется, когда вы хотите, чтобы Helm v3 управлял существующими релизами Helm v2
   • Следует учитывать, что клиент Helm v2:
     • может управлять от 1 до нескольких кластеров Kubernetes
     • может подключаться к нескольким экземплярам Tiller в кластере
   • Это означает, что при миграции нужно учитывать, что релизы развёртываются в кластеры через Tiller и его namespace. Поэтому необходимо выполнять миграцию для каждого кластера и каждого экземпляра Tiller, которыми управляет экземпляр клиента Helm v2
   • Рекомендуемый путь миграции данных:
     1. Создайте резервную копию данных v2
     2. Мигрируйте конфигурацию Helm v2
     3. Мигрируйте релизы Helm v2
     4. Когда убедитесь, что Helm v3 управляет всеми данными Helm v2 (для всех кластеров и экземпляров Tiller экземпляра клиента Helm v2) как ожидалось, очистите данные Helm v2
   • Процесс миграции автоматизирован плагином Helm v3 2to3

Справочные материалы

• Плагин Helm v3 2to3
• Статья в блоге с описанием использования плагина 2to3 и примерами