Helm linux что это

Обновлено: 06.07.2024

В этом руководстве рассказывается, как установить Helm CLI. Helm может быть установлен как из исходного кода, так и из собранных binary релизов.

Из Проекта Helm

Проект Helm предоставляет два способа получения и установки Helm. Это официальные методы получения релизов Helm. В дополнение к этому сообщество Helm предоставляет методы установки Helm через различные менеджеры пакетов. Установка с помощью этих методов может быть найдена ниже официальных методов.

Из Binary Релизов

Каждый релиз Helm предоставляет различные binary сборки под разные операционные системы (OSes). Эти binary версии могут быть загружены и установлены вручную.

Скачайте нужную вам версию
Распакуйте её ( tar -zxvf helm-v3.0.0-linux-amd64.tar.gz )
Найдите helm binary файл в директории из распаковки, и переместите в нужное место ( mv linux-amd64/helm /usr/local/bin/helm )

Сразу после этого можно запустить Helm справку добавить stable репозиторий: helm help .

Примечание: Автоматические тесты Helm выполняются для Linux AMD64 только во время сборки и выпуска CircleCI. Тестирование других OSes является обязанностью сообщества, использующего Helm на их OS.

Из Скрипта

У Helm теперь есть скрипт установки, которая будет автоматически загружать последнюю версию Helm и устанавливать его локально.

Вы можете получить этот сценарий, а затем выполнить его локально. Он хорошо документирован, так что вы можете прочитать его и понять, что он делает, прежде чем запускать.

Через Менеджеров Пакетов

Сообщество Helm предоставляет возможность установки Helm через менеджеры пакетов операционной системы. Они не поддерживаются проектом Helm и не считаются проверенными.

Используя Homebrew (macOS)

Члены сообщества Helm внесли свой вклад в создание formula Helm для Homebrew. Эта formula, почти всегда, актуальна.

(Примечание:: Существует также formula для emacs-helm, являющаяся другим проектом.)

Используя Chocolatey (Windows)

Члены сообщества Helm внесли свой вклад в Helm пакет собранный под Chocolatey. Данная сборка почти всегда актуальна

Используя Apt (Debian/Ubuntu)

Члены сообщества Helm внесли свой вклад в Helm package для Apt. Данная сборка почти всегда актуальна

Используя Snap

Snapcrafters сообщество поддерживает Snap-версию Helm пакета:

Используя pkg (FreeBSD)

Члены сообщества FreeBSD внесли свой вклад в создание Helm пакета под FreeBSD Ports Collection. Данная сборка почти всегда актуальна

Тестовые Сборки

В дополнение к релизам вы можете скачать или установить тестовые сборки

Используя Canary Сборки

Сборки Canary – это версии программного обеспечения Helm, построенные из последней основной ветви. Они не являются официальными релизами и могут быть нестабильными. Тем не менее, они предлагают возможность протестировать передовые функции.

Canary Helm binaries сборки хранятся в get.helm.sh. Вот несколько ссылок на общие сборки:

Из Исходного Кода (Linux, macOS)

Создание Helm из исходного кода-это немного больше работы, но это лучший способ пойти, если вы хотите протестировать последнюю версию (pre-release) Helm.

У вас должна быть рабочая среда Go.

При необходимости скрипт извлекает зависимости, кэширует их и проверяет конфигурацию. Затем он скомпилирует helm и поместит его в bin/helm .

Заключение

В большинстве случаев установка так же проста, как получение предварительно построенного binary файла helm . В этом документе описаны дополнительные случаи для тех, кто хочет делать с Helm более сложные вещи.

После успешной установки клиента Helm вы можете перейти к использованию Helm для управления chart-ми и добавить stable репозиторий.

Мы являемся выпускным проектом Cloud Native Computing Foundation.

© 2021 The Linux Foundation. All rights reserved. The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see our Trademark Usage page.

В этом руководстве объясняются основы использования Helm для управления пакетами на вашем кластере Kubernetes. Руководство предполагает, что вы уже установили Helm CLI.

Если вы просто заинтересованы нескольких командам, то можете начать с Краткого Руководства. В этой главе описаны особенности команд Helm.

Three Big Concepts

Chart – это пакет Helm. Он содержит описания ресурсов, необходимые для запуска приложения, инструмента или службы внутри кластера Kubernetes.

