Una breve introduzione à Kustomize

Nota. transl.: L'articulu hè statu scrittu da Scott Lowe, un ingegnere cù una larga sperienza in IT, chì hè l'autore / coautore di sette libri stampati (principalmente nantu à VMware vSphere). Avà travaglia per a so filiale VMware Heptio (acquistata in 2016), spicializata in cloud computing è Kubernetes. U testu stessu serve cum'è una introduzione concisa è faciule da capisce à a gestione di cunfigurazione per Kubernetes cù a tecnulugia. Personalizà, chì recentemente hè diventatu parte di K8s.

Una breve introduzione à Kustomize

Kustomize hè un strumentu chì permette à l'utilizatori di "persunalizà schedarii YAML simplici, senza mudelli per scopi diversi, lascendu u YAML originale intactu è utilizable" (descrizzione presa direttamente da kustomize repository in GitHub). Kustomize pò esse eseguitu direttamente o, da Kubernetes 1.14, utilizatu kubectl -k per accede à e so funziunalità (ancu se da Kubernetes 1.15, u binariu separatu hè più novu di e capacità integrate in kubectl). (Nota. transl.: È cù a liberazione recente Kubernetes 1.16 persunalizà sustinutu da ancu in l'utilità kubeadm.) In questu post, vogliu presentà i lettori à i principii di kustomize.

