Краткое введение в helm

Что-то я давно ничего не писал о Kubernetes. А ведь в нём куча всего интересного происходит. Вот, например, посмотрели мы в прошлый раз как создавать k8s объекты через YAML конфигурацию, и было то хорошо. Но неудобно. Файлов же может быть много, копировать их туда-сюда тоже то ещё удовольствие. А если использовать менеджер пакетов helm, то как бы всё приятно сразу становится.

Кто такой helm

Helm — это установщик пакетов для Kubernetes. Примерно такой же, как npm для nodejs или apt-get для цивилизованного мира. Говоря helm, мы на самом деле подразумеваем целых два приложения: клиентский helm и его серверного, живущего в Kubernetes компаньона — tiller. На пару они могут искать, устанавливать, апгрэйдить и удалять пакеты-приложения, в хельмовской терминологии называемые чартами (chart).

‘Chart’ — не единственный странный выбор слов. Например, чарт, установленный в Kubernetes, уже называется релиз (release). Если установить чарт-пакет два раза, то получится два релиза. И т.п.

Но зато репозиторий для чартов так и называется — репозиторий. Ну и конечно, есть как «дефолтный» репозиторий, так и собственные, локальные.

Разобравшись с терминологией, теперь можно посмотреть на хельм поближе.

Установка

Тут всё просто. Для всех основных осей и их пакетных менеджеров (brew, apt-get, chocolatey) уже есть готовый пакет, и, например, для Мака brew install helm делает всё, что нужно.

Правда, таким образом устанавливается только клиентская утилита. Tiller всё ещё нужно устанавливать в k8s кластер руками. Но просто. Свой локальный кластер я запустил через minikube start, а tiller в него попал при помощи helm init.

Кстати, можно посмотреть, как именно выглядит конфигурация установки tiller. Если заменить команду установки на helm init --output yaml, то оказывается, что серверный компонент — это банальный Deployment с единственным контейнером внутри:

Основные операции

Акей, helm готов, нужно с ним чего-нибудь поделать. Например, найти какой-нибудь стандартный чарт и установить его, проверить статус и удалить к такой-то бабушке.

Поиск

helm search сразу выплёвывает все известные чарты, но на самом деле я уже примерно представляю, что именно мне нужно. Так что, сузив поиск при помощи helm search prometheus, нужный кандидат оказывается вверху списка, и можно сразу переходить к его установке:

Установка

stable/prometheus — вот, что мы будем устанавливать, и чего уж тут медлить:

Вот что, кстати, удобно. В конце логов установки идёт секция Notes, в которой сразу есть насколько полезных советов. Например, в строках 17-18 есть команды для проброса порта 9093 наружу, так что мы сможем зайти в админку одного из установленных прометеевских сервисов — Alertmanager.

Посмотреть Notes можно и позже с командой helm status %release name%.

Смотрим установленные чарты (релизы)

Посмотреть, что уже установлено, тоже довольно просто:

Кстати, запомните число во втором столбце (REVISION) — оно очень пригодится, когда мы будем делать апгрэйды и их откаты.

Удаляем релиз

Это вообще просто — helm delete %release name% и всё. Правда, удалять его прямо сейчас я не хочу, поэтому в конце команды добавлю флаг --dry-run, чтобы всё прошло понарошку:

Продвинутые операции

Кастомизируем установку

Устанавливать чарты «как есть» — просто, но бесполезно. Хотелось бы, конечно, сначала подстроить её под себя.

Смотрим, что вообще можно настроить

Изменить можно практически любой параметр чарта, но где вообще их искать? Ну, например, в helm inspect values:

Применяем настройки

Я серьёзно подрезал вывод команды inspect, но кастомизируемых параметров она вывела уйму. Например, один из первых параметров контролирует, будет ли Alertmanager, админку которого мы смотрели недавно, установлен. В теории, если положить что-то вроде alertmanager.enabled=false в файл конфигурации (нужно синтаксис проверить), то его можно передать сразу в install:

Но можно обойтись без файлов и подавать параметры напрямую:

Но есть ещё один момент. Так как Alertmanager уже был установлен, то почему бы просто не избавиться от него, проапгрэйдив уже существующий релиз?

Апгрэйд и откат назад

Апгрэйд релиа

Банально заменив install на upgrade, можно передать параметры кастомизации уже установленному чарту:

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

Откат релиза

Если вдруг мы передумаем, есть команда для отката назад. Нужно только найти номер последней успешной ревизии (помните тот второй столбец в helm list, который был равен единице?) передать её в rollback:

Список всех доступных ревизий можно глянуть через history:

Создаём свой чарт

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

Бойлерплейт

Есть классная команда helm create, которая создаст бойлерплейт, с которого уже можно двигаться дальше:

Chart.yaml, судя по всему, задаёт имя чарта, его версию и прочую стандартную ерунду. В папку же charts вроде бы кладут чарты-зависимости. Самый интересный файл чарта на этом этапе —  values.yaml. Именно из него шли те кастомизируемые параметры для install/upgrade, которые выдавал helm inspect values.

Папка templates

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

Это полезно. Например, я не хотел бы, чтобы мой деплйомент шёл со статическим именем. Лучше бы взять имя релиза, под которым его установят, и просто добавить какой-нибудь суффикс. Вот так:

.Release (как и .Values) — один из предустановленных объектов, на которые шаблоны могут ссылаться. Есть и другие места, откуда можно взять значения и даже целые куски конфигурации для подстановки, но замена значений не единственное, что шаблоны могут делать. Можно, например, ещё использовать управляющие конструкции вроде if или range, функции и даже конвейерные инструкции, так что {{ .Release.Name | upper }} — вполне себе валидная строка.

Упаковка и установка чарта

Папку с чартом прямо так можно и устанавливать — helm install ./demo-chart и все дела. Но если отгружать чарт в какой-нибудь репозиторий, или просто делиться им с друзьями, то лучше сначала его упаковать:

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

Мораль

Вот такой он, helm. Вполне себе, кстати, ничего — легко устанавливается, понятно работает, и если всё то, что я видел в его шаблонах, правда, то он просто невероятно мощный. Есть, правда, одна проблема. У меня локально уже установлено штуки четыре пакетных менеджера — brew для Мака и три для JavaScript. Куда так много? Можно их как-нибудь объединить в один? USB-C вроде ж победил остальные разъёмы, почему с пакетными менеджерами нельзя так же?