Репозиторий это место, где можно собирать charts-ы и делиться ими. Очень похоже на Perl's CPAN archive или Fedora Package Database, но для пакетов Kubernetes.

Релиз это пример charts-а, работающего в кластере Kubernetes. Один chart часто может быть установлен много раз в одном и том же кластере. Каждый раз, когда он устанавливается, создается новый release. Рассмотрим график MySQL. У каждого из них будет свой release, который, в свою очередь, будет иметь своё имя release name.

Зная эти понятия, объяснить работу Helm можно так:

Helm устанавливает charts в Kubernetes, создавая новый release для каждой установки. А для поиска новых графиков можно воспользоваться поиском Helm chart repositories.

'helm search': Поиск Charts

Helm поставляется с мощной поисковой командой. Он может быть использован для поиска двух различных типов источников:

helm search hub ищет в the Artifact Hub, который агрегирует списки из различных хранилищ
helm search repo поиск в репозиториях, которые вы добавили в свой локальный каталог helm client (используя helm repo add ). Этот поиск выполняется по локальным данным, не используя подключение к публичной сети.

Вы можете найти общедоступные chart-ы, запустив helm search hub :

Выше приведен поиск всех chart-ов wordpress на Artifact Hub.

Поиск показывает все доступные chart-ы с определенным именем helm search hub .

Используя helm search repo , вы можете найти названия chart-ов в уже добавленных вами репозиториях:

Helm search использует приближённый поиск подстроки (fuzzy string matching), поэтому вы можете вводить части слов или фраз:

Поиск – это хороший способ найти доступные пакеты. Как только вы нашли пакет , который хотите установить, вы можете использовать helm install для его установки.

'helm install': Установка пакета

Чтобы установить новый пакет, используйте команду helm install . В самом простом случае она ожидает два аргумента: имя выпуска _release_name_ , и имя chart-а, который Вы хотите установить.

После установки wordpress chart-а обратите внимание, что при установке создается новый объект release. Текущей релиз называется happy-panda . (Если вы хотите чтобы Helm сгенерировал имя за вас, оставьте название релиза и используйте --generate-name .)

Во время установки helm клиент напечатает полезную информацию о том, какие ресурсы были созданы, каково состояние релиза, а также есть ли дополнительные шаги настройки, которые вы можете воспроизвести.

Helm не ждет, пока все ресурсы будут запущены, прежде чем он завершит свою работу. Для многих chart-ов требуются образ Docker-а размером более 600M, и их установка в Kubernetes кластер может занять много времени.

Чтобы отслеживать состояние релиза или перечитывать информацию о конфигурации, вы можете использовать helm status :

Выше показано текущее состояние вашего релиза.

Настройка Chart-а Перед установкой

Изначально Helm использует параметры конфигурации по умолчанию. Но вы всегда можете настроить chart используя свою конфигурацию

Чтобы увидеть, какие параметры есть в chart-е, используйте helm show values :

Затем вы можете переопределить любой из этих параметров в файле формата YAML, а затем передать этот файл во время установки.

Команды выше создадут пользователя для MariaDB с именем user0 и предоставит этому пользователю доступ к созданной базе данных user0db , но использует остальные значения chart-а по умолчанию.

Существует два способа передачи конфигурационных данных во время установки:

--values (или -f ): Укажите YAML файл с конфигурацией. Это можно сделать несколько раз, и самый правый файл будет иметь приоритет
--set : переопределения в командной строке.

Если используются оба параметра, то значения --set объединяются в --values с более высоким приоритетом. Переопределения, указанные с помощью --set , сохраняются в ConfigMap. Значения, которые были --set , можно просмотреть для данного выпуска с помощью helm get values <release-name> . Значения --set , можно очистить, выполнив helm upgrade с --reset-values .

Формат и Ограничения --set

Параметр --set принимает ноль или более пар имя/значение. В самом простом случае он используется следующим образом: --set name=value . Пример в YAML формате:

Несколько значений разделяются символами , . --set a=b,c=d в YAML формате выглядит так:

Поддерживаются более сложные выражения. Например, --set outer.inner=value

Списки могут быть предоставлены путем включения значений в < и >. Например, --set name= :

