Міграція з Helm v2 на Helm v3

Цей посібник показує, як мігрувати з Helm v2 на Helm v3. Для цього необхідно мати встановлений Helm v2, який управляє релізами в одному або кількох кластерах.

Огляд змін у Helm 3

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

1. Видалення Tiller:

   • Заміна архітектури клієнт/сервер на клієнт/бібліотека (тільки бінарний файл helm)
   • Безпека тепер залежить від користувача (делеговано безпеці кластера Kubernetes)
   • Релізи тепер зберігаються як секрети в кластері, а метадані обʼєкта релізу змінилися
   • Релізи зберігаються на основі простору імен релізу, а не в просторі імен Tiller

2. Оновлено репозиторій чартів:

   • helm search тепер підтримує як локальні запити в репозиторії, так і запити до Artifact Hub

3. Зміни у apiVersion чарту:

   • Динамічно підключені залежності чартів переміщені до Chart.yaml (requirements.yaml видалено і requirements --> dependencies)
   • Тепер можна додавати бібліотечні чарти (helper/common charts) як динамічно підключені залежності
   • Чарти мають поле метаданих type, яке визначає, чи є чарт application чи library. Стандартно це application, що означає, що його можна рендерити та інсталювати
   • Чарти Helm 2 (apiVersion=v1) все ще можна встановлювати

4. Додано специфікацію теки XDG:

   • Домівка Helm видалена і замінена специфікацією теки XDG для зберігання конфігураційних файлів
   • Більше не потрібно ініціалізувати Helm
   • helm init і helm home видалені

5. Додаткові зміни:

   • Установка/налаштування Helm спрощено:
     • Тільки клієнт Helm (бінарний файл helm) (без Tiller)
     • Парадигма "run-as-is"
   • 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 - без обмежень)
   • Бібліотека Helm 3 на Go зазнала значних змін і несумісна з бібліотекою Helm 2
   • Бінарники Helm тепер розміщені на 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 для зберігання та метадані обʼєкта релізу, що містяться в ресурсі. Релізи також будуть в просторі імен користувача, а не в просторі імен Tiller (наприклад, простір імен Tiller стандартно kube-system v2). v2 використовує "ConfigMaps" або "Secrets" у просторі імен Tiller і TILLER ownership. v3 використовує "Secrets" у просторі імен користувача і helm ownership. Релізи є інкрементальними в обох версіях v2 і v3
     • Єдина проблема може бути, якщо ресурси кластера Kubernetes (наприклад, clusterroles.rbac) визначені в чарті. Розгортання v3 тоді буде невдалим, навіть якщо унікальне в просторі імен, оскільки ресурси будуть конфліктувати
     • Конфігурація v3 більше не використовує $HELM_HOME і використовує специфікацію теки XDG замість цього. Вона також створюється на льоту за необхідності. Тому вона є незалежною від конфігурації v2. Це стосується тільки випадків, коли обидві версії встановлені на одній системі

2. Міграція з Helm v2 на Helm v3:

   • Цей сценарій застосовується, коли ви хочете, щоб Helm v3 управляв наявними релізами Helm v2
   • Слід зазначити, що клієнт Helm v2:
     • може управляти одним або кількома кластерами Kubernetes
     • може підключатися до одного або кількох екземплярів Tiller для кластера
   • Це означає, що ви повинні бути обізнані про це під час міграції, оскільки релізи розгортаються в кластери Tiller і його простір імен. Тому ви повинні бути обізнані про міграцію для кожного кластера та кожного екземпляра 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 з прикладами