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

Go SDK

Helm 3 представив повністю переписаний Go SDK для кращого досвіду при розробці програмного забезпечення та інструментів, які використовують Helm. Повну документацію можна знайти на https://pkg.go.dev/helm.sh/helm/v3, але короткий огляд деяких найбільш популярних пакетів і простий приклад наведені нижче.

Огляд пакетів

Ось список найбільш часто використовуваних пакетів з простим поясненням кожного:

• pkg/action: Містить основний "клієнт" для виконання дій Helm. Це той самий пакет, який використовує CLI "під капотом". Якщо вам просто потрібно виконати базові команди Helm з іншої програми Go, цей пакет для вас.
• pkg/{chart,chartutil}: Методи та допоміжні засоби для завантаження та маніпулювання чартами.
• pkg/cli і його пакети: Містять усі обробники стандартних змінних середовища Helm, а його пакети містять обробку виводів та файлів значень.
• pkg/release: Визначає обʼєкт Release та статуси.

Очевидно, існує багато інших пакетів, тому перегляньте документацію для отримання додаткової інформації!

Простий приклад

Ось простий приклад виконання helm list за допомогою Go SDK:

package main

import (
    "log"
    "os"

    "helm.sh/helm/v3/pkg/action"
    "helm.sh/helm/v3/pkg/cli"
)

func main() {
    settings := cli.New()

    actionConfig := new(action.Configuration)
    // Ви можете передати порожній рядок замість settings.Namespace(), щоб
    // перелічити всі простори імен
    if err := actionConfig.Init(settings.RESTClientGetter(), settings.Namespace(), os.Getenv("HELM_DRIVER"), log.Printf); err != nil {
        log.Printf("%+v", err)
        os.Exit(1)
    }

    client := action.NewList(actionConfig)
    // Лише перерахувати розгорнуті
    client.Deployed = true
    results, err := client.Run()
    if err != nil {
        log.Printf("%+v", err)
        os.Exit(1)
    }

    for _, rel := range results {
        log.Printf("%+v", rel)
    }
}

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

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.

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

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

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

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

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