Перейти к основному содержимому
Версия: 3.19.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. Пост-рендерер должен лишь реализовать следующий интерфейс:

type PostRenderer interface {
    // Run expects a single buffer filled with Helm rendered manifests. It
    // expects the modified results to be returned on a separate buffer or an
    // error if there was an issue or failure while running the post render step
    Run(renderedManifests *bytes.Buffer) (modifiedManifests *bytes.Buffer, err error)
}

Для получения дополнительной информации об использовании Go SDK смотрите раздел Go SDK.

Go SDK​

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

Бэкенды хранения​

В Helm 3 по умолчанию информация о релизах хранится в объектах Secret в пространстве имён релиза. В Helm 2 по умолчанию информация о релизах хранилась в объектах ConfigMap в пространстве имён экземпляра Tiller. В следующих подразделах описывается настройка различных бэкендов. Конфигурация выполняется через переменную окружения HELM_DRIVER, которую можно установить в одно из значений: [configmap, secret, sql].

Бэкенд хранения ConfigMap​

Чтобы включить бэкенд ConfigMap, установите переменную окружения HELM_DRIVER в значение configmap.

В оболочке это делается так:

export HELM_DRIVER=configmap

Если вы хотите перейти с бэкенда по умолчанию на бэкенд ConfigMap, вам придётся выполнить миграцию самостоятельно. Получить информацию о релизах можно с помощью следующей команды:

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

ВАЖНО ДЛЯ ПРОДАКШЕНА: Информация о релизах включает содержимое чартов и файлов values, поэтому может содержать конфиденциальные данные (пароли, закрытые ключи и другие учётные данные), которые необходимо защищать от несанкционированного доступа. При управлении авторизацией Kubernetes с помощью RBAC можно предоставить более широкий доступ к ресурсам ConfigMap, ограничив при этом доступ к ресурсам Secret. Например, встроенная роль «view» предоставляет доступ к большинству ресурсов, но не к Secret. Кроме того, данные Secret можно настроить для зашифрованного хранения. Учитывайте это при переходе на бэкенд ConfigMap, так как это может раскрыть конфиденциальные данные вашего приложения.

Бэкенд хранения SQL​

Существует бэкенд хранения SQL в бета-версии, который хранит информацию о релизах в базе данных SQL.

Такой бэкенд хранения особенно полезен, если информация о ваших релизах превышает 1 МБ (в этом случае её нельзя хранить в ConfigMap/Secret из-за внутренних ограничений базового хранилища 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"