Stručné úvodné informácie o Kustomize

Pozn. prekl.: Článok napísal Scott Lowe — inžinier s bohatými skúsenosťami v IT, autor alebo spoluautor siedmich kníh (väčšinou o VMware vSphere). V súčasnosti pracuje v jej dcérskej spoločnosti VMware — Heptio (prevzatá v roku 2016), špecializujúcej sa na cloudové výpočty a Kubernetes. Text slúži ako úvod do správy konfigurácií pre Kubernetes pomocou technológie Kustomize, ktorá bola nedávno integrována do K8s.

Kustomize je nástroj, ktorý umožňuje používateľom "prispôsobovať jednoduché a bezšablónové YAML súbory pre rôzne ciele, pričom pôvodný YAML zostáva nedotknutý a použiteľný" (popis prevzatý priamo z repozitára kustomize na GitHub). Kustomize je možné spustiť priamo alebo, počnúc Kubernetes 1.14, použiť kubectl -k na prístup k jeho funkciám (aj keď vo verzii Kubernetes 1.15 je samostatná binárka novšia ako funkcie integrované v kubectl). (Pozn. prekl.: S nedávnym vydaním Kubernetes 1.16 kustomize podporované take v nástroji kubeadm.) V tejto publikácii chcem oboznámiť čitateľov so základmi kustomize.

V jednoduchšej forme používania je kustomize jednoducho sadou zdrojov (YAML súborov, ktoré definujú objekty Kubernetes: Deployments, Services atď.) spolu so zoznamom pokynov na zmeny, ktoré je potrebné vykonať na týchto zdrojoch. Podobne ako make používa súbor pokynov obsiahnutých v Makefile, a Docker vytvára kontajner na základe pokynov z Dockerfile, kustomize využíva kustomization.yaml na uchovávanie predpisov o tom, aké zmeny chce používateľ vykonať na sade zdrojov.

Tu je príklad súboru kustomization.yaml:

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

Nechcem sa pokúšať opísať všetky možné polia v súbore kustomization.yaml (o tom je dobre napísané tu), ale poskytnem krátke vysvetlenie konkrétneho príkladu:

• Pole resources uvedení, ktoré (aké zdroje) bude kustomize meniť. V tomto prípade bude hľadať zdroje v súboroch deployment.yaml a service.yaml vo svojom adresári (prípadne je možné uviesť úplné alebo relatívne cesty).
• Pole namePrefix ukazuje kustomize, aby pridávala určité prefixy (v tomto prípade — dev-) k atribútu name všetkých zdrojov definovaných v poli resources. Tým pádom, ak v Deployment je name s hodnotou nginx-deployment, kustomize z neho spraví dev-nginx-deployment.
• Pole namespace prikazuje kustomize-u, aby pridal zadaný názov priestoru ku všetkým zdrojom. V tomto prípade sa Deployment a Service umiestnia do názvu priestoru vývoj.
• Nakoniec, pole commonLabels obsahuje súbor štítkov, ktorý bude pridaný ku všetkým zdrojom. V našom príklade kustomize priradí zdrojom štítok s názvom environment a hodnotou vývoj.

Ak používateľ vykoná kustomize build . v adresári s súborom kustomization.yaml a potrebnými zdrojmi (t.j. súbormi deployment.yaml a service.yaml), dostane na výstupe text s zmenami, ktoré sú uvedené v kustomization.yaml.

Pozn. prekl.: Ilustrácia z dokumentácie projektu o „jednoduchom“ používaní kustomize

Výstup je možné presmerovať, ak je potrebné zafixovať zmeny:

kustomize build . > custom-config.yaml

Výstupy sú deterministické (pri rovnakých vstupných údajoch budú výsledky na výstupe rovnaké), preto nie je potrebné ukladať výsledok do súboru. Namiesto toho sa môže okamžite poslať do iného príkazu:

kustomize build . | kubectl apply -f -

Prístup k funkciám kustomize je možné získať aj cez kubectl -k (od verzie 1.14 Kubernetes). Avšak majte na pamäti, že samostatný balík kustomize sa aktualizuje rýchlejšie než integrovaný v kubectl (aspoň to je situácia s vydaním Kubernetes 1.15).

