Kratek uvod v Kustomize

Opomba. prevod: Članek je napisal Scott Lowe, inženir z bogatimi izkušnjami na področju IT, ki je avtor/soavtor sedmih tiskanih knjig (predvsem o VMware vSphere). Zdaj dela za hčerinsko podjetje VMware Heptio (prevzeto leta 2016), specializirano za računalništvo v oblaku in Kubernetes. Samo besedilo služi kot jedrnat in lahko razumljiv uvod v upravljanje konfiguracije za Kubernetes z uporabo tehnologije Prilagoditi, ki je pred kratkim postala del K8s.

Kustomize je orodje, ki uporabnikom omogoča, da "prilagodite preproste datoteke YAML brez predlog za različne namene, tako da originalni YAML ostane nedotaknjen in uporaben" (opis je izposojen neposredno iz prilagodite repozitorij na GitHubu). Kustomize je mogoče zagnati neposredno ali pa ga od Kubernetes 1.14 dalje uporabiti kubectl -k za dostop do njegove funkcionalnosti (čeprav je od Kubernetesa 1.15 ločena binarna datoteka novejša od zmogljivosti, vgrajenih v kubectl). (Opomba. prevod: In z nedavno izdajo Kubernetes 1.16 prilagoditi podpira tudi v pripomočku kubeadm.) V tej objavi želim bralce seznaniti z osnovami kustomize.

V svoji najpreprostejši obliki/aplikaciji je kustomize preprosto zbirka virov (datoteke YAML, ki definirajo objekte Kubernetes: razmestitve, storitve itd.) in seznam navodil za spremembe, ki jih je treba izvesti v teh virih. Tako kot make uporablja nabor navodil, ki ga vsebuje Makefile, Docker pa zgradi vsebnik na podlagi navodil iz Dockerfile, prilagodite uporabe kustomization.yaml za shranjevanje navodil o tem, katere spremembe želi uporabnik narediti v naboru virov.

Tukaj je primer datoteke kustomization.yaml:

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

Ne bom poskušal govoriti o vseh možnih poljih v datoteki. kustomization.yaml (o tem je dobro napisano tukaj), vendar bom podal kratko razlago konkretnega primera:

• Polje resources označuje, kaj (kateri viri) bo prilagoditev spremenila. V tem primeru bo vire iskal v datotekah deployment.yaml и service.yaml v vašem imeniku (po potrebi lahko podate celotne ali relativne poti).
• Polje namePrefix ukaže kustomize, naj doda določeno predpono (v tem primeru - dev-) pripisati name vse vire, opredeljene na terenu resources. Torej, če ima Deployment name s pomenom nginx-deployment, prilagajanje bo uspelo dev-nginx-deployment.
• Polje namespace ukaže kustomize, naj doda dani imenski prostor vsem virom. V tem primeru bosta Razmestitev in Storitev spadala v imenski prostor development.
• Končno, polje commonLabels vsebuje niz oznak, ki bodo dodane vsem virom. V našem primeru bo kustomize virom dodelil oznako z imenom environment in vrednost development.

Če uporabnik to stori kustomize build . v imeniku z datoteko kustomization.yaml in potrebna sredstva (tj. datoteke deployment.yaml и service.yaml), potem bo na izhodu prejel besedilo s spremembami, navedenimi v kustomization.yaml.

Opomba. prevod: Ilustracija iz projektne dokumentacije o “preprosti” uporabi kustomize

Izhod je mogoče preusmeriti, če je treba izvesti spremembe:

kustomize build . > custom-config.yaml

Izhodni podatki so deterministični (isti vhodni podatki bodo ustvarili enake izhodne rezultate), zato vam ni treba shraniti rezultata v datoteko. Namesto tega se lahko posreduje neposredno drugemu ukazu:

kustomize build . | kubectl apply -f -

Do funkcij prilagajanja lahko dostopate tudi prek kubectl -k (od različice Kubernetes 1.14). Vendar ne pozabite, da se samostojni paket kustomize posodablja hitreje kot integrirani paket kubectl (vsaj tako je pri izdaji Kubernetes 1.15).

