Краток вовед во Kustomize

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

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

Во својата наједноставна форма/апликација, 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. Така, ако распоредувањето има 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 (од Кубернетес верзија 1.14). Сепак, имајте на ум дека самостојниот пакет за прилагодување се ажурира побрзо од интегрираниот пакет kubectl (барем ова е случај со изданието Kubernetes 1.15).

Читателите може да прашаат: „Зошто сета оваа сложеност ако можете директно да ги уредувате датотеките? Одлично прашање. Во нашиот пример, навистина некој може да измени датотеки deployment.yaml и service.yaml директно, но што ако тие се вилушка на туѓ проект? Менувањето на датотеките директно го отежнува (ако не и невозможно) да се ребазира вилушката кога се прават промени на потеклото/изворот. Користењето на kustomize ви овозможува да ги централизирате овие промени во датотека kustomization.yaml, оставајќи ги оригиналните датотеки недопрени и на тој начин олеснување на ребазата на оригиналните датотеки доколку е потребно.

Придобивките од kustomize стануваат очигледни во посложени случаи на употреба. Во горниот пример kustomization.yaml а ресурсите се во истиот директориум. Сепак, kustomize поддржува случаи на употреба каде што има основна конфигурација и многу варијанти од неа, познати и како преклопувања. На пример, еден корисник сакаше да ги земе Deployment and Service за 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 - ја добивате опцијата за производство. И сето тоа - без да се направат никакви промени на оригиналот (основа) досиеја, сето тоа на декларативен и детерминистички начин. Можете да ја заверите основната конфигурација и директориумите за преклопување директно на контролата на верзијата, знаејќи дека врз основа на овие датотеки можете да ја репродуцирате саканата конфигурација во секое време.

Забелешка. превод.: Илустрација од проектната документација за користење на преклопувања во кустомизирање

Прилагодете може многу повеќе од она што е опфатено во оваа статија. Сепак, се надевам дека ќе послужи како добар вовед.

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

Има многу добри написи и публикации за кустомизирање. Еве неколку што ми беа особено корисни:

• Променете ја основната конфигурација на YAML за различни средини за производство/тестирање со помош на Kustomize;
• Kustomize - Вистинскиот начин за правење шаблони во Kubernetes;
• Декларативно управување со објекти на Kubernetes со користење на Customize;
• Приспособување на графиконите на кормилото нагоре со приспособување.

Забелешка. превод.: Можете исто така да препорачате блок од врски објавени како ресурси на веб-страницата на алатката, проследено со збирка видеа со најнови извештаи за кустомизирање.

Ако имате прашања или предлози за подобрување на овој материјал, јас сум секогаш отворен за повратни информации. Можете да ме контактирате на Twitter или Канал Kubernetes Slack. Забавувајте се со менување на вашите манифестати со kustomize!

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

Прочитајте и на нашиот блог:

• «Алатки за развивачи на апликации што работат на Kubernetes";
• «Kubernetes 1.14: преглед на главните иновации";
• «Пет главни резултати од самитот Хелм 2019 во Амстердам";
• «Рачно со менаџерот на пакети Кубернетес - Хелм".

Извор: www.habr.com