Начиная с Helm 2.5.0, доступ к элементам списка возможен с помощью синтаксиса индекса массива. Например, --set servers[0].port=80 :

Можно задать несколько значений. Строка --set servers[0].port=80,servers[0].host=example становится:

Иногда вам нужно использовать специальные символы в --set . Вы можете использовать обратную косую черту для экранирования символов; --set name=value1\,value2 :

Точно так же вы можете экранировать точки, что может пригодиться, когда chart-ы используют функцию toYaml для анализа аннотаций, меток и селекторов узлов. Пример синтаксиса --set nodeSelector."kubernetes\.io/role"=master :

Deeply nested data structures can be difficult to express using --set . Chart designers are encouraged to consider the --set usage when designing the format of a values.yaml file (read more about Values Files).

Дополнительные Методы Установки

helm install может установить один из нескольких источников:

'helm upgrade' и 'helm rollback': Обновление Релиза и Восстановление После Сбоя

Когда выпускается новая версия chart-а или когда вы хотите изменить конфигурацию своего релиза, вы можете использовать команду helm upgrade .

An upgrade takes an existing release and upgrades it according to the information you provide. Because Kubernetes charts can be large and complex, Helm tries to perform the least invasive upgrade. It will only update things that have changed since the last release.

Обновление использует существующий релиз и обновляет его в соответствии с предоставленной вами информацией. Из-за того, что chart-ы Kubernetes могут быть большими и сложными, Helm пытается выполнить наименее инвазивное обновление. Он будет обновлять только то, что изменилось с момента последнего релиза.

В приведенном выше случае релиз happy-panda обновляется с тем же chart, но с новым файлом YAML:

Вы можете использовать helm get values , чтобы увидеть, заработа ли новая версия.

Команда helm get - это полезный инструмент для просмотра релизов в кластере. И как мы видим выше, она показывает, что наши новые значения из panda.yaml были развернуты в кластере.

Теперь, если что-то идет не так, как планировалось во время выпуска, легко откатиться к предыдущему выпуску, используя helm rollback [RELEASE] [REVISION] .

Пример выше возвращает happy-panda к самой первой версии выпуска. Версия выпуска-это инкрементная версия. Каждый раз, когда происходит установка, обновление или откат, номер версии увеличивается на 1. Первый номер редакции всегда равен 1. Мы можем использовать helm history [RELEASE] , чтобы увидеть номера версий для определенного релиза.

Полезные Опции для Установки/Обновлении/Отката

Существует несколько других полезных параметров, которые вы можете указать для настройки поведения Helm во время установки/обновления/отката. Обратите внимание, что это не полный список флагов cli. Чтобы увидеть описание всех флагов, просто запустите helm <command> --help .

--timeout : Go duration время ожидания выполнения Kubernetes команд. Стандартное время 5m0s .
--wait : Ждет, пока все Pods не будут в состоянии готовности, Развертывания должны иметь минимум ( Desired минус maxUnavailable ) Pods в состоянии готовности и Services должны иметь IP адрес (и Ingress если есть LoadBalancer ) перед пометкой успешного релиза. Он будет ждать до значения --timeout . Если тайм - аут достигнут, то релиз будет помечен как FAILED . Note: In scenarios where Deployment has replicas set to 1 and maxUnavailable is not set to 0 as part of rolling update strategy, --wait will return as ready as it has satisfied the minimum Pod in ready condition.
--no-hooks : Это пропускает запуск hooks для команды
--recreate-pods (доступно только для upgrade и rollback ): Этот флаг приведет к пересозданию всех pods (with the exception of pods belonging to deployments). (УСТАРЕЛО в Helm 3)

'helm uninstall': Удаление Релиза

Когда потребуется удалить релиз из кластера, используйте команду helm uninstall :

Это приведет к удалению релиза из кластера. Вы можете просмотреть все ваши текущие развернутые релизы с помощью команды helm list :

Из примера выше видно, что релиз happy-panda был удален.

В предыдущих версиях Helm, когда релиз удалялся, запись о его удалении оставалась. В Helm 3, Удаление удаляет записи релиза, а также. Если вы хотите сохранить запись об удалении выпуска, используйте helm uninstall --keep-history . Использование helm list --uninstalled покажет только те выпуски, которые были удалены с флагом --keep-history .

