Kustomize Как навести порядок в Kubernetes YAML без головной боли

Представьте: вы работаете с Kubernetes, и у вас есть приложение, которое нужно развернуть в нескольких окружениях – dev, staging, production. Каждое окружение требует немного разных конфигураций: где-то больше реплик, где-то другие лимиты по CPU/памяти, где-то специфичные переменные окружения.

Знакомая ситуация, правда? Что вы обычно делаете? Копируете YAML-файлы и начинаете вручную менять их? Или, может быть, пытаетесь использовать сложный шаблонизатор, который добавляет больше абстракций, чем решает проблем?

В какой-то момент это превращается в настоящий кошмар: изменения в базовой конфигурации приходится дублировать везде, возникают ошибки, а процесс обновления становится пыткой. Хочется, чтобы было просто: взять базовый набор манифестов и поверх него «наложить» нужные изменения для каждого случая, не трогая оригинал.

Kustomize: Декларативное управление конфигурациями Kubernetes

К счастью, такое решение существует, и оно называется Kustomize. Это инструмент, разработанный SIG CLI сообществом Kubernetes, который стал де-факто стандартом для декларативного управления конфигурациями YAML.

Его философия проста и гениальна: никаких шаблонов. Kustomize работает напрямую с вашими «сырыми» YAML-файлами, позволяя вам применять к ним «патчи» и «наложения», чтобы создавать уникальные варианты конфигураций. При этом ваши оригинальные YAML-файлы остаются абсолютно нетронутыми. Это как если бы вы брали чертеж дома и накладывали на него прозрачные пленки с изменениями для «летнего» или «зимнего» варианта, не меняя сам чертеж.

Kustomize понимает объекты Kubernetes, что делает его особенно мощным. Он не просто текстовый процессор, а умный помощник, который знает, как правильно модифицировать Kubernetes API-объекты.

Ключевые возможности Kustomize: Когда YAML становится гибким

Давайте углубимся в то, что Kustomize умеет делать и почему он так полюбился разработчикам.

1. Декларативное управление без шаблонизаторов

Основное отличие Kustomize от того же Helm – это его подход «без шаблонов». Вы не пишете Go-шаблоны или Jinja2, вы работаете с обычным YAML. Это снижает порог входа и делает конфигурации гораздо более читаемыми и предсказуемыми.

Вы просто описываете, какие изменения нужно внести в ваши базовые манифесты, а Kustomize сам генерирует итоговый YAML. Это декларативный подход в чистом виде, что очень хорошо сочетается с идеологией Kubernetes.

2. Сохранение оригинальных манифестов

Представьте, что вы используете какой-то сторонний Chart или набор манифестов для развертывания Prometheus или Nginx Ingress Controller. Если вам нужно внести небольшие изменения – например, добавить специфичный лейбл или изменить образ контейнера – обычно приходится либо форкать репозиторий, либо использовать сложные скрипты.

Kustomize решает эту проблему элегантно. Вы можете взять оригинальные манифесты как «базу» и создать свой файл kustomization.yaml, в котором опишете все необходимые изменения. Оригиналы при этом останутся нетронутыми, что значительно упрощает обновление до новых версий базовых конфигураций.

3. Управление вариантами конфигураций (Overlays)

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

Вы определяете общую «базу» (base) с общими для всех окружений настройками. Затем для каждого окружения создаете «оверлей» (overlay), который ссылается на эту базу и добавляет специфичные для данного окружения патчи (например, больше реплик для production, другой Ingress hostname для staging и т.д.).

Вот как это может выглядеть в файловой системе:

~/someApp
├── base
│   ├── deployment.yaml
│   ├── kustomization.yaml
│   └── service.yaml
└── overlays
    ├── development
    │   ├── cpu_count.yaml
    │   ├── kustomization.yaml
    │   └── replica_count.yaml
    └── production
        ├── cpu_count.yaml
        ├── kustomization.yaml
        └── replica_count.yaml

