Kratak uvod u prilagođavanje

Bilješka. transl.: Članak je napisao Scott Lowe, inženjer sa velikim iskustvom u IT-u, koji je autor/koautor sedam štampanih knjiga (uglavnom o VMware vSphere). Sada radi za VMware podružnicu Heptio (kupljenu 2016.), specijaliziranu za računalstvo u oblaku i Kubernetes. Sam tekst služi kao sažet i lako razumljiv uvod u upravljanje konfiguracijom za Kubernetes koristeći tehnologiju Prilagodi, koji je nedavno postao dio K8s.

Kustomize je alat koji omogućava korisnicima da "prilagode jednostavne YAML datoteke bez predložaka za različite svrhe, ostavljajući originalni YAML netaknutim i upotrebljivim" (opis posuđen direktno iz prilagodite spremište na GitHub-u). Kustomize se može pokrenuti direktno ili, od Kubernetesa 1.14, koristiti kubectl -k da biste pristupili njegovoj funkcionalnosti (iako je od Kubernetesa 1.15 odvojeni binarni fajl noviji od mogućnosti ugrađenih u kubectl). (Bilješka. transl.: I sa nedavnim izdanjem Kubernetes 1.16 prilagoditi podržano od takođe u uslužnom programu kubeadm.) U ovom postu želim da upoznam čitaoce sa osnovama kustomize.

U svom najjednostavnijem obliku/aplikaciji, kustomize je jednostavno kolekcija resursa (YAML datoteke koje definiraju Kubernetes objekte: implementacije, usluge, itd.) plus lista instrukcija za promjene koje je potrebno izvršiti na tim resursima. Baš kao što make koristi skup instrukcija sadržan u Makefile, a Docker gradi kontejner na osnovu uputstava iz Dockerfile, prilagodite namjene kustomization.yaml za pohranjivanje instrukcija o tome koje promjene korisnik želi napraviti na skupu resursa.

Evo primjera datoteke kustomization.yaml:

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

Neću pokušavati da govorim o svim mogućim poljima u datoteci. kustomization.yaml (o ovome je dobro napisano ovdje), ali ću dati kratko objašnjenje konkretnog primjera:

• polje resources označava šta (koje resurse) kustomize će promijeniti. U ovom slučaju, tražit će resurse u datotekama deployment.yaml и service.yaml u vašem direktoriju (možete navesti pune ili relativne staze ako je potrebno).
• polje namePrefix nalaže kustomize da doda određeni prefiks (u ovom slučaju - dev-) pripisati name sve resurse definisane na terenu resources. Dakle, ako Deployment ima name sa značenjem nginx-deployment, prilagodite će uspjeti dev-nginx-deployment.
• polje namespace nalaže kustomize da doda dati prostor imena svim resursima. U ovom slučaju, Deployment and Service će pasti u imenski prostor development.
• Konačno, polje commonLabels sadrži skup oznaka koje će biti dodane svim resursima. U našem primjeru, kustomize će dodijeliti oznaku resursima s imenom environment i značenje development.

Ako korisnik to učini kustomize build . u direktoriju sa datotekom kustomization.yaml i potrebne resurse (tj. datoteke deployment.yaml и service.yaml), tada će na izlazu dobiti tekst sa promjenama navedenim u kustomization.yaml.

Bilješka. transl.: Ilustracija iz projektne dokumentacije o “jednostavnoj” upotrebi kustomize

Izlaz se može preusmjeriti ako promjene moraju biti urezane:

kustomize build . > custom-config.yaml

Izlazni podaci su deterministički (isti ulazni podaci će proizvesti iste izlazne rezultate), tako da ne morate spremati rezultat u datoteku. Umjesto toga, može se proslijediti direktno drugoj komandi:

kustomize build . | kubectl apply -f -

Funkcijama prilagođavanja se takođe može pristupiti putem kubectl -k (od verzije Kubernetesa 1.14). Međutim, imajte na umu da se samostalni kustomize paket ažurira brže od integriranog kubectl paketa (barem je to slučaj s izdanjem Kubernetes 1.15).