Флаг helm list --all покажет вам все релизы, сохраненные Helm, включая записи для неудачных или удаленных элементов (если был указан параметр --keep-history ):

Обратите внимание, что поскольку релизы теперь удаляются по умолчанию, откат удаленного ресурса больше невозможен.

'helm repo': Работа с Репозиториями

Helm 3 больше не поставляется со стандартным хранилищем chart-ов. Команды helm repo предоставляет возможности добавления, перечисления и удаления репозиториев.

Узнать о настроенных репозитории можно с помощью helm repo list :

Новые репозитории могут быть добавлены с помощью helm repo add :

Поскольку репозитории диаграмм часто меняются, в любой момент вы можете убедиться, что ваш клиент Helm обновлен, запустив helm repo update .

Репозитории могут быть удалены с помощью helm repo remove .

Создание Собственных Chart-ов

Руководство по разработке Chart-ов объясняет, как создавать свои собственные chart-ы. Но вы можете быстро начать работу с помощью команды helm create :

Теперь у вас есть chart в ./deis-workflow . Вы можете редактировать его и создавать свои собственные шаблоны.

У Helm есть линтер для проверки корректности chart-а, воспользоваться им можно с помощью helm lint .

Когда придет время упаковать chart в пакет для распространения вам поможет команда helm package

Теперь вы можете с легкостью поставить этот chart в ваш Helm с помощью helm install

Упакованные chart-ы могут быть загружены в репозиторий chart-ов. Смотрите документацию по Helm chart репозитории для того, что бы узнать новые детали.

Заключение

В этой главе рассмотрены основные схемы использования клиента helm , включая поиск, установку, обновление и удаление. Он также охватывает полезные служебные команды, такие как helm status , helm get , и helm repo .

Для получения дополнительной информации об этих командах обратитесь к встроенной справке Helm: helm help .

Мы являемся выпускным проектом Cloud Native Computing Foundation.

Статья является логическим продолжение нашей недавней публикации об истории пакетного менеджера для Kubernetes — Helm. В этот раз мы снова затронем вопросы устройства и функционирования нынешнего Helm (версия 2.x), а также управляемых им чартов и репозиториев, после чего перейдём к практике: установке Helm в кластер Kubernetes и использованию чартов.

Вступление

Helm — инструмент для управления чартами.

Чарт описывает необходимый набор данных для создания экземпляра приложения в кластере Kubernetes. Он может иметь вложенные чарты и использоваться как для описания полноценных сервисов, состоящих из множества зависимых ресурсов, так и для описания отдельных независимых составляющих. К примеру, чарт stable/gitlab-ce описывает комплексное решение с использованием независимых чартов redis и postgresql.

Чарт может быть установлен неограниченное количество раз в одном и том же кластере. Таким образом, описание логики выката приложения в разные окружения может и должно храниться в одном чарте.

Клиентская часть Helm отвечает за формирование чарта и передачу вместе с пользовательскими параметрами находящемуся в кластере Kubernetes компоненту Tiller. В свою очередь, Tiller отвечает за жизненный цикл экземпляра запущенного чарта, релиза. (На всякий случай напомню, что в следующем крупном обновлении Helm — версии 3 — уже не будет Tiller.)

А теперь — обо всём по порядку.

Установка и обновление

Для работы с Helm требуется Kubernetes. Можно использовать локально установленный Minikube (см. также «Начало работы в Kubernetes с помощью Minikube») или любой другой доступный кластер.

Начнём с установки клиента: выбираем релиз, скачиваем и распаковываем архив для своей системы, переносим исполняемый файл…

Далее установка Tiller в кластер. По умолчанию Tiller устанавливается в кластер контекста kubectl ( kubectl config current-context ), в пространство имён kube-system , но это можно изменить, используя соответствующие опции и переменные окружения — они описаны в справке ( helm init --help ). Выполним установку и посмотрим на созданные ресурсы в кластере:

Теперь Tiller установлен в кластер и готов к управлению релизами, взаимодействию с Kubernetes API.

Примечание: При установке и обновлении (опция --upgrade ) Tiller'а можно задавать конкретный образ вместо использования последнего стабильного релиза по умолчанию. Имя произвольного образа определяется опцией --tiller-image , а с опцией --canary-image при выкате Tiller будет использован canary-образ. Сanary-образ позволяет использовать Tiller, версия кода которого соответствует ветке master.

