Кратко введение в 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 ще попаднат в пространството име разработка.
• Най-накрая, полето commonLabels съдържа набор от етикети, които ще бъдат добавени към всички ресурси. В нашия пример kustomize ще присвои на ресурсите етикет с името среда и стойността разработка.

Ако потребителят изпълни 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
  - 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 директно в системата за управление на версии, знаейки, че на база тези файлове по всяко време може да се възпроизведе нужната конфигурация.

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

Kustomize може много повече, отколкото е описано в тази статия. Надявам се, обаче, тя да послужи като добро въведение.

Допълнителни ресурси

Има много добри статии и публикации за kustomize. Ето няколко, които намерих за особено полезни:

• Промяна на основната YAML конфигурация за различни среди prod/test с Kustomize;
• Kustomize — Правилният начин да се прави темплейтинг в Kubernetes;
• Декларативно управление на Kubernetes обекти с Kustomize;
• Персонализиране на основни Helm графики с Kustomize.

Прим. прев.: Също така може да се препоръча блок с връзки, публикувани като Ресурси на сайта на инструмента, и последващата след тях колекция от видео с последните доклади за kustomize.

Ако имате въпроси или предложения за подобряване на този материал, винаги съм отворен за обратна връзка. Можете да се свържете с мен в Twitter или в Slack канала на Kubernetes. Наслаждавайте се, модифицирайки своите манифести с Kustomize!

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

Прочетете също в нашия блог:

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

Източник: habr.com