Čitatelia sa môžu pýtať: „Prečo sú všetky tieto komplikácie, ak môžem upravovať súbory priamo?“. Výborná otázka. V našom príklade je naozaj možné modifikovať súbory deployment.yaml a service.yaml priamo, ale čo ak sú forkmi niekoho projektu? Priame úpravy súborov sťažujú (ak nie úplne znemožňujú) rebase forku, keď sa vykonávajú zmeny v zdroji/zdrojovom kóde. Používanie kustomize umožňuje centralizovať tieto zmeny v súbore kustomization.yaml, pričom pôvodné súbory zostávajú nedotknuté a tak uľahčuje pri potreby rebase pôvodných súborov.

Výhody kustomize sa stávajú zrejmými vo zložitejších prípadoch použitia. V uvedenom príklade kustomization.yaml a zdroje sú v rovnakom adresári. Kustomize však podporuje scenáre použitia, keď existuje základná konfigurácia a množstvo jej variantov, tiež známych ako overlays. Napríklad používateľ sa rozhodol vziať Deployment a Service pre nginx, ktoré som použil ako príklad, a vytvoriť vývojové, stagingové a produkčné verzie (alebo varianty) týchto súborov. Na to potrebuje vyššie uvedené overlay a samotné základné zdroje.

Na ilustráciu konceptu overlays a základných zdrojov (základné zdroje), predpokladajme, že adresáre majú nasledujúcu štruktúru:

- base
  - deployment.yaml
  - service.yaml
  - kustomization.yaml
- overlays
  - dev
    - kustomization.yaml
  - staging
    - kustomization.yaml
  - prod
    - kustomization.yaml

V súbore base/kustomization.yaml používatelia pomocou poľa resources jednoducho vyhlasujú zdroje, ktoré by mal kustomize zahrnúť.

V každom z súborov overlays/{dev,staging,prod}/kustomization.yaml používatelia odkazujú na základnú konfiguráciu v poli resources, a potom uvádzajú konkrétne zmeny pre toto prostredie. Napríklad súbor overlays/dev/kustomization.yaml môže vyzerať ako príklad uvedený vyššie:

resources:
- ../../base
namePrefix: dev-
namespace: development
commonLabels:
  environment: development

Zároveň súbor overlays/prod/kustomization.yaml môže byť úplne iný:

resources:
- ../../base
namePrefix: prod-
namespace: production
commonLabels:
  environment: production
  sre-team: blue

Keď používateľ spustí kustomize build . v adresári overlays/dev, kustomize vygeneruje variant development. Ak sa však spustí kustomize build . v adresári overlays/prod , výsledkom bude variant production. A toto všetko — bez akýchkoľvek zmien v pôvodných (základných) súboroch, a to všetko — deklaratívne a deterministicky. Je možné commitať základnú konfiguráciu a overlay adresáre priamo do systému správy verzií, s vedomím, že na základe týchto súborov je možné kedykoľvek reprodukovať potrebnú konfiguráciu.

Pozn. prekl.: Ilustrácia z dokumentácie projektu o použití overlays v kustomize

Kustomize zvládne oveľa viac, ako je uvedené v tomto článku. Dúfam však, že poslúži ako dobrý úvod.

Ďalšie zdroje

Existuje množstvo dobrých článkov a publikácií o kustomize. Tu je niekoľko, ktoré som považoval za zvlášť užitočné:

• Zmena základnej YAML konfigurácie pre rôzne prostredia prod/test pomocou Kustomize;
• Kustomize — Správny spôsob, ako robiť templating v Kubernetes;
• Deklaratívne riadenie objektov Kubernetes pomocou Kustomize;
• Prispôsobovanie upstream Helm grafov pomocou Kustomize.

Pozn. prekl.: Takisto môžem odporučiť blok odkazov, publikovaných ako Zdroje na stránke nástroja a následnú kolekciu videí s poslednými prednáškami o kustomize.

Ak máte akékoľvek otázky alebo návrhy na zlepšenie tohto materiálu, som vždy otvorený spätnej väzbe. Spojiť sa so mnou môžete v Twitter alebo na Slack kanáli Kubernetes. Užite si prispôsobenie svojich manifestov pomocou kustomize!

P.S. od prekladateľa

Prečítajte si tiež na našom blogu:

• «Nástroje pre vývojárov aplikácií bežiacich v Kubernetes»;
• «Kubernetes 1.14: prehľad hlavných noviniek»;
• «Päť hlavných záverov Helm Summit 2019 v Amsterdame»;
• «Praktické oboznámenie sa so správcom balíkov pre Kubernetes – Helm».

Zdroj: habr.com