In a so forma / applicazione più simplice, kustomize hè simplicemente una cullizzioni di risorse (fichi YAML chì definiscenu l'uggetti Kubernetes: Implementazioni, Servizi, etc.) più una lista di struzzioni per i cambiamenti chì devenu esse fatti à quelli risorse. Cum'è make usa l'istruzzioni cuntenuta in Makefile, è Docker custruisce u cuntinuu basatu annantu à l'istruzzioni da Dockerfile, persunalizà l'usi kustomization.yaml per almacenà struzzioni nantu à i cambiamenti chì l'utilizatore vole fà à un inseme di risorse.

Eccu un schedariu di esempiu kustomization.yaml:

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

Ùn pruvà micca di parlà di tutti i campi pussibuli in u schedariu. kustomization.yaml (questu hè ben scrittu circa ccà), ma daraghju una breve spiegazione di un esempiu specificu:

  • chjosu resources indica ciò chì (chì risorse) kustomize cambierà. In questu casu, cercherà risorse in i schedari deployment.yaml и service.yaml in u vostru repertoriu (pudete specificà percorsi cumpleti o relative se ne necessariu).
  • chjosu namePrefix indica à kustomize per aghjunghje un certu prefissu (in questu casu - dev-) à attribuisce name tutte e risorse definite in u campu resources. Cusì, se Deployment hà name cun significatu nginx-deployment, persunalizà a farà dev-nginx-deployment.
  • chjosu namespace indica à kustomize per aghjunghje u spaziu di nomi datu à tutte e risorse. In questu casu, Deployment and Service caderanu in u namespace development.
  • Infine, u campu commonLabels cuntene un inseme di etichette chì serà aghjuntu à tutte e risorse. In u nostru esempiu, kustomize assignerà una etichetta à e risorse cù u nome environment è significatu development.

Se l'utilizatore faci kustomize build . in u cartulare cù u schedariu kustomization.yaml è e risorse necessarie (vale à dì i schedari deployment.yaml и service.yaml), dopu à l'output riceverà un testu cù i cambiamenti specificati in kustomization.yaml.

Una breve introduzione à Kustomize
Nota. transl.: Illustrazione da a documentazione di u prugettu nantu à l'usu "semplice" di kustomize

L'output pò esse reindirizzatu se i cambiamenti devenu esse impegnati:

kustomize build . > custom-config.yaml

I dati di output sò deterministici (i stessi dati di input pruduceranu i stessi risultati di output), perchè ùn avete micca bisognu di salvà u risultatu in un schedariu. Invece, pò esse passatu direttamente à un altru cumandamentu:

kustomize build . | kubectl apply -f -

E funzioni di kustomize ponu ancu accede via kubectl -k (dapoi a versione 1.14 di Kubernetes). Tuttavia, tenite in mente chì u pacchettu kustomize standalone hè aghjurnatu più veloce di u pacchettu kubectl integratu (almenu questu hè u casu cù a versione Kubernetes 1.15).

I lettori ponu dumandà: "Perchè tutta sta cumplessità se pudete edità i schedari direttamente?" Grande dumanda. In u nostru esempiu, veramente mudificà i schedari deployment.yaml и service.yaml direttamente, ma chì s'ellu sò una furchetta di u prugettu di qualcunu altru ? U cambiamentu di i fugliali direttamente rende difficiuli (se ùn hè micca impussibile) di rebase una furchetta quandu i cambiamenti sò fatti à l'origine / fonte. Utilizà kustomize permette di centralizà sti cambiamenti in un schedariu kustomization.yaml, lascendu i fugliali originali intactu è cusì facenu più faciule per ribasà i schedari originali se ne necessariu.

I benefici di kustomize diventanu evidenti in casi di usu più cumplessi. In l'esempiu sopra kustomization.yaml è e risorse sò in u stessu annuariu. In ogni casu, kustomize supporta i casi d'usu induve ci hè una cunfigurazione di basa è parechje varianti di questu, cunnisciutu ancu com'è overlays. Per esempiu, un utilizatore vulia piglià Deployment and Service per nginx, chì aghju utilizatu com'è esempiu, è creà versioni di sviluppu, staging è produzzione (o varianti) di quelli schedari. Per fà questu, avarà bisognu di e superposizioni sopra citate è, in fattu, i risorsi basi stessi.

Per illustrà l'idea di sovrapposizioni è risorse sottostanti (risorse di basa), assumemu chì i cartulari anu a struttura seguente:

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

In u schedariu base/kustomization.yaml utilizatori chì utilizanu u campu resources simpricimenti dichjarà e risorse chì kustomize deve include.

In ognunu di i schedari overlays/{dev,staging,prod}/kustomization.yaml l'utilizatori riferite à a cunfigurazione di basa in u campu resources, è dopu indicà cambiamenti specifichi per ambiente datu. Per esempiu, u schedariu overlays/dev/kustomization.yaml pò esse cum'è l'esempiu datu prima:

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

In stu casu, u schedariu overlays/prod/kustomization.yaml pò esse cumplettamente differente:

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

Quandu l'utilizatore corre kustomize build . in u catalogu overlays/dev, kustomize genererà l'opzione di sviluppu. Si corre kustomize build . in u catalogu overlays/prod - avete l'opzione di produzzione. È tuttu questu - senza fà cambiamenti à l'uriginale (base) i schedari, tutti in una manera dichjarazione è deterministicu. Pudete cummette a cunfigurazione di basa è i cartulari di sovrapposizione direttamente à u cuntrollu di versione, sapendu chì basatu nantu à questi schedari pudete ripruduce a cunfigurazione desiderata in ogni mumentu.

Una breve introduzione à Kustomize
Nota. transl.: Illustrazione da a documentazione di u prugettu nantu à l'usu di sovrapposizioni in kustomize

Personalizà can assai più di ciò chì hè cupartu in stu articulu. Tuttavia, spergu chì serve cum'è una bona introduzione.

Risorse supplementari

Ci sò assai boni articuli è publicazioni nantu à kustomize. Eccu alcuni chì aghju trovu particularmente utile:

Nota. transl.: Pudete ancu ricumandemu un bloccu di ligami publicati cum'è Resources nantu à u situ web di l'utilità, seguita da una cullizzioni di video cù l'ultimi rapporti nantu à kustomize.

Sì avete dumande o suggerimenti per migliurà stu materiale, sò sempre apertu à i feedback. Pudete cuntattatemi à Twitter o Canale Kubernetes Slack. Divertitevi mudificà i vostri manifesti cù kustomize!

PS da u traduttore

Leghjite puru nant'à u nostru blog:

Source: www.habr.com

Add a comment