Краткое введение в Kustomize

Прим. перев.: Статью написал Scott Lowe — инженер с большим стажем в ИТ, являющийся автором/соавтором семи печатных книг (преимущественно по VMware vSphere). Сейчас он работает в её дочерней организации VMware — Heptio (поглощена в 2016 году), специализируясь на облачных вычислениях и Kubernetes. Сам же текст служит ёмким и простым для понимания введением в управление конфигурациями для Kubernetes с помощью технологии Kustomize, недавно вошедшей в состав K8s.



Kustomize – это инструмент, позволяющий пользователям «настраивать простые и свободные от шаблонов файлы YAML под различные цели, оставляя оригинальный YAML нетронутым и пригодным для использования» (описание позаимствовано прямо из репозитория kustomize на GitHub). Kustomize можно запускать напрямую или, начиная с Kubernetes 1.14, использовать kubectl -k для доступа к его функциям (хотя по состоянию на Kubernetes 1.15 отдельный бинарник новее, чем возможности, встроенные в kubectl). (Прим. перев.: А с недавним релизом Kubernetes 1.16 kustomize поддерживается ещё и в утилите kubeadm.) В этой публикации я хочу познакомить читателей с основами kustomize.

В своей простейшей форме/применении kustomize — это просто набор ресурсов (YAML-файлов, которые определяют объекты Kubernetes: Deployments, Services и т.д.) плюс список инструкций по изменениям, которые необходимо внести в эти ресурсы. Подобно тому, как make использует набор инструкций, содержащийся в Makefile, а Docker собирает контейнер на основе инструкций из Dockerfile, kustomize использует kustomization.yaml для хранения предписаний о том, какие изменения пользователь хочет внести в набор ресурсов.

Вот пример файла kustomization.yaml:

resources:
- deployment.yaml
- service.yaml
namePrefix: dev-
namespace: development
commonLabels:
  environment: development

Не буду пытаться рассказать обо всех возможных полях в файле kustomization.yaml (об этом неплохо написано здесь), но проведу краткое объяснение конкретного примера:

• Поле resources указывает, что (какие ресурсы) будет менять kustomize. В данном случае он будет искать ресурсы в файлах deployment.yaml и service.yaml в своем каталоге (при необходимости можно указывать полные или относительные пути).
• Поле namePrefix предписывает kustomize'у добавлять определенный префикс (в данном случае — dev-) к атрибуту name всех ресурсов, определенных в поле resources. Таким образом, если в Deployment'е есть name со значением nginx-deployment, kustomize сделает из него dev-nginx-deployment.
• Поле namespace предписывает kustomize'у добавлять заданное пространство имен ко всем ресурсам. В данном случае, Deployment и Service попадут в пространство имен development.
• Наконец, поле commonLabels содержит набор лейблов, который будет добавлен ко всем ресурсам. В нашем примере kustomize присвоит ресурсам метку с названием environment и значением development.

Если пользователь выполнит kustomize build . в директории с файлом kustomization.yaml и необходимыми ресурсами (т.е. файлами deployment.yaml и service.yaml), то на выходе он получит текст с изменениями, прописанными в kustomization.yaml.


Прим. перев.: Иллюстрация из документации проекта по «простому» использованию kustomize

Вывод можно перенаправить, если необходимо зафиксировать изменения:

kustomize build . > custom-config.yaml

Выходные данные детерминированы (при одинаковых данных на входе будут получаться одни и те же результаты на выходе), поэтому можно не сохранять результат в файл. Вместо этого его можно сразу передать в другую команду:

kustomize build . | kubectl apply -f -

Доступ к функциям kustomize также можно получить через kubectl -k (начиная с версии 1.14 Kubernetes). Однако имейте в виду, что отдельный пакет kustomize быстрее обновляется, нежели интегрированный в kubectl (по крайне мере, так обстоят дела с релизом Kubernetes 1.15).

