O scurtă introducere în Kustomize

Notă. transl.: Articolul a fost scris de Scott Lowe, un inginer cu o vastă experiență în IT, care este autorul/coautorul a șapte cărți tipărite (în principal pe VMware vSphere). Acum lucrează pentru filiala sa VMware Heptio (achiziționată în 2016), specializată în cloud computing și Kubernetes. Textul în sine servește ca o introducere concisă și ușor de înțeles în gestionarea configurației pentru Kubernetes folosind tehnologia Personalizați, care a devenit recent parte a K8s.

Kustomize este un instrument care permite utilizatorilor să „personalizeze fișiere YAML simple, fără șablon, în diferite scopuri, lăsând YAML original intact și utilizabil” (descrierea împrumutată direct de la Kustomize depozitul de pe GitHub). Kustomize poate fi rulat direct sau, începând cu Kubernetes 1.14, utilizat kubectl -k pentru a-și accesa funcționalitatea (deși începând cu Kubernetes 1.15, binarul separat este mai nou decât capacitățile încorporate în kubectl). (Notă. transl.: Și cu lansarea recentă Kubernetes 1.16 personaliza susținută de de asemenea, în utilitarul kubeadm.) În această postare, vreau să prezint cititorilor elementele de bază ale kustomize.

În cea mai simplă formă/aplicație, kustomize este pur și simplu o colecție de resurse (fișiere YAML care definesc obiectele Kubernetes: implementări, servicii etc.) plus o listă de instrucțiuni pentru modificările care trebuie făcute acestor resurse. La fel cum make folosește setul de instrucțiuni conținut în Makefile, iar Docker construiește containerul pe baza instrucțiunilor de la Dockerfile, personalizați utilizările kustomization.yaml pentru a stoca instrucțiuni despre modificările pe care utilizatorul dorește să le facă unui set de resurse.

Iată un exemplu de fișier kustomization.yaml:

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

Nu voi încerca să vorbesc despre toate câmpurile posibile din fișier. kustomization.yaml (este bine scris despre asta aici), dar voi da o scurtă explicație a unui exemplu specific:

• Câmp resources indică ce (ce resurse) kustomize se va schimba. În acest caz, va căuta resurse în fișiere deployment.yaml и service.yaml în directorul dvs. (puteți specifica căi complete sau relative dacă este necesar).
• Câmp namePrefix instruiește kustomize să adauge un anumit prefix (în acest caz - dev-) a atribui name toate resursele definite în domeniu resources. Astfel, dacă Deployment are name cu sens nginx-deployment, personalizarea o va face dev-nginx-deployment.
• Câmp namespace instruiește kustomize să adauge spațiul de nume dat la toate resursele. În acest caz, Deployment and Service vor intra în spațiul de nume development.
• În sfârșit, câmpul commonLabels conține un set de etichete care vor fi adăugate tuturor resurselor. În exemplul nostru, kustomize va atribui o etichetă resurselor cu numele environment și sens development.

Dacă utilizatorul o face kustomize build . în directorul cu fișierul kustomization.yaml și resursele necesare (adică fișiere deployment.yaml и service.yaml), apoi la ieșire va primi un text cu modificările specificate în kustomization.yaml.

Notă. transl.: Ilustrație din documentația proiectului despre utilizarea „simple” a kustomize

Ieșirea poate fi redirecționată dacă trebuie efectuate modificări:

kustomize build . > custom-config.yaml

Datele de ieșire sunt deterministe (aceleași date de intrare vor produce aceleași rezultate de ieșire), așa că nu trebuie să salvați rezultatul într-un fișier. În schimb, poate fi transmis direct unei alte comenzi:

kustomize build . | kubectl apply -f -

Caracteristicile kustomize pot fi accesate și prin intermediul kubectl -k (de la versiunea Kubernetes 1.14). Cu toate acestea, rețineți că pachetul autonom kustomize este actualizat mai rapid decât pachetul integrat kubectl (cel puțin acesta este cazul versiunii Kubernetes 1.15).