Čitaoci se mogu pitati: „Čemu sva ta složenost ako možete direktno uređivati ​​datoteke?“ Odlično pitanje. U našem primjeru, zaista moći modificirati fajlove deployment.yaml и service.yaml direktno, ali šta ako su viljuška nečijeg drugog projekta? Direktna promjena datoteka otežava (ako ne i nemoguće) ponovno baziranje viljuške kada se izvrše promjene u poreklu/izvoru. Korištenje kustomize vam omogućava da centralizirate ove promjene u datoteci kustomization.yaml, ostavljajući originalne datoteke netaknute i na taj način olakšavajući ponovno baziranje originalnih datoteka ako je potrebno.

Prednosti kustomize postaju očigledne u složenijim slučajevima upotrebe. U gornjem primjeru kustomization.yaml a resursi su u istom direktoriju. Međutim, kustomize podržava slučajeve upotrebe gde postoji osnovna konfiguracija i mnoge njene varijante, takođe poznate kao prekrivanja. Na primjer, korisnik je htio uzeti Deployment and Service za nginx, koje sam koristio kao primjer, i kreirati razvojne, scenske i proizvodne verzije (ili varijante) tih datoteka. Da bi to učinio, trebat će mu gore spomenuti slojevi i, zapravo, sami osnovni resursi.

Da ilustruje ideju preklapanja i osnovnih resursa (osnovni resursi), pretpostavimo da direktoriji imaju sljedeću strukturu:

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

U fajlu base/kustomization.yaml korisnika koji koriste teren resources jednostavno navedite resurse koje kustomize treba uključiti.

U svakom od fajlova overlays/{dev,staging,prod}/kustomization.yaml korisnici se pozivaju na osnovnu konfiguraciju na terenu resources, a zatim navedite određene promjene za dato okruženje. Na primjer, fajl overlays/dev/kustomization.yaml može izgledati kao primjer dat ranije:

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

U ovom slučaju fajl overlays/prod/kustomization.yaml može biti potpuno drugačije:

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

Kada korisnik pokrene kustomize build . u katalogu overlays/dev, kustomize će generirati opciju razvoja. Ako trčiš kustomize build . u katalogu overlays/prod - dobijate opciju proizvodnje. I sve to - bez ikakvih promjena u originalu (baza) datoteke, sve na deklarativni i deterministički način. Možete predati osnovnu konfiguraciju i direktorije preklapanja direktno u kontrolu verzija, znajući da na osnovu ovih datoteka možete reproducirati željenu konfiguraciju u bilo kojem trenutku.

Bilješka. transl.: Ilustracija iz projektne dokumentacije o korištenju prekrivača u kustomizeu

Prilagodite limenku puno više od onoga što je pokriveno u ovom članku. Ipak, nadam se da će poslužiti kao dobar uvod.

Dodatni resursi

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

• Promijenite osnovnu YAML konfiguraciju za različita okruženja prod/testirajte koristeći Kustomize;
• Prilagođavanje — pravi način izrade šablona u Kubernetesu;
• Deklarativno upravljanje Kubernetes objektima pomoću Customize;
• Prilagođavanje Upstream Helm Charts sa Customize.

Bilješka. transl.: Također možete preporučiti blok linkova objavljenih kao sredstva na web stranici uslužnog programa, nakon čega slijedi zbirka videozapisa s najnovijim izvještajima o kustomizeu.

Ako imate pitanja ili prijedloga za poboljšanje ovog materijala, uvijek sam otvoren za povratne informacije. Možete me kontaktirati na cvrkut ili Kubernetes Slack kanal. Zabavite se mijenjajući svoje manifeste uz kustomize!

PS od prevodioca

Pročitajte i na našem blogu:

• «Alati za programere aplikacija koje rade na Kubernetesu»;
• «Kubernetes 1.14: Najvažnije o tome šta je novo»;
• «Pet glavnih rezultata Helm Summit 2019 u Amsterdamu»;
• «Praktičan uvod u menadžer paketa za Kubernetes - Helm".

izvor: www.habr.com