Служебные данные хранятся в кластере в специальных ресурсах, ConfigMaps , поэтому удаление и переустановка Tiller'а не приводят к потере данных установленных ранее релизов.

Репозитории чартов

По умолчанию Helm использует официальный репозиторий чартов Kubernetes. Он содержит тщательно проработанные актуальные чарты для решения множества прикладных задач. Этот репозиторий именуется stable:

При необходимости создание собственного репозитория не составит никаких проблем. Требования к серверу — минимальные, поэтому, как и большинство публичных репозиториев чартов, его можно разместить на GitHub Pages. Подробнее про инструменты и необходимые для этого шаги можно почитать в документации.

При использовании репозиториев чартов они могут быть добавлены и удалены. Для того, чтобы версии чартов были актуальными, необходимо периодически обновлять индекс. Приведу пример для публичного репозитория bitnami, большая часть чартов которого используется в официальном репозитории Helm:

Далее — поиск по репозиториям. Вызов helm search без аргументов показывает все доступные чарты:

В необязательном поле keywords в Chart.yaml разработчики указывают теги, которые используются для упрощения поиска в репозиториях чартов:

Примечание: При использовании команды helm search можно столкнуться с нестабильной работой нескольких фильтров: наличие результата зависит от порядка указания и количества фильтров.

После того, как круг поисков сузился до нескольких вариантов, можно перейти к более детальному анализу чартов — с помощью команды helm inspect . Она выводит содержимое файлов чарта Chart.yaml , values.yaml и README.md . Каждый раздел по отдельности можно вывести с соответствующими аргументами: chart , values и readme .

В официальном репозитории чарты прекрасно документированы и содержат примеры использования, а некоторые чарты — даже готовые конфигурации для production. К примеру, хороший readme представлен у stable/wordpress (для его вывода в консоли см. helm inspect readme stable/wordpress ).

Поиск — это хороший способ найти доступные пакеты. После того, как пакет найден, можно использовать его для установки приложения в кластер.

Первое приложение

Для примера выбран уже упомянутый чарт stable/wordpress.

В нём используются параметры, описанные в файле values.yaml . Параметры можно переопределить в YAML-файле, а затем передать этот файл во время установки (опции -f , --values ). Кроме того, их можно переопределить непосредственно в командной строке (опции --set , --set-string и --set-file ). Все опции доступны для использования произвольное количество раз; при этом переопределение в командной строке имеет больший приоритет над файлами с параметрами.

При установке чарта можно задать имя релизу опцией --name или использовать случайное имя, сгенерированное Helm.

Установим чарт с конфигурацией для production, поменяем название блога, отключим сохранение данных WordPress в PersistentVolumeClaim (подробнее про постоянные хранилища см. в документации Kubernetes):

В случае работы с полноценным кластером далее можно следовать рекомендациям из блока NOTES выше. Если же у вас Minikube — откройте сайт в браузере следующим образом:

Поздравляю, приложение в кластере!

Развёрнутый чарт с WordPress появился в списке всех релизов Helm:

Обратите внимание, что при обновлении Tiller сравнивает полученный чарт с параметрами с последним сохранённым и выполняет соответствующие запросы в Kubernetes API, а актуальное состояние ресурсов релиза не берётся в расчёт. Важно понимать эту особенность и не совершать ошибок:

Обновление ничем не отличается от инсталяции: Helm-клиент отправляет Tiller чарт вместе с параметрами, поэтому надо быть внимательнее и не забыть указать параметры и файлы с параметрами, которые задавались при инсталяции (или при предыдущем обновлении) и которые не должны быть проигнорированы. В примере выше — это --set "wordpressBlogName=Flant's Blog!" --set "persistence.enabled=false" -f values-production.yaml .
Приложения, которые выкатываются при помощи Helm, должны обслуживаться только с использованием Helm: изменения, сделанные вручную при помощи kubectl , не будут учтены Helm и могут приводить к необратимым последствиям.

Состояние компонентов релиза приложения в кластере всегда можно проверить следующим образом:

Helm позволяет откатываться до определённой ревизии релиза. На текущий момент ревизий две:

