Ответ
Я использовал 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или внешних инструментов