Helm чарты для продукта

Продукт заказчика поставляется в разные среды: от облака до закрытых контуров клиентов без доступа в интернет. Для работы продукта нужен набор инфраструктурных сервисов: базы данных, брокеры сообщений, хранилище секретов, реестр образов и мониторинг.

Российский разработчик корпоративного ПО поставляет продукт в разные среды: от облака до закрытых контуров заказчиков без доступа в интернет. Инфраструктуру (базы данных, брокеры сообщений, хранилище секретов, мониторинг) приходилось собирать вручную из разрозненных open-source чартов. Каждый чарт имел свои настройки реестра образов, планирования подов и хранилища. Обновление любого компонента превращалось в риск.

Нужна была единая, воспроизводимая платформа, которую инженер разворачивает без ручных правок.

02.06.2026 - 12.08.2026

1 Тимлид, 1 Сениор DevOps, 2 QA инженера

Мы разработали 14 production-ready Helm-чартов:
- Базы данных: PostgreSQL (CloudNativePG), MySQL InnoDB Cluster, Valkey.
- Брокеры сообщений: NATS JetStream, RabbitMQ.
- Поиск и хранение: Elasticsearch, MinIO, Harbor.
- Безопасность: Vault, External Secrets Operator, cert-manager.
- Мониторинг: Prometheus, Loki, Alloy.
Чарты объединены helmfile-оркестратором. Он включает нужные сервисы флагами, сам расставляет порядок установки (например, cert-manager раньше операторов) и передаёт общие параметры.

Единые параметры для всей платформы. Реестр образов, node selector, affinity, tolerations и storage class задаются один раз и доходят до каждого пода. Если вендорский чарт не умеет читать общие параметры, то мы дорабатываем его шаблоны. Доработки хранятся отдельными патчами, а новая версия от вендора применяется поверх них без потери изменений.

Работа без интернета. Образы каждого чарта описаны в манифесте и автоматически зеркалируются в приватный реестр на этапе CI. Для любого образа можно задать собственную сборку.
Соблюдение зависимостей между сервисами. Оркестратор учитывает связи между компонентами и устанавливает их в правильном порядке. Сервисы включаются и отключаются флагами, а независимые компоненты ставятся параллельно.

Корректное удаление. Для чартов с операторами мы реализовали pre-delete хуки. Они находят и удаляют ресурсы релиза и ждут их фактического исчезновения. Благодаря этому не остаётся «зависших» объектов в состоянии Terminating.

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

Контроль качества. Для каждого чарта есть JSON-схема values и unit-тесты. Интеграционный тест в k3d поднимает кластер с локальным реестром, ставит чарт, проверяет air-gap и глобальные параметры на живом кластере, затем удаляет релиз. Все чарты используют общий CI-пайплайн, семантическое версионирование и документацию в Backstage.

1. Вендорские чарты не знают про общие параметры платформы.
У многих чартов есть собственные поля nodeSelector, affinity, tolerations и imagePullSecrets. Но они не читают общие настройки платформы, поэтому заданный глобально параметр просто не доходил до подов. Мы проверяли каждый чарт на реальном рендере и дорабатывали шаблоны через патчи. Ещё одна ловушка: пустой {} в Helm считается заполненным значением и блокирует переход к глобальной настройке. Эту особенность мы учли в шаблонах и значениях по умолчанию.

2. Образы, спрятанные в неочевидных местах.
Для работы без интернета нужно зеркалировать все образы. Но часть из них вендоры скрывают в ConfigMap, hook-задачах или init-контейнерах. Например, образ sidecar для бэкапов PostgreSQL задавался в ConfigMap, а не в Deployment. Мы ввели четырёхшаговую инвентаризацию образов: рендер оригинального чарта, поиск по файлам, анализ шаблонов и ConfigMap, чтение значений по умолчанию. Кроме того, при любом изменении шаблона мы сверяем список образов с манифестом зеркалирования.

3. Лимит Kubernetes на размер релиза.
Helm хранит релиз в Secret, а Secret ограничен 1 МБ. У стека мониторинга одни только CRD занимают около 4,4 МБ, что приводило к падению установки. 
Мы вынесли CRD в отдельный подчарт, который не попадает в Secret релиза. Также мониторинг был разделён на три независимых чарта.

4. Helm не обновляет CRD при апгрейде.
Обновление чарта не обновляло CRD, и кластер мог остаться со старой схемой. Автоматизировать это мы сознательно запретили, потому что слепое применение CRD может сломать работающие ресурсы. Вместо этого у каждого чарта есть процедура ручного обновления: сравнение с кластером через kubectl diff --server-side, чек-лист breaking changes (удалённые версии API, удалённые поля схемы, смена webhook конверсии) и только затем применение.

5. Оператор удаляется раньше своих ресурсов.
При выполнении команды helm uninstall Helm мог удалить оператор раньше, чем пользовательские ресурсы. Тогда ресурсы с финализаторами навсегда зависали в состоянии Terminating, и удалить их приходилось вручную. Мы ввели обязательные метки принадлежности на все ресурсы и pre-delete хуки. Они находят ресурсы релиза, удаляют их и ждут реального исчезновения из API без фиксированных пауз.

Вся платформа разворачивается командой helmfile sync, установка одинакова в облаке и в закрытом контуре. Обновления компонентов проходят по понятной процедуре, а не вручную.