Helm vs Kustomize — что выбираешь и почему?

Пример

кода

helm upgrade --install ingress-nginx ingress-nginx/ingress-nginx -n ingress --create-namespace
kubectl apply -k overlays/prod
kubectl kustomize overlays/prod

Суть

Helm и Kustomize решают похожую боль — управление Kubernetes manifests, но философия разная. Helm генерирует YAML из chart templates и values, хранит release state и хорошо подходит для распространения приложений как пакетов. Kustomize берет обычный YAML и применяет overlays, patches, image transforms и generators без template language. Поэтому Helm сильнее для packaged third-party apps, а Kustomize часто проще для собственных manifests с несколькими окружениями.

Как работает

Helm chart содержит templates, values.yaml, Chart.yaml и может иметь dependencies. Команда helm install/upgrade создает release и хранит историю, rollback и hooks. Минус — templates могут стать сложной программой внутри YAML. Kustomize использует kustomization.yaml: bases/resources, patches, configMapGenerator, secretGenerator, images, labels. kubectl apply -k умеет применять kustomization напрямую. Минус — для сложной параметризации patches могут стать громоздкими. В GitOps часто встречается гибрид: Helm chart как source, Kustomize overlay сверху.

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

• Выбирать Helm только потому, что он популярнее. Для простых внутренних манифестов Kustomize может быть прозрачнее.
• Превращать Helm templates в нечитаемую логику. Это ухудшает review и diff.
• Хранить секреты в values.yaml без отдельной secret strategy.

Что отличает сильный ответ

Хороший ответ не должен быть религиозным. Для third-party chart обычно Helm. Для base плюс dev/stage/prod overlays — Kustomize. Для платформы важно, как инструмент интегрируется с GitOps, policy, diff, secret management и ownership команд.

• Называть Kustomize package manager
• Не знать helm release lifecycle
• Игнорировать GitOps diff и секреты

• Сравнивает подходы
• Приводит use cases
• Понимает trade-offs