- PVSM.RU - https://www.pvsm.ru -

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

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

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

Kustomize – это инструмент, позволяющий пользователям «настраивать простые и свободные от шаблонов файлы YAML под различные цели, оставляя оригинальный YAML нетронутым и пригодным для использования» (описание позаимствовано прямо из репозитория kustomize на GitHub [2]). Kustomize можно запускать напрямую или, начиная с Kubernetes 1.14, использовать kubectl -k для доступа к его функциям (хотя по состоянию на Kubernetes 1.15 отдельный бинарник новее, чем возможности, встроенные в kubectl). (Прим. перев.: А с недавним релизом Kubernetes 1.16 [3] kustomize поддерживается [4] ещё и в утилите 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 (об этом неплохо написано здесь [5]), но проведу краткое объяснение конкретного примера:

  • Поле 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 - 2
Прим. перев.: Иллюстрация из документации проекта по «простому» использованию 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) файлы, и все это — декларативным и детерминированным способом. Можно коммитить базовую конфигурацию и оверлейные директории прямо в систему управления версиями, зная, что на основе этих файлов в любой момент можно воспроизвести нужную конфигурацию.

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

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

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

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

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

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

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

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

Автор: anchiru

Источник [17]


Сайт-источник PVSM.RU: https://www.pvsm.ru

Путь до страницы источника: https://www.pvsm.ru/sistemnoe-administrirovanie/331953

Ссылки в тексте:

[1] Kustomize: https://kustomize.io/

[2] репозитория kustomize на GitHub: https://github.com/kubernetes-sigs/kustomize

[3] Kubernetes 1.16: https://habr.com/ru/company/flant/blog/467477/

[4] поддерживается: https://github.com/kubernetes/enhancements/issues/1177

[5] здесь: https://github.com/kubernetes-sigs/kustomize/blob/master/docs/fields.md

[6] Change base YAML config for different environments prod/test using Kustomize: https://levelup.gitconnected.com/kubernetes-change-base-yaml-config-for-different-environments-prod-test-6224bfb6cdd6

[7] Kustomize — The right way to do templating in Kubernetes: https://blog.stack-labs.com/code/kustomize-101/

[8] Declarative Management of Kubernetes Objects Using Kustomize: https://kubernetes.io/docs/tasks/manage-kubernetes-objects/kustomization/

[9] Customizing Upstream Helm Charts with Kustomize: https://testingclouds.wordpress.com/2018/07/20/844/

[10] Resources: https://kustomize.io/#resources

[11] Twitter: https://twitter.com/scott_lowe

[12] Slack-канале Kubernetes: https://kubernetes.slack.com/

[13] Инструменты для разработчиков приложений, запускаемых в Kubernetes: https://habr.com/ru/company/flant/blog/462707/

[14] Kubernetes 1.14: обзор основных новшеств: https://habr.com/ru/company/flant/blog/445196/

[15] Пять главных итогов Helm Summit 2019 в Амстердаме: https://habr.com/ru/company/flant/blog/468259/

[16] Практическое знакомство с пакетным менеджером для Kubernetes — Helm: https://habr.com/ru/company/flant/blog/420437/

[17] Источник: https://habr.com/ru/post/469179/?utm_campaign=469179&utm_source=habrahabr&utm_medium=rss