Каждый kustomization.yaml в директории overlays ссылается на base и применяет свои специфичные патчи. Это дает невероятную гибкость и порядок в ваших конфигурациях.

4. Встроенная интеграция с kubectl

Самое приятное – вам, возможно, даже не придется устанавливать Kustomize отдельно! Начиная с версии kubectl v1.14, Kustomize встроен прямо в клиент Kubernetes.

Вы можете проверить версию Kustomize, используемую вашим kubectl, командой:

kubectl version --client

Это означает, что kubectl сам понимает kustomization.yaml файлы и может применять их напрямую. Например, чтобы развернуть конфигурацию для продакшена, достаточно:

kustomize build ~/someApp/overlays/production | kubectl apply -f -

Или, если у вас более свежая версия kubectl, можно просто использовать:

kubectl apply -k ~/someApp/overlays/production

Такая нативная интеграция значительно упрощает CI/CD пайплайны и ручное управление кластером.

Как это работает под капотом: немного магии YAML

Kustomize не просто заменяет строки. Он понимает структуру Kubernetes объектов и умеет выполнять «умные» патчи. Вы можете добавлять общие лейблы ко всем ресурсам, менять имена ConfigMap'ов, добавлять префиксы к именам, изменять количество реплик и многое другое, просто описывая это в kustomization.yaml.

Вот пример базового kustomization.yaml и его ресурсов:

# kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
labels:
includeSelectors: true
  pairs:
    app: myapp
resources:
  - deployment.yaml
  - service.yaml
configMapGenerator:
  - name: myapp-map
    literals:
      - KEY=value

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
        - name: myapp
          image: myapp
          resources:
            limits:
              memory: "128Mi"
              cpu: "500m"
          ports:
            - containerPort: 6060

# service.yaml
apiVersion: v1
kind: Service
metadata:
  name: myapp
spec:
  selector:
    app: myapp
  ports:
    - port: 6060
      targetPort: 6060

Заметьте, как в kustomization.yaml мы добавляем общий лейбл app: myapp и генерируем ConfigMap. Kustomize «пропатчит» эти ресурсы, добавив лейблы и создав ConfigMap, не изменяя deployment.yaml и service.yaml.

Итоговый YAML можно получить командой:

kustomize build ~/someApp

Практическое применение: где Kustomize покажет себя во всей красе

Kustomize – это не просто модный инструмент, это настоящий рабочий конь для многих сценариев:

• Управление несколькими окружениями: Как мы уже говорили, это его основная задача. Dev, Staging, Prod, QA – каждое со своими нюансами, но на базе единого конфига.
• Развертывание сторонних приложений: Вам нужно развернуть Prometheus, Grafana или какой-то оператор, но с небольшими кастомизациями? Kustomize позволит вам это сделать, не меняя оригинальные манифесты из репозитория проекта.
• Добавление общих конфигураций: Нужно добавить всем Deployment'ам в проекте специфичный imagePullSecrets или nodeSelector? Kustomize сделает это централизованно через kustomization.yaml.
• A/B тестирование: Быстро создать несколько вариантов развертывания для A/B тестирования, меняя лишь небольшие части конфигурации.

Выводы: Стоит ли попробовать Kustomize?

Если вы регулярно работаете с Kubernetes и устали от ручной правки YAML-файлов, Kustomize – это то, что вам нужно. Он предлагает элегантный, декларативный и нативный способ управления конфигурациями, который значительно упрощает жизнь.

Его интеграция с kubectl делает его еще более привлекательным. Вы получаете мощный инструмент прямо из коробки, без лишних зависимостей.

Kustomize особенно хорошо подходит тем, кто ценит простоту, читаемость и не хочет погружаться в сложности шаблонизаторов для базовых задач. Он позволяет поддерживать ваши конфигурации в чистоте и порядке, минимизируя риск ошибок.

Так что, если вы еще не знакомы с Kustomize, настоятельно рекомендую уделить ему время. Он может стать вашим лучшим другом в управлении Kubernetes-кластерами!