Кароткае ўвядзенне ў 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). (Заўв. перав.: А з нядаўнім рэлізам Кубернетэс 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 патрапяць у прастору імёнаў 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 падтрымлівае сцэнары выкарыстання, калі есць базавая канфігурацыя і мноства яе варыянтаў, таксама вядомых як накладанняў. Напрыклад, карыстач захацеў узяць 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. Вось некалькі, якія я палічыў асабліва карыснымі:

• Змена base YAML config for different environments prod/test using Kustomize;
• Kustomize – права на сыход у Kubernetes;
• Declarative Management of Kubernetes Objects Using Kustomize;
• Customizing Upstream Helm Charts with Kustomize.

Заўв. перав.: Таксама можна параіць блок спасылак, апублікаваных як рэсурсы на сайце ўтыліты, і наступную за імі калекцыю відэа з апошнімі дакладамі пра kustomize.

Калі ў вас ёсць пытанні ці прапановы па паляпшэнні гэтага матэрыялу, я заўсёды адкрыты да зваротнай сувязі. Звязацца са мной можна ў Twitter або ў Slack-канале Kubernetes. Атрымлівайце задавальненне, мадыфікуючы свае маніфесты з дапамогай kustomize!

PS ад перакладчыка

Чытайце таксама ў нашым блогу:

• «Інструменты для распрацоўшчыкаў прыкладанняў, якія запускаюцца ў Kubernetes»;
• «Kubernetes 1.14: агляд асноўных навін»;
• «Пяць галоўных вынікаў Helm Summit 2019 у Амстэрдаме»;
• «Практычнае знаёмства з пакетным мэнэджэрам для Kubernetes - Helm.

Крыніца: habr.com