Откатим приложения к первоначальному состоянию:

Теперь история ревизий пополнилась на одну запись:

Статья подходит к концу и релиз больше не требуется?

А удалён ли он в действительности.

Команда удаляет Kubernetes-ресурсы, связанные с релизом, но не сам релиз. Вся информация о релизе остаётся доступной, в том числе и его история:

Для полного удаления релиза используется опция --purge :

Резюмируя

В этой статье рассказано про базовую архитектуру Helm 2, его компоненты и их функций, а также об основных примитивах, чартах, релизах и репозиториях чартов. Мы установили Helm в кластер Kubernetes и получили понимание жизненного цикла релиза и основных команд для работы с ним.

Следующий материал из этого цикла будет посвящён теме создания собственного чарта — в нём я расскажу про структуру чарта, шаблонизацию и инструменты отладки. ОБНОВЛЕНО: Новая статья доступна по этой ссылке.

Прим. перев.: Этой статьёй мы открываем цикл публикаций про пакетный менеджер для Kubernetes, который активно используем в повседневной работе, — Helm. Оригинальным автором материала является Matt Butcher — один из основателей проекта Helm, работающий над Open Source-проектами в Microsoft и написавший 8 технических книг (в частности, «Go in Practice»). Однако статья дополнена нашими (местами — обширными) комментариями, а в скором времени будет ещё больше расширена новыми заметками по Helm более практической направленности. ОБНОВЛЕНИЕ (03.09.2018): вышло продолжение — «Практическое знакомство с пакетным менеджером для Kubernetes — Helm».

В июне Helm перешёл из статуса ведущего проекта Kubernetes в фонд Cloud Native Computing Foundation (CNCF). CNCF становится родительской организацией для лучших в своём роде cloud native-инструментов с открытым исходным кодом. Поэтому большая честь для Helm стать частью такого фонда. И наш первый значимый проект под покровительством CNCF по-настоящему масштабный: мы создаём Helm 3.

Краткая история Helm

Helm изначально появился как Open Source-проект компании Deis. Его моделировали по подобию Homebrew (менеджер пакетов для macOS — прим. перев.), а стоящей перед Helm 1 задачей была облегчённая возможность для пользователей быстро установить свои первые рабочие нагрузки на Kubernetes. Официальный анонс Helm состоялся на первой конференции KubeCon San Francisco в 2015 году.

Прим. перев.: С первой версии, которая называлась dm (Deployment Manager), для описания ресурсов Kubernetes был выбран синтаксис YAML, а при написании конфигураций поддерживались шаблоны Jinja и Python-скрипты.

Шаблон простого веб-приложения мог выглядеть следующим образом:

При описании компонентов выкатываемого приложения указывается имя, используемый шаблон, а также необходимые параметры этого шаблона. В примере выше ресурсы frontend и redis используют шаблоны из официального репозитория.

Уже в этой версии можно использовать ресурсы из общей базы знаний, создавать собственные репозитории шаблонов и компоновать комплексные приложения за счёт параметров и вложенности шаблонов.

Архитектура Helm 1 состоит из трёх компонентов. Следующая диаграмма иллюстрирует отношения между ними:

А теперь вернёмся к оригинальному тексту об истории Helm…

Несколькими месяцами позже мы объединили усилия с командой Kubernetes Deployment Manager из Google и начали работу над Helm 2. Целью было сохранить простоту использования Helm, добавив в него следующее:

шаблоны чартов («чарт» — аналог пакета в экосистеме Helm — прим. перев.) для кастомизации;
управление внутри кластера для команд;
полноценный репозиторий чартов;
стабильный и подписываемый формат пакетов;
твёрдая приверженность семантическому версионированию и сохранению обратной совместимости от версии к версии.

Прим. перев.: Таким образом, во второй версии Helm в кластере остаётся единственный компонент, который отвечает за жизненный цикл инсталяций (release), а подготовка конфигураций выносится в Helm-клиент.

Если перезагрузка кластера при использовании первой версии Helm приводила к полной потере служебных данных (т.к. они хранились в оперативной памяти), то в Helm 2 все данные хранятся в ConfigMaps , т.е. ресурсах внутри Kubernetes. Ещё одним важным шагом стал переход от синхронного API (где каждый запрос был блокирующим) к использованию асинхронного gRPC.