Cititorii se pot întreba: „De ce toată această complexitate dacă puteți edita fișierele direct?” Mare întrebare. În exemplul nostru, într-adevăr Se poate modifica fișierele deployment.yaml и service.yaml direct, dar dacă sunt o furcă a proiectului altcuiva? Schimbarea directă a fișierelor face dificilă (dacă nu imposibilă) rebazarea unui furk atunci când se fac modificări la origine/sursă. Utilizarea kustomize vă permite să centralizați aceste modificări într-un fișier kustomization.yaml, lăsând fișierele originale intacte și, astfel, ușurând rebazarea fișierelor originale dacă este necesar.

Beneficiile kustomize devin evidente în cazuri de utilizare mai complexe. În exemplul de mai sus kustomization.yaml iar resursele sunt în același director. Cu toate acestea, kustomize acceptă cazuri de utilizare în care există o configurație de bază și multe variante ale acesteia, cunoscute și ca suprapunerile. De exemplu, un utilizator a vrut să ia Deployment and Service pentru nginx, pe care l-am folosit ca exemplu, și să creeze versiuni de dezvoltare, staging și producție (sau variante) ale acelor fișiere. Pentru a face acest lucru, va avea nevoie de suprapunerile menționate mai sus și, de fapt, de resursele de bază în sine.

Pentru a ilustra ideea de suprapuneri și resurse de bază (resurse de bază), să presupunem că directoarele au următoarea structură:

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

În dosar base/kustomization.yaml utilizatorii care folosesc câmpul resources pur și simplu declarați resursele pe care kustomize ar trebui să le includă.

În fiecare dintre dosare overlays/{dev,staging,prod}/kustomization.yaml utilizatorii se referă la configurația de bază din câmp resources, iar apoi indicați modificări specifice pentru mediu dat. De exemplu, fișier overlays/dev/kustomization.yaml ar putea arăta ca exemplul dat mai devreme:

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

În acest caz dosarul overlays/prod/kustomization.yaml ar putea fi complet diferit:

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

Când utilizatorul rulează kustomize build . în catalog overlays/dev, kustomize va genera opțiunea de dezvoltare. Dacă fugi kustomize build . în catalog overlays/prod - primești opțiunea de producție. Și toate acestea - fără a face nicio modificare la original (baza) dosare, toate într-un mod declarativ și determinist. Puteți trimite configurația de bază și directoarele de suprapunere direct la controlul versiunilor, știind că pe baza acestor fișiere puteți reproduce configurația dorită în orice moment.

Notă. transl.: Ilustrație din documentația proiectului despre utilizarea suprapunerilor în kustomize

Personalizați cutia mai mult mai mult decât ceea ce este tratat în acest articol. Cu toate acestea, sper să servească drept o introducere bună.

Resurse aditionale

Există multe articole și publicații bune despre kustomize. Iată câteva pe care le-am găsit deosebit de utile:

• Schimbați configurația de bază YAML pentru diferite medii de prod/test folosind Kustomize;
• Kustomize — Modul corect de a face șabloane în Kubernetes;
• Managementul declarativ al obiectelor Kubernetes folosind Customize;
• Personalizarea graficelor din amonte cu Customize.

Notă. transl.: De asemenea, puteți recomanda un bloc de link-uri publicate ca Resurse pe site-ul utilității, urmat de o colecție de videoclipuri cu cele mai recente rapoarte despre kustomize.

Dacă aveți întrebări sau sugestii pentru îmbunătățirea acestui material, sunt întotdeauna deschis la feedback. Ma puteti contacta la Twitter sau Canalul Kubernetes Slack. Distrați-vă modificându-vă manifestele cu kustomize!

PS de la traducator

Citește și pe blogul nostru:

• «Instrumente pentru dezvoltatorii de aplicații care rulează pe Kubernetes»;
• «Kubernetes 1.14: prezentare generală a principalelor inovații»;
• «Cinci rezultate principale ale Helm Summit 2019 de la Amsterdam»;
• «Practic cu Managerul de pachete Kubernetes - Helm".

Sursa: www.habr.com