Какой у вас опыт работы с Kustomize?

«Какой у вас опыт работы с Kustomize?» — вопрос из категории Kubernetes, который задают на 23% собеседований Devops Инженер. Ниже — развёрнутый ответ с разбором ключевых моментов.

Ответ

Я использовал Kustomize для управления конфигурациями Kubernetes в разных окружениях (dev, staging, production) в нескольких проектах. Основная задача — избежать дублирования манифестов при настройке параметров для каждого окружения.

Типичная структура проекта:

base/
├── deployment.yaml
├── service.yaml
└── kustomization.yaml
overlays/
├── dev/
│   ├── kustomization.yaml
│   └── patch-replicas.yaml
└── prod/
    ├── kustomization.yaml
    └── patch-resources.yaml

Конкретные задачи, которые я решал:

  • Настройка разного количества реплик для dev (1) и prod (3+) через patchesStrategicMerge
  • Подстановка переменных окружения через configMapGenerator и secretGenerator
  • Управление образами контейнеров через images поле
  • Интеграция с CI/CD пайплайнами (GitLab CI, GitHub Actions) для kubectl apply -k

Пример kustomization.yaml для production:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ../../base

patchesStrategicMerge:
- patch-resources.yaml

images:
- name: myapp
  newTag: v1.2.3

configMapGenerator:
- name: app-config
  files:
  - config.properties

Преимущества, которые я оценил:

  • Нативная интеграция с kubectl (с версии 1.14)
  • Простота и прозрачность — видно все изменения в виде патчей
  • Отсутствие шаблонизации, что уменьшает сложность отладки
  • Хорошая сочетаемость с GitOps подходами (FluxCD, ArgoCD)

Ограничения, с которыми столкнулся:

  • Для сложных условных конструкций приходится создавать много файлов патчей
  • Нет встроенной поддержки зависимостей между приложениями (в отличие от Helm charts)
  • Динамические значения требуют использования vars или внешних инструментов