Чем принципиально отличается подход Helm (шаблонизация с values) от подхода Kustomize (патчи поверх чистых манифестов), и в какой ситуации новичку будет проще выбрать Kustomize, а не Helm?

Короткий ответ

Helm использует шаблонный язык (Go templates) и подстановку значений из values.yaml в заготовки манифестов с версионируемыми "релизами", а Kustomize работает без шаблонов, просто накладывая декларативные патчи на валидные YAML-манифесты; Kustomize проще выбрать, когда манифесты почти одинаковы между окружениями и нет необходимости в пакетировании/версионировании чарта как отдельного артефакта.

Как это работает подробнее

в Helm шаблоны содержат конструкции {{ .Values.x }}, {{ if }}, {{ range }}, что даёт гибкость, но требует понимания шаблонного языка и усложняет чтение "сырых" манифестов до рендера; Kustomize хранит сами манифесты в валидном YAML и описывает только дельту (патчи, генераторы ConfigMap/Secret, смену namespace/префиксов), что проще читать напрямую.

Пример кода

commands.shКопировать

$ kubectl apply -k overlays/dev

Что использовать на практике

• Практика. Kustomize встроен в kubectl (kubectl apply -k) и не требует установки дополнительного CLI, что снижает порог входа для небольших проектов; Helm предпочтительнее, когда нужно публиковать приложение как переиспользуемый артефакт с зависимостями, хуками и системой релизов/rollback.

Подводные камни

• Ошибка. думать, что Kustomize и Helm взаимоисключающие — на практике их комбинируют (Kustomize как post-processing над helm template); выбирать Helm "по умолчанию" для простого внутреннего сервиса с двумя окружениями, где хватило бы пары патчей Kustomize, и получать лишнюю сложность шаблонов без реальной потребности в ней.