Со времени выпуска Helm 2 в 2016 году проект Kubernetes пережил взрывной рост и появление новых значительных возможностей. Было добавлено управление доступом на основе ролей (RBAC). Представлено множество новых типов ресурсов. Изобретены сторонние ресурсы (Custom Resource Definitions, CRD). А что самое важное — появились лучшие практики. Проходя через все эти изменения, Helm продолжал служить потребностям пользователей Kubernetes. Но нам стало очевидно, что настало время внести в него крупные изменения для того, чтобы потребности этой развивающейся экосистемы продолжали удовлетворяться.

Так мы пришли к Helm 3. Далее я расскажу о некоторых из новшеств, фигурирующих на дорожной карте проекта.

Поприветствуем Lua

В Helm 2 мы представили шаблоны. На раннем этапе разработки Helm 2 мы поддерживали шаблоны Go, Jinja, чистый код на Python и у нас даже был прототип поддержки ksonnet. Но наличие множества движков для шаблонов породило больше проблем, чем решило. Поэтому мы пришли к тому, чтобы выбрать один.

У шаблонов Go было четыре преимущества:

библиотека встроена в Go;
шаблоны исполняются в жёстко ограниченном песочницей окружении;
мы могли вставлять в движок произвольные функции и объекты;
они хорошо работали с YAML.

И мы узнали об их разочарованиях:

Синтаксис сложен в чтении и плохо документирован.
Проблемы языка, такие как неизменные переменные, запутанные типы данных и ограничительные правила в области видимости, превратили простые вещи в сложные.
Отсутствие возможности определять функции внутри шаблонов ещё больше усложнили создание повторно используемых библиотек.

Работа над объектами, а не кусками YAML

Снова и снова мы слышали от пользователей запрос на возможность инспекции и модификации ресурсов Kubernetes как объектов, а не строк. В то же время они были непреклонны в том, что, какой бы путь реализации мы для этого ни выбрали, он должен быть простым в изучении и хорошо поддерживаться в экосистеме.

После месяцев исследований мы решили предоставить встроенный скриптовый язык, который можно упаковать в песочницу и кастомизировать. Среди 20 ведущих языков оказался лишь один кандидат, удовлетворяющий требованиям: Lua.

В 1993 году группа бразильских ИТ-инженеров создала легковесный скриптовый язык для встраивания в свои инструменты. У Lua простой синтаксис, он широко поддерживается и уже долгое время фигурирует в списке топ-20 языков. Его поддерживают IDE и текстовые редакторы, есть множество руководств и обучающих книг. Вот на такой уже существующей экосистеме мы бы и хотели развивать своё решение.

Наша работа над Helm Lua всё ещё находится на этапе доказательства концепции, и мы ожидаем синтаксиса, который был бы одновременно знакомым и гибким. Сравнивая старый и новый подходы, можно увидеть, куда мы движемся.

Вот как выглядит пример шаблона пода с Alpine в Helm 2:

В этом незамысловатом шаблоне можно сразу увидеть все встроенные директивы шаблонов, такие как > .

А вот как выглядит определение того же пода в предварительной версии кода на Lua:

Нет необходимости рассматривать каждую строчку этого примера, чтобы понять, что происходит. Сразу видно, что в коде определяется под. Но вместо использования YAML-строк со встроенными директивами шаблонов мы определяем под как объект в Lua.

Давайте сократим этот код

