Kratko uvodno poglavlje u Kustomize

Napomena za prijevod.: Članak je napisao Scott Lowe — iskusni IT inženjer, autor ili koautor sedam publikacija (pretežno o VMware vSphere). Trenutno radi u njenoj podružnici VMware — Heptio (kupljena 2016. godine), specijalizirajući se za cloud computing i Kubernetes. Tekst služi kao sažet i lako razumljiv uvod u upravljanje konfiguracijama za Kubernetes koristeći tehnologiju Kustomize, koja je nedavno postala deo K8s.

Kustomize je alat koji omogućava korisnicima da 'prilagode jednostavne i neobavezne YAML datoteke za različite namene, ostavljajući izvorni YAML netaknutim i korišćenim' (opis preuzet iz repozitorijuma kustomize na GitHub). Kustomize se može pokretati direktno ili, počevši od Kubernetes 1.14, koristiti kubectl -k za pristup njegovim funkcijama (iako, prema stanju na Kubernetes 1.15, zasebna binarna datoteka je novija od mogućnosti integrisanih u kubectl). (Napomena za prijevod.: A sa nedavnim izdanjem Kubernetes 1.16 kustomize podržava takođe u alatu kubeadm.) U ovom članku želim upoznati čitatelje sa osnovama kustomize.

U svom najjednostavnijem obliku / upotrebi, kustomize je samo set resursa (YAML datoteka koje definišu Kubernetes objekte: Deployments, Services itd.) plus spisak uputstava o promenama koje treba izvršiti na ovim resursima. Slično tome kako make koristi skup uputstava sadržanih u Makefile, a Docker gradi kontejner na osnovu uputstava iz Dockerfile, kustomize koristi kustomization.yaml za čuvanje uputstava o tome koje promene korisnik želi napraviti na skupu resursa.

Evo primera datoteke kustomization.yaml:

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

Neću pokušavati da opisujem sve moguće oblasti u datoteci kustomization.yaml (o tome je lepo napisano ovdje), ali ću dati kratak opis konkretnog primera:

• Polje resources ukazuje koje resurse će menjati kustomize. U ovom slučaju, on će tražiti resurse u datotekama deployment.yaml i service.yaml u svom direktorijumu (ako je potrebno, mogu se navesti puni ili relativni putevi).
• Polje namePrefix nalaže kustomize-u da doda određeni prefiks (u ovom slučaju — dev-) atributu ime svih resursa definisanih u polju resources. Tako će, ako postoji u Deployment-u ime s vrijednošću nginx-deployment, kustomize napraviti dev-nginx-deployment.
• Polje namespace nalaže kustomize-u da doda određeni namespace svim resursima. U ovom slučaju, Deployment i Service će biti u namespace-u razvoj.
• Na kraju, polje commonLabels sadrži set oznaka koji će biti dodan svim resursima. U našem primjeru, kustomize će resursima dodati oznaku pod nazivom okruženje i vrijednosti. razvoj.

Ako korisnik izvrši kustomize build . u direktoriju s datotekom kustomization.yaml i potrebnim resursima (tj. datotekama deployment.yaml i service.yaml), tada će kao ishod dobiti tekst s promjenama navedenim u kustomization.yaml.

Napomena za prijevod.: Ilustracija iz dokumentacije projekta o "jednostavnom" korištenju kustomize

Izlaz se može preusmjeriti, ako je potrebno zabilježiti promjene:

kustomize build . > custom-config.yaml

Izlaz je deterministički (isti ulaz će dati iste rezultate na izlazu), stoga nije nužno spremati rezultat u datoteku. Umjesto toga, može se odmah proslijediti u drugu naredbu:

kustomize build . | kubectl apply -f -

Pristup funkcijama kustomize također se može dobiti putem kubectl -k (od verzije 1.14 Kubernetes-a). Imajte na umu da se zaseban paket kustomize brže ažurira nego integrirani u kubectl (barem je tako u slučaju izdanja Kubernetes 1.15).

