Helm vs Kustomize: шаблонизация или патчи

Для чего создавался каждый

Helm появился как система управления пакетами для Kubernetes, аналогично apt или yum, чтобы упаковывать, распространять и устанавливать готовые приложения со всеми зависимостями. Kustomize был создан как нативный для kubectl способ кастомизации базовых конфигураций для разных окружений, оставаясь в рамках чистого YAML без шаблонов.

В чём реально отличаются

Главное различие — в парадигме. Helm — это шаблонизатор. Вы пишете шаблоны Go Template в файлах templates/, а Helm, используя значения из values.yaml, генерирует готовые манифесты на этапе helm install. Это генеративная конфигурация. Kustomize работает по принципу патчинга. Вы имеете базовый набор манифестов (например, для dev) и накладываете на них стратегические merge-патчи (patchesStrategicMerge) или JSON-патчи для создания конфигураций для prod, staging и т.д. Это декларативная модификация.

Технически Helm управляет релизами через свой tiller (в версии 2) или напрямую через API (Helm 3), храня историю в Secrets. Kustomize не имеет концепции релиза — это просто клиентский инструмент для сборки итогового YAML, который затем применяется через kubectl apply. У Helm есть централизованные репозитории (Artifact Hub) для поиска и скачивания чартов. Kustomize предполагает, что ваши базовые манифесты уже находятся в вашем контроле версий.

Сложность отладки отличается. В Helm нужно отрендерить шаблон командой helm template, чтобы увидеть итоговый YAML. В Kustomize вы всегда видите и базовые файлы, и патчи, а итоговая сборка (kustomize build) предсказуемо их объединяет.

Когда выбрать первый

Выбирайте Helm, если вы распространяете приложение сторонним пользователям или командам. Чарт — это стандартизированный пакет, который можно версионировать и публиковать. Он обязателен, когда приложение состоит из множества взаимосвязанных ресурсов (Deployment, Service, ConfigMap, Secret, RBAC), которые нужно инсталлировать как единое целое.

Helm необходим, когда требуется сложная логика в шаблонах: условные операторы, циклы для генерации конфигураций в зависимости от входных значений. Например, создание переменного количества реплик или контейнеров на основе values.

Также Helm удобен для управления зависимостями через Chart.yaml. Если вашему приложению нужна база данных или redis, вы можете объявить их как subcharts или зависимости из внешних репозиториев.

Когда выбрать второй

Выбирайте Kustomize, если вы управляете внутренними конфигурациями для нескольких схожих окружений (dev, stage, prod) в рамках одного кластера или проекта. Его сила — в простоте и наглядности. Инженер видит только YAML, без слоя абстракции в виде шаблонов.

Kustomize идеален, когда у вас уже есть рабочие базовые манифесты и нужно лишь слегка их модифицировать для конкретного случая: добавить лейбл, изменить количество реплик, подставить другой ConfigMap. Это часто встречается в GitOps-практиках, где конфигурация хранится в Git, а разница между окружениями минимальна.

Он предпочтительнее, если ваша организация избегает сторонних package managers на кластере или хочет максимально использовать нативные возможности kubectl (kustomize встроен в kubectl apply -k с версии 1.14).

Могут ли работать вместе

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

Работает это так: вы можете использовать Helm для получения “базовых” манифестов через helm template и сохранить их в директорию. Затем применить к этим сгенерированным, но статичным манифестам Kustomize для внесения точечных правок, специфичных для вашего кластера (например, изменить nodeSelector или добавить sidecar-контейнер для логирования).

Более элегантный способ — использовать Kustomize с плагином helmChartInflationGenerator. В этом случае kustomization.yaml напрямую ссылается на Helm-чарт, вызывает его рендеринг в памяти и затем применяет к результату свои патчи. Так сохраняется единая точка управления (kustomization.yaml), но задействуется мощь Helm-шаблонов. Это признаёт, что ни один инструмент не является серебряной пулей, и их гибридное использование часто даёт наиболее гибкий и поддерживаемый результат.