Читатели могут спросить: «Зачем нужны все эти сложности, если можно отредактировать файлы напрямую?». Отличный вопрос. В нашем примере действительно можно модифицировать файлы deployment.yaml и service.yaml напрямую, но что, если они являются форком чьего-либо проекта? Непосредственное изменение файлов затрудняет (если вообще не делает невозможным) rebase форка, когда вносятся изменения в источник/исходник. Использование kustomize позволяет централизовать эти изменения в файле kustomization.yaml, оставив оригинальные файлы нетронутыми и, таким образом, облегчая при необходимости rebase исходных файлов.

Преимущества kustomize становятся очевидными в более сложных случаях использования. В приведенном выше примере kustomization.yaml и ресурсы находятся в одной и той же директории. Однако kustomize поддерживает сценарии использования, когда есть базовая конфигурация и множество ее вариантов, также известных как overlays. Например, пользователь захотел взять Deployment и Service для nginx, которые я использовал в качестве примера, и создать development-, staging- и production-версии (или варианты) тех файлов. Для этого ему понадобятся упомянутые выше overlays и, собственно, сами базовые ресурсы.

Чтобы проиллюстрировать идею overlays и базовых ресурсов (base resources), предположим, что директории имеют следующую структуру:

- base
  - deployment.yaml
  - service.yaml
  - kustomization.yaml
- overlays
  - dev
    - kustomization.yaml
  - staging
    - kustomization.yaml
  - prod
    - kustomization.yaml

В файле base/kustomization.yaml пользователи с помощью поля resources просто объявляют ресурсы, которые должен включить kustomize.

В каждом из файлов overlays/{dev,staging,prod}/kustomization.yaml пользователи ссылаются на базовую конфигурацию в поле resources, а затем указывают конкретные изменения для данного окружения. Например, файл overlays/dev/kustomization.yaml может выглядеть как пример, приведенный ранее:

resources:
- ../../base
namePrefix: dev-
namespace: development
commonLabels:
  environment: development

При этом файл overlays/prod/kustomization.yaml может быть совсем другим:

resources:
- ../../base
namePrefix: prod-
namespace: production
commonLabels:
  environment: production
  sre-team: blue

Когда пользователь запустит kustomize build . в каталоге overlays/dev, kustomize сгенерирует вариант development. Если же запустить kustomize build . в каталоге overlays/prod — получится вариант production. И все это — без внесения каких-либо изменений в изначальные (base) файлы, и все это — декларативным и детерминированным способом. Можно коммитить базовую конфигурацию и оверлейные директории прямо в систему управления версиями, зная, что на основе этих файлов в любой момент можно воспроизвести нужную конфигурацию.


Прим. перев.: Иллюстрация из документации проекта по использованию overlays в kustomize

Kustomize умеет гораздо больше, чем рассказано в этой статье. Впрочем, надеюсь, она послужит хорошим введением.

Дополнительные ресурсы

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

• Change base YAML config for different environments prod/test using Kustomize;
• Kustomize — The right way to do templating in Kubernetes;
• Declarative Management of Kubernetes Objects Using Kustomize;
• Customizing Upstream Helm Charts with Kustomize.

Прим. перев.: Также можно посоветовать блок ссылок, опубликованных как Resources на сайте утилиты, и последующую за ними коллекцию видео с последними докладами про kustomize.

Если у вас есть вопросы или предложения по улучшению этого материала, я всегда открыт к обратной связи. Связаться со мной можно в Twitter или в Slack-канале Kubernetes. Получайте удовольствие, модифицируя свои манифесты с помощью kustomize!

P.S. от переводчика

Читайте также в нашем блоге:

• «Инструменты для разработчиков приложений, запускаемых в Kubernetes»;
• «Kubernetes 1.14: обзор основных новшеств»;
• «Пять главных итогов Helm Summit 2019 в Амстердаме»;
• «Практическое знакомство с пакетным менеджером для Kubernetes — Helm».