Čitatelji bi mogli pitati: "Zašto su svi ovi pritisci potrebni, kada se datoteke mogu uređivati izravno?" Sjajno pitanje. U našem primjeru doista možete izmijeniti datoteke deployment.yaml i service.yaml izravno, ali što ako su one fork nekog projekta? Izravna izmjena datoteka otežava (ako ne i onemogućuje) rebase forka kada se unose promjene u izvor/izvornik. Korištenje kustomize omogućuje centralizaciju tih promjena u datoteci kustomization.yaml, ostavljajući izvorne datoteke netaknute i time olakšavajući rebase izvornih datoteka kad je to potrebno.

Prednosti kustomize postaju očite u složenijim slučajevima upotrebe. U gorenavedenom primjeru kustomization.yaml i resursi su u istoj direktoriji. Međutim, kustomize podržava scenarije upotrebe gdje postoji osnovna konfiguracija i mnoštvo njenih varijanti, poznatih i kao overlays. Na primjer, korisnik je želio uzeti Deployment i Service za nginx, koje sam koristio kao primjer, i stvoriti development, staging i production verzije (ili varijante) tih datoteka. Za to će mu biti potrebni gore spomenuti overlays i same osnovne resurse.

Kako bi ilustrirali ideju overlays i osnovnih resursa (osnovni resursi), pretpostavimo da direktoriji imaju sljedeću strukturu:

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

U datoteci osnovni/kustomization.yaml korisnici putem polja resources jednostavno izjavljuju resurse koje kustomize treba uključiti.

U svakom od datoteka overlays/{dev,staging,prod}/kustomization.yaml korisnici se referiraju na osnovnu konfiguraciju u polju resources, a zatim navode konkretne izmjene za tu okolinu. Na primjer, datoteka overlays/dev/kustomization.yaml može izgledati kao primjer dan ranije:

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

Pri tome datoteka overlays/prod/kustomization.yaml može biti potpuno drugačija:

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

Kada korisnik pokrene kustomize build . u direktoriju overlays/dev, kustomize će generirati varijantu development. Ako se pokrene kustomize build . u direktoriju overlays/prod — dobit ćemo varijantu production. I sve to — bez ikakvih promjena u izvornih (osnovnim) datotekama, a sve to — deklarativno i determinističko. Osnovnu konfiguraciju i overlay direktorije možete komitirati direktno u sustav upravljanja verzijama, znajući da se na temelju tih datoteka u bilo kojem trenutku može reproducirati potrebna konfiguracija.

Napomena za prijevod.: Ilustracija iz dokumentacije projekta o korištenju overlays u kustomize

Kustomize može mnogo više nego što je navedeno u ovom članku. Međutim, nadam se da će poslužiti kao dobro uvod.

Dodatni resursi

Postoji mnogo dobrih članaka i publikacija o kustomize. Evo nekoliko koje sam smatrao posebno korisnim:

• Promjena osnovne YAML konfiguracije za različite okoline prod/test koristeći Kustomize;
• Kustomize — pravi način za rad s šablonima u Kubernetesu;
• Deklarativno upravljanje Kubernetes objektima koristeći Kustomize;
• Prilagodba upstream Helm grafikonima s Kustomize.

Napomena za prijevod.: Također se može preporučiti blok s linkovima, objavljenih kao Resursi na web stranici alata, i naknadna zbirka videa s posljednjim predavanjima o kustomize.

Ako imate pitanja ili prijedloge za poboljšanje ovog materijala, uvijek sam otvoren za povratne informacije. Kontaktirati me možete u Twitter ili u Slack kanalu Kubernetes. Uživajte u modificiranju svojih manifestacija koristeći kustomize!

P.S. od prevodioca

Pročitajte i na našem blogu:

• «Alati za programere aplikacija pokrenutih u Kubernetesu»;
• «Kubernetes 1.14: pregled glavnih noviteta»;
• «Pet ključnih zaključaka Helm Summita 2019 u Amsterdamu»;
• «Praktično upoznavanje s upraviteljem paketa za Kubernetes – Helm».

Izvor: habr.com