🥊 Helm vs Kustomize: Вечная битва или идеальный симбиоз?
Салют! 👋
Сегодня затронем тему, из-за которой в курилках девопсов доходит до драки. Как управлять манифестами?
В левом углу ринга - Helm (пакетный менеджер, шаблоны,
В правом углу - Kustomize (оверлеи, патчи, native k8s).
Многие пытаются выбрать один инструмент на всё. И это ошибка. Давайте разберем, где каждый из них король.
⚓️ Helm: Король дистрибуции
Helm - это про упаковку.
Если вы хотите поставить Redis, Prometheus или Ingress-Nginx - вы берете Helm. Почему?
1. Параметризация: Вам не надо знать внутренности чарта, просто переопределите
2. Хуки: Возможность запустить джобу перед установкой (например, миграцию БД).
3. Версионирование: Удобно откатываться (
🔴 Боль: "Template Hell".
Вы когда-нибудь отлаживали чарт на 500 строк с вложенными
🦎 Kustomize: Король конфигурации
Kustomize - это про вариативность.
Он встроен прямо в
1. Чистый YAML: Никаких фигурных скобок. Это валидный YAML, который можно проверить линтером.
2. Наглядность: Вы четко видите в папке
3. Композиция: Легко собрать приложение из кусков.
🔴 Боль: Нет логики.
В Kustomize нельзя написать
💡 Мой рецепт (Best Practice)
Я перестал выбирать и использую гибридный подход.
1. Сторонний софт (Redis, ELK, Cert-Manager) 👉 Helm.
Не изобретайте велосипед. Возьмите готовый чарт, напишите к нему
2. Свои микросервисы (Internal Apps) 👉 Kustomize.
Для своих приложений шаблоны часто избыточны. У вас меняется только тег образа и Env-vars. Kustomize здесь чище и понятнее разработчикам.
3. Высший пилотаж: Helm + Kustomize.
Есть такая техника:
Так вы получаете гибкость Helm и точность Kustomize.
#k8s #helm #kustomize #gitops #tools #battle
Подпишись 👉@devopslib
Салют! 👋
Сегодня затронем тему, из-за которой в курилках девопсов доходит до драки. Как управлять манифестами?
В левом углу ринга - Helm (пакетный менеджер, шаблоны,
{{ .Values }}).В правом углу - Kustomize (оверлеи, патчи, native k8s).
Многие пытаются выбрать один инструмент на всё. И это ошибка. Давайте разберем, где каждый из них король.
⚓️ Helm: Король дистрибуции
Helm - это про упаковку.
Если вы хотите поставить Redis, Prometheus или Ingress-Nginx - вы берете Helm. Почему?
1. Параметризация: Вам не надо знать внутренности чарта, просто переопределите
values.yaml.2. Хуки: Возможность запустить джобу перед установкой (например, миграцию БД).
3. Версионирование: Удобно откатываться (
helm rollback).🔴 Боль: "Template Hell".
Вы когда-нибудь отлаживали чарт на 500 строк с вложенными
{{ if }}, циклами range и проблемами с отступами YAML? Это ад. Читать чужой (или свой спустя месяц) Helm-шаблон - больно.🦎 Kustomize: Король конфигурации
Kustomize - это про вариативность.
Он встроен прямо в
kubectl (-k). Идея проста: есть Base (общий манифест) и Overlays (dev, stage, prod), которые накладывают патчи поверх базы.1. Чистый YAML: Никаких фигурных скобок. Это валидный YAML, который можно проверить линтером.
2. Наглядность: Вы четко видите в папке
prod, чем именно он отличается от dev (другой CPU limit, другая репликация).3. Композиция: Легко собрать приложение из кусков.
🔴 Боль: Нет логики.
В Kustomize нельзя написать
if enabled: true. Если вам нужно динамически менять структуру манифеста в зависимости от переменной - придется дублировать код или писать сложные патчи.💡 Мой рецепт (Best Practice)
Я перестал выбирать и использую гибридный подход.
1. Сторонний софт (Redis, ELK, Cert-Manager) 👉 Helm.
Не изобретайте велосипед. Возьмите готовый чарт, напишите к нему
values-prod.yaml и радуйтесь.2. Свои микросервисы (Internal Apps) 👉 Kustomize.
Для своих приложений шаблоны часто избыточны. У вас меняется только тег образа и Env-vars. Kustomize здесь чище и понятнее разработчикам.
3. Высший пилотаж: Helm + Kustomize.
Есть такая техника:
helm template генерит "сырой" манифест, а Kustomize потом патчит то, что в Helm чарте не предусмотрено.
helm template my-chart . | kustomize build . | kubectl apply -f -
Так вы получаете гибкость Helm и точность Kustomize.
#k8s #helm #kustomize #gitops #tools #battle
Подпишись 👉@devopslib
❤4😱3👍1💩1