Кратко въведение в персонализирането

Забележка. превод: Статията е написана от Скот Лоу, инженер с богат опит в ИТ, който е автор/съавтор на седем печатни книги (основно за VMware vSphere). Сега той работи за нейното дъщерно дружество на VMware Heptio (придобит през 2016 г.), специализирано в облачни изчисления и Kubernetes. Самият текст служи като кратко и лесно за разбиране въведение в управлението на конфигурацията за Kubernetes с помощта на технология Персонализиране, който наскоро стана част от K8s.

Kustomize е инструмент, който позволява на потребителите да „персонализират прости YAML файлове без шаблони за различни цели, оставяйки оригиналния YAML непокътнат и използваем“ (описанието е заимствано директно от персонализирайте хранилището на GitHub). Kustomize може да се стартира директно или, от Kubernetes 1.14, да се използва kubectl -k за достъп до неговата функционалност (въпреки че от Kubernetes 1.15 отделният двоичен файл е по-нов от възможностите, вградени в kubectl). (Забележка. превод: И с неотдавнашното издание Kubernetes 1.16 персонализирайте с подкрепата на също и в помощната програма kubeadm.) В тази публикация искам да запозная читателите с основите на kustomize.

В своята най-проста форма/приложение, kustomize е просто колекция от ресурси (YAML файлове, които дефинират обекти на Kubernetes: внедрявания, услуги и т.н.) плюс списък с инструкции за промени, които трябва да бъдат направени в тези ресурси. Точно както make използва набора от инструкции, съдържащ се в Makefile, а Docker изгражда контейнера въз основа на инструкции от Dockerfile, персонализирайте употребите kustomization.yaml за съхраняване на инструкции за това какви промени потребителят иска да направи в набор от ресурси.

Ето примерен файл kustomization.yaml:

resources:
- deployment.yaml
- service.yaml
namePrefix: dev-
namespace: development
commonLabels:
  environment: development

Няма да се опитвам да говоря за всички възможни полета във файла. kustomization.yaml (добре е написано за това тук), но ще дам кратко обяснение на конкретен пример:

• Област resources показва какво (кои ресурси) ще се промени. В този случай той ще търси ресурси във файлове deployment.yaml и service.yaml във вашата директория (можете да посочите пълни или относителни пътища, ако е необходимо).
• Област namePrefix инструктира kustomize да добави определен префикс (в този случай - dev-) за приписване name всички ресурси, определени в полето resources. По този начин, ако Deployment има name със стойност nginx-deployment, персонализирането ще го направи dev-nginx-deployment.
• Област namespace инструктира kustomize да добави даденото пространство от имена към всички ресурси. В този случай Deployment and 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 -

Функциите за персонализиране също могат да бъдат достъпни чрез kubectl -k (от Kubernetes версия 1.14). Имайте предвид обаче, че самостоятелният пакет kustomize се актуализира по-бързо от интегрирания пакет kubectl (поне такъв е случаят с изданието Kubernetes 1.15).

Читателите може да попитат: „Защо е цялата тази сложност, ако можете да редактирате файловете директно?“ Страхотен въпрос. В нашия пример, наистина може да модифициране на файлове deployment.yaml и service.yaml директно, но какво ще стане, ако те са разклонение на нечий друг проект? Директната промяна на файлове затруднява (ако не и невъзможно) пребазирането на разклонение, когато се правят промени в произхода/източника. Използването на kustomize ви позволява да централизирате тези промени във файл kustomization.yaml, оставяйки оригиналните файлове непокътнати и по този начин улеснявайки пребазирането на оригиналните файлове, ако е необходимо.

Ползите от kustomize стават очевидни в по-сложни случаи на употреба. В горния пример kustomization.yaml и ресурсите са в същата директория. Въпреки това, kustomize поддържа случаи на използване, при които има базова конфигурация и много нейни варианти, известни също като наслагвания. Например, потребител искаше да вземе Разгръщане и услуга за nginx, което използвах като пример, и да създаде версии за разработка, етапна и производствена версия (или варианти) на тези файлове. За да направи това, той ще се нуждае от гореспоменатите наслагвания и всъщност самите основни ресурси.

За да илюстрира идеята за наслагвания и основни ресурси (базови ресурси), нека приемем, че директориите имат следната структура:

- 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 ще генерира опцията за разработка. Ако тичаш kustomize build . в каталога overlays/prod - получавате опция за производство. И всичко това - без да правите промени в оригинала (база) файлове, всички по декларативен и детерминиран начин. Можете да ангажирате основната конфигурация и директориите с наслагване директно към контрола на версиите, като знаете, че въз основа на тези файлове можете да възпроизведете желаната конфигурация по всяко време.

Забележка. превод: Илюстрация от проектната документация за използване на наслагвания в kustomize

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

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

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

• Променете базовата конфигурация на YAML за различни среди продукт/тест с помощта на Kustomize;
• Kustomize – Правилният начин за създаване на шаблони в Kubernetes;
• Декларативно управление на обекти на Kubernetes с помощта на Customize;
• Персонализиране на Upstream Helm Charts с Customize.

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

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

PS от преводача

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

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

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