- PVSM.RU - https://www.pvsm.ru -
Прим. перев.: Статью написал Scott Lowe — инженер с большим стажем в ИТ, являющийся автором/соавтором семи печатных книг (преимущественно по VMware vSphere). Сейчас он работает в её дочерней организации VMware — Heptio (поглощена в 2016 году), специализируясь на облачных вычислениях и Kubernetes. Сам же текст служит ёмким и простым для понимания введением в управление конфигурациями для Kubernetes с помощью технологии Kustomize [1], недавно вошедшей в состав K8s.
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
Вывод можно перенаправить, если необходимо зафиксировать изменения:
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. Вот несколько, которые я посчитал особо полезными:
Прим. перев.: Также можно посоветовать блок ссылок, опубликованных как Resources [10] на сайте утилиты, и последующую за ними коллекцию видео с последними докладами про kustomize.
Если у вас есть вопросы или предложения по улучшению этого материала, я всегда открыт к обратной связи. Связаться со мной можно в Twitter [11] или в Slack-канале Kubernetes [12]. Получайте удовольствие, модифицируя свои манифесты с помощью kustomize!
Читайте также в нашем блоге:
Автор: 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
Нажмите здесь для печати.