Поскольку мы напрямую работаем с объектами (вместо манипуляции с большим glob'ом текста), можем воспользоваться всеми преимуществами скриптования. Появляющиеся здесь возможности создания разделяемых библиотек выглядят по-настоящему привлекательно. И мы надеемся, что, представив специализированные библиотеки (или позволив сообществу их создать), сможем сократить приведённый выше код примерно до такого:

В данном примере используется возможность работы с определением ресурса как с объектом, которому легко устанавливать свойства, сохраняя при этом лаконичность и читаемость кода.

Шаблоны… Lua… Почему бы не всё вместе?

Пусть шаблоны и не так замечательны для всех задач, у них всё же есть определённые преимущества. Шаблоны в Go — стабильная технология со сложившейся пользовательской базой и множеством существующих чартов. Многие разработчики чартов утверждают, что им нравится писать шаблоны. Поэтому поддержку шаблонов мы убирать не собираемся.

Вместо этого мы хотим разрешить использовать одновременно и шаблоны, и Lua. У скриптов Lua будет доступ к шаблонам Helm и до, и после того, как они отрендерены, что позволит разработчикам продвинутых чартов выполнять сложные преобразования для существующих чартов, сохраняя простую возможность создания Helm-чартов с шаблонами.

Мы очень воодушевлены поддержкой скриптов на Lua, но в то же время избавляемся от значимой части архитектуры Helm…

Прощаясь с Tiller

Во время разработки Helm 2 мы представили Tiller в качестве компонента интеграции с Deployment Manager. Tiller играл важную роль для команд, работающих на одном кластере: он делал возможным взаимодействие с одним и тем же набором релизов для множества различных администраторов.

Однако Tiller работал как гигантский sudo-сервер, выдающий широкий диапазон прав каждому, у кого есть доступ к Tiller. И нашей схемой по умолчанию при инсталляции была разрешительная конфигурация. Поэтому DevOps- и SRE-инженерам приходилось обучаться дополнительным шагам для установки Tiller в кластерах категории multi-tenant.

Более того, при появлении CRD мы больше не могли надёжно полагаться на Tiller для поддержания состояния или функционирования в качестве центрального хаба для информации о релизе Helm. Мы могли только хранить эту информацию в виде отдельных записей в Kubernetes.

Главная цель Tiller может быть достигнута и без самого Tiller. Поэтому одним из первых решений, принятых на этапе планирования Helm 3, был полный отказ от Tiller.

Улучшение безопасности

Без Tiller модель безопасности Helm радикально упрощается. Пользовательская аутентификация делегируется Kubernetes. И авторизация тоже. Права Helm определяются как права Kubernetes (через систему RBAC), и администраторы кластера могут ограничить права Helm на любом необходимом уровне детализации.

Releases, ReleaseVersions и State Storage

В условиях отсутствия Tiller, для поддержания состояния различных релизов внутри кластера нам требуется новый способ взаимодействия всех клиентов (по управлению релизами).

Для этого мы представили две новые записи:

Release — для конкретной инсталляции конкретного чарта. Если мы выполним helm install my-wordpress stable/wordpress , будет создан релиз с названием my-wordpress и поддерживаться на протяжении всей жизни этой инсталляции WordPress.
ReleaseVersion — при каждом обновлении чарта Helm необходимо учитывать, что изменилось и было ли изменение успешным. ReleaseVersion привязан к релизу и хранит только записи с информацией об обновлении, откате и удалении. Когда мы выполним helm upgrade my-wordpress stable/wordpress , оригинальный объект Release останется прежним, но появится дочерний объект ReleaseVersion с информацией об операции обновления.

С этими возможностями команды пользователей Helm смогут отслеживать записи об инсталляциях Helm в кластере без потребности в Tiller.

Но подождите, это ещё не всё!

В этой статье я постарался рассказать о некоторых крупнейших изменениях в Helm 3. Однако этот список вовсе не является полным. План по Helm 3 включает в себя и другие изменения, такие как улучшения в формате чартов, улучшения в производительности для репозиториев чартов и новая событийная система, которой могут пользоваться разработчики чартов. Мы также предпринимаем усилия по тому, что Eric Raymond называется археологией кода, вычищая кодовую базу и обновляя компоненты, утратившие актуальность за последние три года.

Прим. перев.: Парадокс, но пакетный менеджер Helm 2 при успешном выполнении install или upgrade , т.е. имея release в состоянии success , не гарантирует, что ресурсы приложения успешно выкатились (к примеру, нет ошибок типа ImagePullError ). Возможно, новая событийная модель позволит добавлять дополнительные хуки для ресурсов и лучше контролировать процесс выката — скоро мы об этом узнаем.

С присоединением Helm к CNCF нас вдохновляет не только Helm 3, но и Chart Museum, замечательная утилита Chart Testing, официальный репозиторий чартов и другие проекты под эгидой Helm в CNCF. Мы уверены, что хорошее управление пакетами для Kubernetes настолько же важно для облачной (cloud native) экосистемы, насколько важны хорошие пакетные менеджеры для Linux.

Читайте также: