Розширені техніки Helm

попередження

Цю сторінку ще не було оновлено для Helm 4. Деякі відомості можуть бути неточними або не стосуватися Helm 4. Докладнішу інформацію про нові функції, вдосконалення та істотні зміни в Helm 4 див. в Огляді Helm 4.

Цей розділ пояснює різні розширені функції та техніки використання Helm. Інформація в цьому розділі призначена для "досвідчених користувачів" Helm, які бажають здійснювати докладні налаштування та маніпуляції з їх чартами та релізами. Кожна з цих розширених функцій має свої переваги та обмеження, тому кожну з них потрібно використовувати обережно і з глибокими знаннями Helm. Іншими словами, памʼятайте про принцип Пітера Паркера.

Пост-рендеринг

Пост-рендеринг дає можливість встановлювачу чартів вручну маніпулювати, налаштовувати та/або перевіряти створені маніфести перед їх встановленням через Helm. Це дозволяє користувачам з додатковими потребами у налаштуванні використовувати інструменти, такі як kustomize, для застосування змін конфігурації без необхідності створювати форк публічного чарту або вимагати від супроводжувачів чартів вказувати всі можливі опції конфігурації для програмного забезпечення. Є також випадки для впровадження загальних інструментів та контейнерів sidecar у корпоративних середовищах або для аналізу маніфестів перед розгортанням.

Передумови

• Helm 3.1+

Використання

Пост-рендерер може бути будь-яким виконуваним файлом, який приймає створені маніфести Kubernetes через STDIN та повертає дійсні маніфести Kubernetes через STDOUT. Він повинен повертати ненульовий код завершення у випадку помилки. Це єдиний "API" між двома компонентами. Це дозволяє значну гнучкість у тому, що ви можете робити з вашим процесом пост-рендерингу.

Пост-рендерер можна використовувати з install, upgrade і template. Щоб використовувати пост-рендерер, використовуйте прапорець --post-renderer з шляхом до виконуваного файлу рендерера, який ви бажаєте використовувати:

$ helm install mychart stable/wordpress --post-renderer ./path/to/executable

Якщо шлях не містить жодних роздільників, пошук буде здійснюватись в $PATH, в іншому випадку буде створено будь-які відносні шляхи до повністю кваліфікованого шляху.

Якщо ви бажаєте використовувати кілька пост-рендерерів, викликайте їх усіх у скрипті або разом у будь-якому бінарному інструменті, який ви створили. У bash це буде так просто, як renderer1 | renderer2 | renderer3.

Приклад використання kustomize як пост-рендерера можна побачити тут.

Імена файлів

Кожен маніфест, що передається до пост-рендерера, містить тимчасову анотацію:

metadata:
  annotations:
    postrenderer.helm.sh/postrender-filename: <original-template-filename>

Helm використовує цю анотацію під час зчитування вихідних даних пост-рендерера, щоб визначити, яке імʼя файлу повʼязати з кожним маніфестом для подальшої обробки. Якщо анотація відсутня, Helm автоматично генерує імʼя файлу у форматі generated-by-postrender-<id>.yaml. Нарешті, Helm видаляє анотацію перед надсиланням маніфестів до Kubernetes.

Обмеження

При використанні пост-рендерерів є кілька важливих моментів, які слід враховувати. Найважливіше з них полягає в тому, що при використанні пост-рендерера всі особи, які модифікують реліз, МУСЯТЬ використовувати той же рендерер для забезпечення повторюваних збірок. Ця функція спеціально створена для того, щоб дозволити будь-якому користувачеві змінювати рендерер або перестати використовувати рендерер, але це слід робити обережно, щоб уникнути випадкових змін або втрати даних.

Ще одне важливе зауваження стосується безпеки. Якщо ви використовуєте пост-рендерер, ви повинні впевнитися, що він надходить з надійного джерела (так само як і будь-яке інше програмне забезпечення). Використання ненадійних або неперевірених рендерерів НЕ рекомендовано, оскільки вони мають повний доступ до створених шаблонів, які часто містять секретні дані.

Власні пост-рендерери

Крок пост-рендерингу пропонує ще більше гнучкості при використанні в Go SDK. Будь-який пост-рендерер повинен реалізувати наступний Go інтерфейс:

type PostRenderer interface {
    // Run очікує один буфер, заповнений відрендереними маніфестами Helm. Він
    // очікує, що модифіковані результати будуть повернені в окремому буфері або
    // помилку, якщо виникла проблема або збій під час виконання кроку пост-рендерингу
    Run(renderedManifests *bytes.Buffer) (modifiedManifests *bytes.Buffer, err error)
}

Більше інформації про використання Go SDK можна знайти в розділі Go SDK.

Go SDK

Helm 3 представив повністю реструктуризований Go SDK для кращого результату при створенні програмного забезпечення та інструментів, що використовують Helm. Повна документація знаходиться в розділі Go SDK.

Сховища даних

Стандартно інформація про реліз зберігається в Secrets в просторі імен релізу. У наступних розділах показано, як налаштувати різні бекенди. Ця конфігурація заснована на змінній середовища HELM_DRIVER. Її можна встановити на одне з таких значень: [configmap, secret, sql].

Бекенд зберігання ConfigMap

Щоб активувати бекенд ConfigMap, потрібно встановити змінну середовища HELM_DRIVER на configmap.

Ви можете встановити її в оболонці наступним чином:

export HELM_DRIVER=configmap

Якщо ви хочете перемикнутися зі стандартного бекенду на бекенд ConfigMap, вам потрібно буде виконати міграцію самостійно. Ви можете отримати інформацію про релізи за допомогою наступної команди:

kubectl get secret --all-namespaces -l "owner=helm"

Примітки щодо операційної діяльності

Інформація про реліз включає вміст чартів і файлів значень, а тому може містити конфіденційні дані (такі як паролі, приватні ключі та інші облікові дані), які необхідно захищати від несанкціонованого доступу. При управлінні авторизацією Kubernetes, наприклад за допомогою RBAC, можна надати ширший доступ до ресурсів ConfigMap, одночасно обмеживши доступ до ресурсів Secret. Наприклад, стандартна роль для користувачів "view" надає доступ до більшості ресурсів, але не до секретів. Крім того, дані секретів можна налаштувати для шифрованого зберігання. Майте це на увазі, якщо ви вирішите перейти на бек-енд ConfigMap, оскільки це може призвести до розкриття конфіденційних даних вашого застосунку.

Бекенд зберігання SQL

Існує бета-версія бекенду зберігання SQL, який зберігає інформацію про релізи в SQL базі даних.

Використання такого бекенду для зберігання даних є особливо корисним, якщо розмір інформації про реліз перевищує 1 МБ (у цьому випадку її неможливо зберігати в ConfigMaps/Secrets через внутрішні обмеження в базовому сховищі ключів-значень etcd Kubernetes).

Щоб активувати SQL бекенд, потрібно розгорнути SQL базу даних і встановити змінну середовища HELM_DRIVER на sql. Деталі бази даних задаються змінною середовища HELM_DRIVER_SQL_CONNECTION_STRING.

Ви можете встановити її в оболонці наступним чином:

export HELM_DRIVER=sql
export HELM_DRIVER_SQL_CONNECTION_STRING=postgresql://helm-postgres:5432/helm?user=helm&password=changeme

примітка

Зараз підтримується лише PostgreSQL.

Примітки щодо операційної діяльності

Рекомендується:

• Підготувати вашу базу даних для операційної діяльності. Для PostgreSQL перегляньте документацію з адміністрування сервера для отримання додаткової інформації.
• Увімкнути управління дозволами для дзеркального відображення Kubernetes RBAC для інформації про випуски.

Якщо ви хочете перемикнутися зі стандартного бекенду на SQL бекенд, вам потрібно буде виконати міграцію самостійно. Ви можете отримати інформацію про релізи за допомогою наступної команди:

kubectl get secret --all-namespaces -l "owner=helm"