א קורץ הקדמה צו קאַסטאַמייז

נאטיץ. טראַנסל.: Статью написал Scott Lowe — инженер с большим стажем в ИТ, являющийся автором/соавтором семи печатных книг (преимущественно по VMware vSphere). Сейчас он работает в её дочерней организации VMware — Heptio (поглощена в 2016 году), специализируясь на облачных вычислениях и Kubernetes. Сам же текст служит ёмким и простым для понимания введением в управление конфигурациями для Kubernetes с помощью технологии קאַסטאַמייז, недавно вошедшей в состав K8s.

Kustomize – это инструмент, позволяющий пользователям «настраивать простые и свободные от шаблонов файлы YAML под различные цели, оставляя оригинальный YAML нетронутым и пригодным для использования» (описание позаимствовано прямо из репозитория kustomize на GitHub). Kustomize можно запускать напрямую или, начиная с Kubernetes 1.14, использовать kubectl -k для доступа к его функциям (хотя по состоянию на Kubernetes 1.15 отдельный бинарник новее, чем возможности, встроенные в kubectl). (נאטיץ. טראַנסל.: А с недавним релизом קובערנעטעס 1.16 קאַסטאַמייז שטיצט דורך ещё и в утилите 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. И все это — без внесения каких-либо изменений в изначальные (באַזע) файлы, и все это — декларативным и детерминированным способом. Можно коммитить базовую конфигурацию и оверлейные директории прямо в систему управления версиями, зная, что на основе этих файлов в любой момент можно воспроизвести нужную конфигурацию.

נאטיץ. טראַנסל.: Иллюстрация из документации проекта по использованию 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.

נאטיץ. טראַנסל.: Также можно посоветовать блок ссылок, опубликованных как רעסאָורסעס на сайте утилиты, и последующую за ними коллекцию видео с последними докладами про kustomize.

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

פּס פון איבערזעצער

לייענען אויך אויף אונדזער בלאָג:

• «מכשירים פֿאַר דעוועלאָפּערס פון אַפּלאַקיישאַנז פליסנדיק אויף Kubernetes";
• «Kubernetes 1.14: איבערבליק פון די הויפּט ינאָווויישאַנז";
• «Пять главных итогов Helm Summit 2019 в Амстердаме";
• «פּראַקטישע הקדמה צו די פּעקל פאַרוואַלטער פֿאַר קובערנעטעס - העלם'.

מקור: www.habr.com