Stručné úvod do Kustomize

Pozn. přek.: Článek napsal Scott Lowe — inženýr s dlouholetou praxí v IT, autor a spol autor sedmi tištěných knih (převážně o VMware vSphere). Nyní pracuje v dceřiné společnosti VMware — Heptio (združené v roce 2016), specializující se na cloudové služby a Kubernetes. Samotný text slouží jako stručné a snadno pochopitelné úvodní slovo k řízení konfigurací pro Kubernetes pomocí technologie Kustomize, která nedávno přešla do K8s.

Kustomize je nástroj, který umožňuje uživatelům "přizpůsobit jednoduché a šablonám se vyhýbající YAML soubory pro různá použití, aniž by se původní YAML změnil a zůstal použitelný" (popis převzat přímo z repozitáře kustomize na GitHub). Kustomize lze spouštět přímo nebo, počínaje Kubernetes 1.14, použít kubectl -k k jeho funkcím (i když k verzi Kubernetes 1.15 je samostatný binární soubor novější, než funkce zabudované v kubectl). (Pozn. přek.: A s nedávným vydáním Kubernetes 1.16 kustomize podporováno je také dostupný v nástroji kubeadm.) V tomto příspěvku chci čtenáře seznámit se základy kustomize.

V nejjednodušší formě/použití je kustomize pouze soubor zdrojů (YAML soubory, které definují objekty Kubernetes: nasazení, služby atd.) plus seznam pokynů ke změnám, které by měly být provedeny na těchto zdrojích. Podobně jako make používá soubor pokynů, který je obsažen v Makefile, a Docker sestavuje kontejner na základě pokynů z Dockerfile, kustomize používá kustomization.yaml , aby uchovával předpisy o jaké změny chce uživatel provést na souboru zdrojů.

Zde je příklad souboru kustomization.yaml:

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

Nepokouším se popsat všechny možné pole v souboru kustomization.yaml (o tom je dobře napsáno zde), ale provedu stručné vysvětlení konkrétního příkladu:

• Pole resources určuje, které (jaké zdroje) kustomize změní. V tomto případě bude hledat zdroje v souborech deployment.yaml a service.yaml ve svém adresáři (pokud je to nutné, lze zadat celé nebo relativní cesty).
• Pole namePrefix předepisuje kustomize, aby přidával určitý prefix (v tomto případě — dev-) k atributu name všech zdrojích definovaných v poli resources. Takže pokud je v nasazení name s hodnotou nginx-deployment, kustomize z něj udělá dev-nginx-deployment.
• Pole namespace předepisuje kustomize přidávat zadaný namespace ke všem zdrojům. V tomto případě se Deployment a Service dostanou do namespace vývoj.
• Nakonec pole commonLabels obsahuje sadu tagů, které budou přidány ke všem zdrojům. V našem příkladu kustomize přiřadí zdrojům štítek s názvem environment a hodnotou vývoj.

Pokud uživatel provede kustomize build . ve složce s souborem kustomization.yaml a potřebnými zdroji (tj. soubory deployment.yaml a service.yaml), získá text se změnami uvedenými v kustomization.yaml.

Pozn. přek.: Ilustrace z dokumentace projektu k "jednoduchému" použití kustomize

Výstup lze přesměrovat, pokud chcete zaznamenat změny:

kustomize build . > custom-config.yaml

Výstupy jsou deterministické (při stejných vstupních datech dostanete stejné výstupy), takže není třeba výsledek ukládat do souboru. Místo toho ho můžete okamžitě předat jiné příkazu:

kustomize build . | kubectl apply -f -

Přístup k funkcím kustomize lze také získat prostřednictvím kubectl -k (od verze 1.14 Kubernetes). Mějte však na paměti, že samostatný balíček kustomize se rychleji aktualizuje než integrovaný v kubectl (alespoň to platí pro release Kubernetes 1.15).

