Поиск и установка готовых чартов

Главная суперсила Helm для начала — ставить чужой production-ready софт одной командой.

Готовый чарт уже содержит выверенные манифесты Deployment, Service, StatefulSet и десятки настраиваемых параметров — вам остаётся лишь подставить свои значения.

Прежде чем учиться писать чарты, полезно научиться их потреблять. 80% повседневной работы с Helm — это установка готовых чартов: баз данных, очередей, ingress-контроллеров, систем мониторинга. Разберём полный цикл на примере PostgreSQL.

Подумайте, что значит развернуть PostgreSQL в Kubernetes вручную. Вам понадобятся StatefulSet с правильной стратегией обновления, headless-Service для стабильных DNS-имён подов, обычный Service для клиентов, PersistentVolumeClaim под данные, ConfigMap с настройками сервера, Secret с паролями, probe-проверки готовности и живости, а ещё корректные политики безопасности. Это сотни строк YAML, в которых легко ошибиться и которые нужно поддерживать. Готовый чарт — это та же самая работа, но уже проделанная и протестированная инженерами, которые занимаются именно этой базой данных. Вы получаете их экспертизу «в коробке».

Хорошая аналогия — пакетные менеджеры вроде apt или npm. Никто не собирает nginx из исходников каждый раз; вы пишете apt install nginx и получаете рабочий бинарник с разумными дефолтами. Helm играет ту же роль для целых приложений в кластере: репозиторий чартов — это аналог пакетного репозитория, а чарт — аналог пакета. Разница в том, что приложение в кластере состоит из множества объектов и почти всегда требует настройки под конкретное окружение, поэтому у чартов есть мощный слой параметров — values.

Шаг 1: подключаем репозиторий и обновляем индекс

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update bitnami

repo update скачивает свежий index.yaml. Без него search покажет старый список версий — частая причина «почему не вижу новую версию чарта».

Что вообще такое репозиторий чартов? Это всего лишь HTTP-сервер, отдающий файл index.yaml и набор упакованных архивов .tgz. В index.yaml перечислены все чарты, их версии, контрольные суммы и ссылки на скачивание. Когда вы делаете repo add, Helm запоминает URL и один раз скачивает индекс; команда search работает локально по этой скачанной копии и не ходит в сеть. Поэтому индекс может устареть, и его нужно периодически обновлять. Понимание этой механики снимает много вопросов: например, становится ясно, почему добавление репозитория не «устанавливает» ничего в кластер — это операция чисто на вашей машине.

Шаг 2: ищем чарт

helm search repo postgresql
helm search repo postgresql --versions | head   # все доступные версии

Вывод:

NAME               	CHART VERSION	APP VERSION	DESCRIPTION
bitnami/postgresql 	13.2.24      	16.1.0     	PostgreSQL ...

Различайте две версии: CHART VERSION (версия упаковки чарта) и APP VERSION (версия самого PostgreSQL внутри). Они меняются независимо.

Шаг 3: изучаем настройки чарта перед установкой

У хорошего чарта десятки параметров. Не угадывайте — посмотрите дефолтные values:

helm show values bitnami/postgresql | head -40
helm show readme bitnami/postgresql   # документация чарта

Так вы узнаете точные пути параметров, например auth.username, auth.database, primary.persistence.size.

Шаг 4: устанавливаем с переопределением значений

Переопределить дефолты можно прямо в командной строке через --set или (лучше) через файл -f my-values.yaml.

helm install orders-db bitnami/postgresql   --namespace data --create-namespace   --set auth.username=app   --set auth.database=orders   --set primary.persistence.size=8Gi   --version 13.2.24

Флаг --version фиксирует версию чарта — обязателен для воспроизводимости в проде. Без него Helm возьмёт последнюю версию из индекса, и завтрашняя установка может отличаться от сегодняшней.

Первый аргумент orders-db — это имя релиза, и оно важнее, чем кажется. Один и тот же чарт можно установить в кластер много раз под разными именами: orders-db, billing-db, analytics-db — это будут три независимых релиза PostgreSQL со своими данными, своими values и своей историей. Имя релиза становится префиксом большинства создаваемых объектов, поэтому выбирайте его осмысленно и стабильно: переименование релиза на практике означает удаление старого и создание нового, то есть фактически пересоздание приложения. Флаг --create-namespace избавляет от отдельного kubectl create namespace — Helm создаст namespace, если его ещё нет.

--set против -f: когда что

Оба механизма переопределяют дефолты, но у них разная область применения. --set хорош для одного-двух простых значений и для секретов, которые не хочется класть в файл (например, пароль из переменной окружения CI). Файл -f хорош для всего остального: он читаем, его легко ревьюить в pull request и он остаётся в истории git. Важно, что флаги складываются: можно держать общий файл с настройками и поверх него точечно подменять одно значение через --set. Приоритет идёт слева направо — последующий источник перекрывает предыдущий, а --set всегда выигрывает у файлов.

Файл значений вместо длинной строки --set

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

# orders-db.values.yaml
auth:
  username: app
  database: orders
primary:
  persistence:
    size: 8Gi
  resources:
    requests:
      cpu: 250m
      memory: 256Mi

helm install orders-db bitnami/postgresql   -n data --create-namespace   -f orders-db.values.yaml --version 13.2.24

Файл значений можно (и нужно) хранить в git рядом с инфраструктурным кодом — это и есть «версионируемая конфигурация окружения».

Как Helm применяет это под капотом

При install Helm: (1) загружает чарт, (2) сливает дефолтные values.yaml чарта с вашими переопределениями, (3) рендерит шаблоны в готовые манифесты, (4) отправляет их в API кластера и (5) сохраняет запись о релизе (ревизия 1) в Secret. Увидеть, что именно отрендерится, можно не применяя:

helm install orders-db bitnami/postgresql   -f orders-db.values.yaml --dry-run --debug | head -60

--dry-run прогоняет рендер без записи в кластер — бесценно для проверки перед боевой установкой.

Стоит задержаться на шаге слияния values, потому что именно здесь живёт большинство сюрпризов. У чарта есть собственный values.yaml с дефолтами; ваши переопределения накладываются поверх по принципу глубокого слияния словарей, ключ за ключом. Это значит, что задав primary.persistence.size, вы меняете только этот лист дерева, а соседние ветки primary.resources, primary.podLabels и прочие остаются дефолтными. Из этого же следует тонкость со списками: массивы YAML не сливаются поэлементно, а заменяются целиком. Если в дефолтах есть список из трёх элементов, а вы задаёте список из одного — в результате останется один, а не четыре. Это частый источник недоумения с переопределением переменных окружения или томов.

Последний этап — запись о релизе. Helm не «забывает» установку: он сохраняет в кластере снимок того, что и с какими значениями развернул. Этот снимок и называется ревизией; первая установка — это ревизия 1. Благодаря ему Helm умеет апгрейдить и откатывать релизы, не имея под рукой исходного чарта. Подробнее этот механизм разберём в следующих уроках, но держите в голове уже сейчас: install — это не просто «применить YAML», а «применить и запомнить».

Частые ошибки

Установка без --version. «Вчера работало, сегодня нет» — потому что апстрим выпустил новую версию чарта.
Угадывание путей values. Всегда сверяйтесь с helm show values; неверный путь в --set молча игнорируется.
Тип значения в --set. --set replicas=3 даёт число, а --set tag=01 может стать числом 1 — для строк используйте --set-string.

Итог

Полный цикл: repo add → repo update → search → show values → install.
Различайте CHART VERSION и APP VERSION; в проде фиксируйте --version.
Файл -f values.yaml лучше длинной цепочки --set и хранится в git.