Розширені техніки 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.

Дозволити Helm володіти наявними ресурсами

За звичай Helm відмовляється встановлювати або оновлювати чарт, якщо ресурс, який не належить до релізу, вже існує у кластері. У такому випадку Helm виведе наступну помилку: "resource already exists and is not owned by this release".

Helm відстежує права власності на ресурси у кластері за допомогою анотацій, керованих Helm, та повʼязаних міток, таких як app.kubernetes.io/managed-by. Цей процес валідації права власності захищає вас від випадкового перезапису обʼєктів, створених іншим інструментом або релізом.

Використовуйте --take-ownership у helm install або helm upgrade, коли ви дійсно хочете, щоб Helm прийняв ці наявні обʼєкти у реліз:

helm install my-release ./mychart --take-ownership
helm upgrade my-release ./mychart --take-ownership

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

Коли це використовується

Типові випадки використання прапорця --take-ownership:

• Перенесення вручну застосованого маніфеста (або іншого інструмента розгортання) до чарту Helm без видалення живих ресурсів спочатку
• Відновлення після видалення анотацій або втрати історії релізу, так що Helm більше не розпізнає свої обʼєкти
• Узгодження чарту з кластерними обʼєктами, які вже відповідають бажаним назвам/видам

Обмеження та найкращі практики

• Отримання прав власності не призводить до видалення зайвих полів, яких ніколи не було в чарті. Тристороннє стратегічне об’єднання (або застосування на стороні сервера, якщо ви ним користуєтеся) як і раніше визначає, як поєднуються значення в режимі реального часу та значення з чарту.
• Щоб уникнути отримання права власності на обʼєкти, якими Helm не повинен управляти, обережно ставтеся до назв і перегляньте результати тестового запуску спочатку (--dry-run).
• helm template також приймає --take-ownership для паритету прапорців; він не взаємодіє з кластером.

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"

:::note Примітки щодо операційної діяльності Інформація про реліз включає вміст чартів і файлів значень, а тому може містити конфіденційні дані (такі як паролі, приватні ключі та інші облікові дані), які необхідно захищати від несанкціонованого доступу. При управлінні авторизацією 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.

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

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

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

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