Čtenáři se mohou ptát: „Proč všechny tyto komplikace, když lze soubory upravit přímo?“. Skvělá otázka. V našem příkladu je skutečně lze modifikovat soubory deployment.yaml a service.yaml přímo, ale co když jsou forkem něčího projektu? Přímá změna souborů ztěžuje (pokud to vůbec neznemožňuje) rebase forků, když se provádějí změny ve zdroji. Použití kustomize umožňuje centralizovat tyto změny v souboru kustomization.yaml, přičemž originální soubory zůstávají nedotčeny a tím usnadňují v případě potřeby rebase původních souborů.

Výhody kustomize se stávají zřejmými v složitějších případech použití. V uvedeném případě kustomization.yaml a zdroje se nacházejí ve stejné složce. Kustomize však podporuje scénáře, kdy existuje základní konfigurace a její mnohé varianty, známé také jako overlays. Například uživatel chce vzít Deployment a Service pro nginx, které jsem použil jako příklad, a vytvořit verze (nebo varianty) těchto souborů pro vývoj, staging a produkci. K tomu potřebuje výše zmíněné overlays a samozřejmě samotné základní zdroje.

Aby ilustrovat myšlenku overlayů a základních zdrojů (základní zdroje), předpokládejme, že adresáře mají následující strukturu:

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

V souboru base/kustomization.yaml uživatelé pomocí pole resources prostě deklarují zdroje, které má kustomize zahrnout.

V každém z těchto souborů overlays/{dev,staging,prod}/kustomization.yaml uživatelé odkazují na základní konfiguraci v poli resources, a poté uvádějí konkrétní změny pro toto prostředí. Například soubor overlays/dev/kustomization.yaml může vypadat jako příklad uvedený výše:

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

Přitom soubor overlays/prod/kustomization.yaml může být úplně jiný:

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

Když uživatel spustí kustomize build . ve složce overlays/dev, kustomize vygeneruje variantu development. Pokud spustíte kustomize build . ve složce overlays/prod , dostanete variantu production. A to vše — bez provádění jakýchkoli změn v původních (základních) souborech a to vše — deklarativním a deterministickým způsobem. Můžete committovat základní konfiguraci a overlayové adresáře přímo do systému správy verzí, s vědomím, že na základě těchto souborů lze kdykoli znovu vytvořit požadovanou konfiguraci.

Pozn. přek.: Ilustrace z dokumentace projektu k použití overlayů v kustomize

Kustomize umí mnohem více, než je popsáno v tomto článku. Doufám, že poslouží jako dobrý úvod.

Další zdroje

Existuje mnoho dobrých článků a publikací o kustomize. Zde je několik, které jsem považoval za obzvlášť užitečné:

• Změna základní YAML konfigurace pro různé prostředí prod/test pomocí Kustomize;
• Kustomize — Správný způsob, jak provádět šablonování v Kubernetes;
• Deklarativní správa objektů Kubernetes pomocí Kustomize;
• Přizpůsobení upstream Helm chartů pomocí Kustomize.

Pozn. přek.: Rovněž doporučuji blok odkazů zveřejněný jako Zdroje na webové stránce utilit a následnou kolekci videí s nejnovějšími prezentacemi o kustomize.

Pokud máte dotazy nebo návrhy na zlepšení tohoto materiálu, jsem vždy otevřený zpětné vazbě. Spojit se se mnou můžete v Twitter nebo na Slack kanálu Kubernetes. Užijte si upravování svých manifestů pomocí kustomize!

P.S. od překladatele

Přečtěte si také náš blog:

• «Nástroje pro vývojáře aplikací běžících v Kubernetes»;
• «Kubernetes 1.14: přehled hlavních novinek»;
• «Pět hlavních závěrů Helm Summitu 2019 v Amsterdamu»;
• «Praktické seznámení s balíčkovým manažerem pro Kubernetes — Helm».

Zdroj: habr.com