Перейти до основного вмісту
Версія: 3.22.0

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

Цей розділ пояснює різні розширені функції та техніки використання 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 як пост-рендерера можна побачити тут.

Обмеження​

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

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

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

Крок пост-рендерингу пропонує ще більше гнучкості при використанні в 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.

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

Helm 3 змінив стандартне зберігання інформації про випуски на Secrets у просторі імен випуску. Helm 2 стандартно зберігає інформацію про випуски як ConfigMaps у просторі імен екземпляра Tiller. Підрозділи, що йдуть далі, показують, як налаштувати різні бекенди. Це налаштування базується на змінній середовища 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" надає доступ до більшості ресурсів, але не до Secrets. Крім того, дані секретів можуть бути налаштовані для шифрування. Будь ласка, врахуйте це, якщо ви вирішите перейти на бекенд 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.

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

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

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

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