Как стать автором
Обновить

Комментарии 11

Было бы классно если бы в статье про Helm было описано зачем он нужен.
С обывательской позиции разработчика который не работает с бэкендом, есть kubernetes, в нем есть деплойменты, там можно указать образ. Образы льются куда нибудь вроде докерхаб или гугловый репозиторий. Какую именно задачу решает хелм?

Может быть кто нибудь из коментаторов сможет подсказать.

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


В rhel/centos:


yum install unzip # можно ведь и самому собрать из исходников?

В helm:


helm install prometheus-operator # попробуйте сами создать такого монстрика из 46 yml-артефактов для кубера

Понятное дело, что функционал можно не только удобно получить, но и удалить, и обновить, и откатить к предыдущей версии.

Образы льются куда нибудь вроде докерхаб или гугловый репозиторий

На пути от образа до деплоймента стоит пропасть из конфигов Кубернетеса.

Представьте, что у вас есть бинарник. Например, скомпилированная библиотека .so.
Ну да, есть. Но ведь ее надо положить в систему. Надо сделать ldconfig. Надо создать линки типа libabc.so.2 -->libabc.so.2.0.6. И тут вы используете какие-то скрипты или профильные утилиты для аккуратной упаковки со всякими post/pre-install и post/pre-delete скриптами. В результате вы получаете в место файла .so, например, какой-нибудь .deb пакет.
А когда вам захочется обновить библиотеку, вы просто дадите короткую команду.

Вот образ докера в этой аллегории — библиотека .so. А ворох скриптов по его установке, апргрейду и даунгрейду — пакет Helm.
Коротко: это package manager для Kubernetes.

Helm оперирует такими вещами как charts.
Внутри одно чарта у тебя:
— Шаблоны для самого kubernetes
— Всякие переменные
— Название, версия и все такое

Ну и все прелести типичного package manager: можно указывать зависимости на другие чарты.

В итоге это приводит к тому что можно писать вот так:
helm install my-project

Где my-project зависит от frontend, backend, database, message-queue.
И helm это раскатает в kubernetes.

Потом можно делать вот такие вещи:
helm history my-project # История версий
helm rollback my-project 128 # Сделать роллбек на вот такую версию
Один из юз-кейсов хелма: у меня есть микросервис (на самом деле не один), который я запускаю независимо для нескольких стран. У них типовая конфигурация, но для каждой страны значение отдельных параметров среды разное. Helm позволяет иметь шаблон конфигурации, на основе которого я могу развернуть все имеющиеся страны, не занимаясь копипастингом.

Автор этого материала ниже развернуто ответил, а ещё подробнее обещаем раскрыть в следующих статьях по теме.

Q: Какую именно задачу решает helm?

Helm может использоваться для выката приложений в кластер kubernetes. Helm не обрабатывает исходный код приложения, а работает с образами, для создания которых потребуется инструмент CI/CD.

Q: Почему просто не использовать `kubectl apply -f`?

Обычно проблемы начинаются когда идёт автоматизация процесса выката, настройка процессов CI/CD. К примеру, рассмотрим задачу с выкатом в различные окружения.

Каждое окружение имеет свои потребности. Требуется различный набор kubernetes-ресурсов, отличаются параметры у ресурсов (сертификаты, доступы баз данных, сопутствующих сервисов, и т.д.). Опять же, продовые доступы и сертификаты не должны храниться в незашифрованном виде в репозитории.

Появляется потребность в шаблонизации и работе с секретами, и это только вершина айсберга.

Таким образов, требуется комплексный подход к выкату, так почему бы не использовать helm?

Helm содержит инструменты для создания, отладки, компоновки и сопровождения конфигураций kubernetes-ресурсов, а также упрощает управление выкатом приложений, за счёт хуков, версионирования, возможности многократного использования Chart-ов и многого другого.

Kubernetes-ресурсы:
  1. Кастомизация и переиспользование за счёт шаблонизации.
  2. Официальный репозиторий с готовыми решениями, из которых можно компоновать собственные приложения.
  3. Инструменты отладки (lint).
  4. Использование секретов, рендер и использование других helm-плагинов.

Выкат:
  1. Установка, обновление, удаление инсталяций.
  2. Версионирование, откат до определённой версии. К примеру, откат при неудавшемся выкате.
  3. Хуки, позволяющие вмешиваться в жизненный цикл релиза. К примеру, делать дамп базы перед удалением инсталяции или выкатывать фикстурные данные после установки, оповещать по API сопутствующие сервисы об установке, обновлении, удалении и т.д.

Об этом и многом другом мы постараемся рассказать в этом цикле статей про helm.

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

Началом существования helm принято считать презентацию на KubeCon в San Francisco в ноябре 2015-го года. Менее чем через год вышла вторая версия и в настоящий момент она является актуальной.

Данная статья является анонсом следующей версии и нет никакой информации по дате выхода.

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

The release object contains information about a release, where a release is a particular installation of a named chart and values. This object describes the top-level metadata about a release.

At minimum, there are two necessary pieces of data a Release must track:

The name of the release
The curretly deployed version (release version Secret) of this release
The release object persists for the duration of an application lifecycle, and is the owner of all release version Secrets, as well as of all objects that are directly created by the Helm chart. (These relationships may be represented by owner references.)

With this change, release names can now be scoped to namespace, instead of globally scoped as they were with Helm 2.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий