🥇Kubernetes 1.16: revizuirea caracteristicilor cheie | ProHoster

Nota traducătorului.: Articolul a fost scris de Scott Lowe — un inginer cu multă experiență în IT, autor/co-autor al șapte cărți tipărite (în principal despre VMware vSphere). Acum lucrează la filiala VMware — Heptio (achiziționată în 2016), specializându-se în cloud computing și Kubernetes. Textul servește drept o introducere concisă și ușor de înțeles în managementul configurațiilor pentru Kubernetes folosind tehnologia Kustomize, recent integrată în K8s.

Kustomize este un instrument care permite utilizatorilor „să personalizeze fișiere YAML simple și fără șabloane pentru diferite scopuri, lăsând YAML-ul original intact și utilizabil” (descriere preluată direct din repository-ul kustomize de pe GitHub). Kustomize poate fi rulat direct sau, începând cu Kubernetes 1.14, utilizat cu kubectl -k pentru a accesa funcționalitățile sale (deși la Kubernetes 1.15 un binar separat este mai nou decât funcționalitățile încorporate în kubectl). (Nota traducătorului.: Cu lansarea recentă a Kubernetes 1.16 kustomize susținută și în utilitarul kubeadm.) În această publicație vreau să familiarizez cititorii cu noțiunile de bază ale kustomize.

În cea mai simplă formă/aplicare, kustomize este pur și simplu un set de resurse (fișiere YAML care definesc obiecte Kubernetes: Deployments, Services etc.) plus o listă de instrucțiuni de modificare care trebuie aplicate acestor resurse. Asemănător cu faptul că make folosește un set de instrucțiuni din Makefile, iar Docker construiește un container pe baza instrucțiunilor din Dockerfile, kustomize folosește kustomization.yaml pentru a stoca prescripțiile despre ce modificări dorește utilizatorul să facă în setul 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ă explic toate câmpurile posibile din fișier kustomization.yaml (despre acest lucru s-a scris destul de bine aici), dar voi oferi o scurtă explicație a unui exemplu specific:

• Câmp resources indică ce (resurse) va modifica kustomize. În acest caz, va căuta resurse în fișierele deployment.yaml și service.yaml din directorul său (dacă este necesar, se pot specifica căi absolute sau relative).
• Câmp namePrefix îi indică lui kustomize să adauge un prefix specific (în acest caz — dev-) la atributul name al tuturor resurselor definite în câmpul resources. Astfel, dacă în Deployment există name cu valoarea nginx-deployment, kustomize îl va transforma în dev-nginx-deployment.
• Câmp namespace impune lui kustomize să adauge spațiul de nume specificat tuturor resurselor. În acest caz, Deployment și Service vor cădea în spațiul de nume dezvoltare.
• În cele din urmă, câmpul commonLabels conține un set de etichete care va fi adăugat tuturor resurselor. În exemplul nostru, kustomize va atribui resurselor o etichetă cu numele environment și valoarea dezvoltare.

Dacă utilizatorul va executa kustomize build . în directorul cu fișierul kustomization.yaml și resursele necesare (adică fișierele deployment.yaml și service.yaml), va obține un text cu modificările specificate în kustomization.yaml.

Nota traducătorului.: Ilustrație din documentația proiectului pentru utilizarea „simplă” a kustomize

Iesirea poate fi redirecționată, dacă este necesar să se înregistreze modificările:

kustomize build . > custom-config.yaml

Ieșirea este determinată (cu aceleași date de intrare se vor obține aceleași rezultate la ieșire), prin urmare, nu este necesar să se salveze rezultatul într-un fișier. În schimb, acesta poate fi transmis direct unei alte comenzi:

kustomize build . | kubectl apply -f -

Accesul la funcțiile kustomize poate fi obținut și prin kubectl -k (începând cu versiunea 1.14 Kubernetes). Cu toate acestea, rețineți că pachetul kustomize separat se actualizează mai repede decât cel integrat în kubectl (cel puțin, așa stau lucrurile cu lansarea Kubernetes 1.15).

Cititorii s-ar putea întreba: „De ce sunt necesare toate aceste complicății, dacă se pot edita fișierele direct?”. O întrebare excelentă. În exemplul nostru chiar poate modificarea fișierelor deployment.yaml și service.yaml direct, dar ce se întâmplă dacă acestea sunt un fork al unui alt proiect? Schimbarea directă a fișierelor îngreunează (dacă nu face imposibil) rebase-ul fork-ului, atunci când se fac modificări în sursă/în original. Utilizarea kustomize permite centralizarea acestor modificări într-un fișier kustomization.yaml, lăsând fișierele originale intacte și, astfel, facilitând, dacă este necesar, rebase-ul fișierelor originale.

Avantajele kustomize devin evidente în cazuri de utilizare mai complexe. În exemplul de mai sus, kustomization.yaml și resursele se află în același director. Cu toate acestea, kustomize suportă scenarii de utilizare, când există o configurație de bază și multiplele sale variații, de asemenea cunoscute sub numele de overlays. De exemplu, utilizatorul a dorit să ia Deployment și Service pentru nginx, pe care l-am folosit ca exemplu, și să creeze versiuni (sau variante) de development, staging și production ale acestor fișiere. Pentru aceasta, utilizatorul va avea nevoie de overlays-urile menționate mai sus și, desigur, de resursele de bază.

Pentru a ilustra ideea de overlays și resurse de bază (resurse de bază), să presupunem că directorul are următoarea structură:

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

În fișierul base/kustomization.yaml utilizatorii prin intermediul câmpului resources declară simplu resursele pe care trebuie să le includă kustomize.

În fiecare dintre fișiere overlays/{dev,staging,prod}/kustomization.yaml utilizatorii se referă la configurația de bază în câmpul resources, apoi specifică modificările concrete pentru această mediu. De exemplu, fișierul overlays/dev/kustomization.yaml ar putea arăta ca exemplul menționat anterior:

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

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

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

Când utilizatorul va rula kustomize build . în catalogul overlays/dev, kustomize va genera o variantă de development. Dacă se lansează kustomize build . în catalogul overlays/prod — se va obține o variantă de production. Și toate acestea — fără a face vreo modificare în fișierele inițiale (de bază) și toate acestea — într-un mod declarat și determinat. Se poate comite configurația de bază și directoarele overlays direct în sistemul de control al versiunilor, știind că pe baza acestor fișiere, oricând, se poate reproduce configurația dorită.

Nota traducătorului.: Ilustrație din documentația proiectului privind utilizarea overlays în kustomize

Kustomize știe mult mai mult decât ceea ce este prezentat în acest articol. Totuși, sper că acesta va servi ca o introducere bună.

Resurse suplimentare

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

• Schimbarea configurației YAML de bază pentru medii diferite prod/test utilizând Kustomize;
• Kustomize — Calea corectă de a face templating în Kubernetes;
• Managementul Declarației Obiectelor Kubernetes folosind Kustomize;
• Personalizarea Graficele Helm din sursă cu Kustomize.

Nota traducătorului.: De asemenea, se poate recomanda blocul de linkuri publicate ca Resurse pe site-ul utilitarului și urmate de o colecție de videoclipuri cu ultimele prezentări despre kustomize.

Dacă aveți întrebări sau sugestii pentru îmbunătățirea acestui material, sunt întotdeauna deschis la feedback. Mă puteți contacta în Twitter sau pe canalul Slack Kubernetes. Bucurați-vă de modularea manifestelor dvs. cu ajutorul kustomize!

P.S. de la traducător

Citiți și în blogul nostru:

• «Instrumente pentru dezvoltatori de aplicații, care rulează în Kubernetes»;
• «Kubernetes 1.14: o privire asupra principalelor noutăți»;
• «Cele cinci rezultate principale ale Helm Summit 2019 din Amsterdam»;
• «Introducere practică în managerul de pachete pentru Kubernetes - Helm».

Sursa: habr.com