Bralci se lahko vprašajo: "Čemu vsa ta kompleksnost, če lahko neposredno urejate datoteke?" Odlično vprašanje. V našem primeru res eno lahko spreminjanje datotek deployment.yaml и service.yaml neposredno, kaj pa če so fork projekta nekoga drugega? Neposredno spreminjanje datotek oteži (če ne nemogoče) ponovno baziranje razcepa, ko se spremeni izvor/vir. Uporaba kustomize vam omogoča centralizacijo teh sprememb v datoteki kustomization.yaml, pri čemer ostanejo izvirne datoteke nedotaknjene in tako olajšajo ponovno baziranje izvirnih datotek, če je potrebno.

Prednosti kustomize postanejo očitne v bolj zapletenih primerih uporabe. V zgornjem primeru kustomization.yaml in viri so v istem imeniku. Vendar pa kustomize podpira primere uporabe, kjer obstaja osnovna konfiguracija in številne njene različice, znane tudi kot prekrivke. Na primer, uporabnik je želel vzeti Deployment and Service for nginx, ki sem ga uporabil kot primer, in ustvariti razvojne, uprizoritvene in proizvodne različice (ali različice) teh datotek. Za to bo potreboval zgoraj omenjene prekrivke in pravzaprav sama osnovna sredstva.

Za ponazoritev ideje o prekrivanju in osnovnih virih (osnovni viri), predpostavimo, da imajo imeniki naslednjo strukturo:

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

V datoteki base/kustomization.yaml uporabnikov, ki uporabljajo polje resources preprosto navedite vire, ki jih mora vključiti kustomize.

V vsaki od datotek overlays/{dev,staging,prod}/kustomization.yaml uporabniki se sklicujejo na osnovno konfiguracijo na terenu resourcesin nato navedite posebne spremembe za danem okolju. Na primer datoteka overlays/dev/kustomization.yaml lahko izgleda kot prejšnji primer:

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

V tem primeru datoteka overlays/prod/kustomization.yaml lahko čisto drugačen:

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

Ko uporabnik teče kustomize build . v katalogu overlays/dev, bo kustomize ustvaril razvojno možnost. Če tečeš kustomize build . v katalogu overlays/prod - dobite možnost izdelave. In vse to - brez spreminjanja izvirnika (osnova) datoteke, vse na deklarativen in determinističen način. Osnovno konfiguracijo in prekrivne imenike lahko prenesete neposredno v nadzor različic, saj veste, da lahko na podlagi teh datotek kadar koli reproducirate želeno konfiguracijo.

Opomba. prevod: Ilustracija iz projektne dokumentacije o uporabi prekrivanj v kustomize

Prilagodite lahko veliko več kot je zajeto v tem članku. Vendar upam, da služi kot dober uvod.

Dodatni viri

Obstaja veliko dobrih člankov in publikacij o kustomize. Tukaj je nekaj, ki so se mi zdele posebej koristne:

• Spremenite osnovno konfiguracijo YAML za različna okolja, izdelajte/testirajte z uporabo Kustomize;
• Prilagodi – Pravi način za izdelavo predlog v Kubernetesu;
• Deklarativno upravljanje predmetov Kubernetes z uporabo Customize;
• Prilagajanje grafikonov Upstream Helm s funkcijo Customize.

Opomba. prevod: Priporočite lahko tudi blok povezav, objavljen kot viri na spletnem mestu pripomočka, ki mu sledi zbirka videoposnetkov z najnovejšimi poročili o kustomize.

Če imate vprašanja ali predloge za izboljšanje tega gradiva, sem vedno odprt za povratne informacije. Kontaktirate me lahko na Twitter ali Kanal Kubernetes Slack. Zabavajte se s spreminjanjem svojih manifestov s programom kustomize!

PS od prevajalca

Preberite tudi na našem blogu:

• «Orodja za razvijalce aplikacij, ki se izvajajo na Kubernetesu»;
• «Kubernetes 1.14: pregled glavnih novosti»;
• «Pet glavnih rezultatov Helm Summit 2019 v Amsterdamu»;
• «Praktični uvod v upravitelja paketov za Kubernetes - Helm".

Vir: www.habr.com