Краткое введение в 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.

Админка 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 вроде ж победил остальные разъёмы, почему с пакетными менеджерами нельзя так же?

6 комментариев для “Краткое введение в helm

  1. > USB-C вроде ж победил остальные разъёмы, почему с пакетными менеджерами нельзя так же?

    потому, что утром рано…
    с одной стороны есть системный пжкэдж-манагер для разных дистро; с другой — какой-нибудь cpan, pip или, не приведи господи, какой-нибудь npm, они кроссплатформенные, они не хотят ложиться в дистро; с третьей — счастье а-ля helm и иже. и каждый лепит своё, это оправдано, ибо «мне так лучше, я так вижу». как говорил герой одного фильма «всем на всё насрать».

    по идее имиджи для контейнеров должны были стать универсальными пакетами. не стали.

    на деле единственная система пэкэджей, которая везде работает — тарболл с сырцами и с автоконфигом. при условии, что сырцы собираются. девы чааасто такое юзают… да кому я рассказываю? 😉

    1. Даа, с разумной навигацией между постами пока проблема. Хорошо бы исправить, но пока это проигрывает по приоритету остальным задачам 🙁

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *