Stručný úvod do Kustomize

Poznámka. přel.: Článek napsal Scott Lowe, inženýr s rozsáhlými zkušenostmi v IT, který je autorem/spoluautorem sedmi tištěných knih (především o VMware vSphere). Nyní pracuje pro její dceřinou společnost VMware Heptio (získaná v roce 2016), která se specializuje na cloud computing a Kubernetes. Samotný text slouží jako stručný a srozumitelný úvod do správy konfigurace pro Kubernetes pomocí technologie Přizpůsobit, která se nedávno stala součástí K8s.

Kustomize je nástroj, který uživatelům umožňuje „přizpůsobit jednoduché soubory YAML bez šablon pro různé účely a ponechat původní YAML nedotčený a použitelný“ (popis převzat přímo z kustomize repozitář na GitHubu). Kustomize lze spustit přímo nebo od Kubernetes 1.14 použít kubectl -k pro přístup k jeho funkcím (ačkoli od Kubernetes 1.15 je samostatný binární soubor novější než možnosti zabudované do kubectl). (Poznámka. přel.: A s nedávným vydáním Kubernetes 1.16 přizpůsobit podporováno také v obslužném programu kubeadm.) V tomto příspěvku chci čtenářům přiblížit základy kustomize.

Ve své nejjednodušší formě/aplikaci je kustomize jednoduše sbírka zdrojů (soubory YAML, které definují objekty Kubernetes: Deployments, Services, atd.) plus seznam pokynů pro změny, které je třeba provést v těchto zdrojích. Stejně jako make používá instrukční sadu obsaženou v Makefilea Docker sestaví kontejner na základě pokynů z Dockerfile, přizpůsobení použití kustomization.yaml k uložení pokynů o tom, jaké změny chce uživatel provést v sadě zdrojů.

Zde je ukázkový soubor kustomization.yaml:

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

Nebudu se snažit mluvit o všech možných polích v souboru. kustomization.yaml (o tom se dobře píše zde), ale uvedu stručné vysvětlení konkrétního příkladu:

• Pole resources označuje, co (které zdroje) kustomize změní. V tomto případě bude hledat zdroje v souborech deployment.yaml и service.yaml ve vašem adresáři (v případě potřeby můžete zadat úplné nebo relativní cesty).
• Pole namePrefix pokyn kustomize přidat určitou předponu (v tomto případě - dev-) přiřadit name všechny zdroje definované v poli resources. Pokud tedy Deployment má name s hodnotou nginx-deployment, přizpůsobení to udělá dev-nginx-deployment.
• Pole namespace pokyn kustomize přidat daný jmenný prostor ke všem zdrojům. V tomto případě bude Deployment and Service spadat do jmenného prostoru development.
• Konečně pole commonLabels obsahuje sadu štítků, které budou přidány ke všem zdrojům. V našem příkladu kustomize přiřadí ke zdrojům štítek s názvem environment a význam development.

Pokud to uživatel udělá kustomize build . v adresáři se souborem kustomization.yaml a potřebné zdroje (tj. soubory deployment.yaml и service.yaml), pak na výstupu obdrží text se změnami uvedenými v kustomization.yaml.

Poznámka. přel.: Ilustrace z projektové dokumentace o „jednoduchém“ použití kustomize

Výstup lze přesměrovat, pokud je třeba provést změny:

kustomize build . > custom-config.yaml

Výstupní data jsou deterministická (stejná vstupní data poskytnou stejné výstupní výsledky), takže výsledek nemusíte ukládat do souboru. Místo toho jej lze předat přímo jinému příkazu:

kustomize build . | kubectl apply -f -

K funkcím kustomize lze také přistupovat prostřednictvím kubectl -k (od verze Kubernetes 1.14). Mějte však na paměti, že samostatný balíček kustomize se aktualizuje rychleji než integrovaný balíček kubectl (alespoň tomu tak je u vydání Kubernetes 1.15).

Čtenáři se mohou ptát: „Proč taková složitost, když můžete soubory upravovat přímo?“ Skvělá otázka. V našem příkladu skutečně jeden může upravovat soubory deployment.yaml и service.yaml přímo, ale co když jsou forkem projektu někoho jiného? Přímá změna souborů znesnadňuje (ne-li nemožné) rebase fork, když jsou provedeny změny v původu/zdroji. Použití kustomize vám umožní centralizovat tyto změny v souboru kustomization.yaml, ponechání původních souborů nedotčené, a tak v případě potřeby usnadní opětovné založení původních souborů.

Výhody kustomize se projeví ve složitějších případech použití. Ve výše uvedeném příkladu kustomization.yaml a prostředky jsou ve stejném adresáři. Kustomize však podporuje případy použití, kdy existuje základní konfigurace a mnoho jejích variant, známých také jako překryvy. Například uživatel chtěl vzít Deployment and Service for nginx, který jsem použil jako příklad, a vytvořit vývojové, pracovní a produkční verze (nebo varianty) těchto souborů. K tomu bude potřebovat výše zmíněné překryvy a vlastně i samotné základní prostředky.

Pro ilustraci myšlenky překryvných vrstev 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é používající pole resources jednoduše deklarujte zdroje, které by kustomize měla obsahovat.

V každém ze souborů overlays/{dev,staging,prod}/kustomization.yaml uživatelé odkazují na základní konfiguraci v poli resourcesa poté uveďte konkrétní změny pro dané 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

V tomto případě soubor overlays/prod/kustomization.yaml může být úplně jinak:

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

Když uživatel spustí kustomize build . v katalogu overlays/dev, kustomize vygeneruje možnost vývoje. Pokud běžíš kustomize build . v katalogu overlays/prod - získáte možnost výroby. A to vše - aniž by bylo nutné provádět jakékoli změny v originálu (základna) soubory, to vše deklarativním a deterministickým způsobem. Základní konfiguraci a překryvné adresáře můžete odeslat přímo do správy verzí s vědomím, že na základě těchto souborů můžete požadovanou konfiguraci kdykoli reprodukovat.

Poznámka. přel.: Ilustrace z projektové dokumentace o použití překryvů v kustomize

Přizpůsobit plechovku moc více, než je popsáno v tomto článku. Doufám však, že poslouží jako dobrý úvod.

Dodatečné zdroje

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

• Změňte základní konfiguraci YAML pro různá prostředí prod/test pomocí Kustomize;
• Kustomize — Správný způsob vytváření šablon v Kubernetes;
• Deklarativní správa objektů Kubernetes pomocí přizpůsobení;
• Přizpůsobení grafů upstream kormidla pomocí Customize.

Poznámka. přel.: Můžete také doporučit blok odkazů publikovaný jako Zdroje na webu nástroje, následuje sbírka videí s nejnovějšími zprávami o kustomize.

Máte-li dotazy nebo návrhy na vylepšení tohoto materiálu, jsem vždy otevřen zpětné vazbě. Můžete mě kontaktovat na X nebo Kanál Kubernetes Slack. Bavte se upravováním svých manifestů pomocí kustomize!

PS od překladatele

Přečtěte si také na našem blogu:

• «Nástroje pro vývojáře aplikací běžících na Kubernetes";
• «Kubernetes 1.14: Nejdůležitější novinky";
• «Pět hlavních výsledků Helm Summit 2019 v Amsterdamu";
• «Praktický úvod do správce balíčků pro Kubernetes - Helm".

Zdroj: www.habr.com