🥇Кратко представяне на Kustomize

Прим. прев.: Статията е написана от Скот Лоу — инженер с дългогодишен опит в ИТ, автор или съавтор на седем печатни книги (предимно за 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-) към атрибута име на всички ресурси, определени в полето resources. Така, ако в Deployment е включен име с стойността nginx-deployment, kustomize ще го направи dev-nginx-deployment.
Поле namespace предписва на kustomize да добавя зададеното пространство име към всички ресурси. В този случай, Deployment и Service ще попаднат в пространството име разработка.
На края, полето общи етикети съдържа набор от етикети, които ще бъдат добавени към всички ресурси. В нашия пример kustomize ще присвои на ресурсите етикет с наименованието environment и стойност разработка.

Ако потребителят изпълни 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 поддържа сценарии на употреба, в които има основна конфигурация и множество нейни варианти, известни също като overlay-те. Например, потребителят е искал да вземе Deployment и Service за nginx, които използвах като пример, и да създаде development-, staging- и production-версии (или варианти) на тези файлове. За това ще му бъдат нужни споменатите по-горе overlay-те и самите основни ресурси.

За да илюстрираме идеята за 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. Ето няколко, които сметнах за особено полезни:

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

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