En kort introduksjon til Kustomize

Merk. overs.: Artikkelen er skrevet av Scott Lowe, en ingeniør med lang erfaring innen IT, som er forfatter/medforfatter av syv trykte bøker (hovedsakelig på VMware vSphere). Han jobber nå for VMware-datterselskapet Heptio (kjøpt i 2016), og spesialiserer seg på cloud computing og Kubernetes. Selve teksten fungerer som en kortfattet og lettfattelig introduksjon til konfigurasjonsadministrasjon for Kubernetes ved bruk av teknologi Tilpass, som nylig ble en del av K8s.

Kustomize er et verktøy som lar brukere "tilpasse enkle, malfrie YAML-filer til forskjellige formål, og la den originale YAML være intakt og brukbar" (beskrivelse lånt direkte fra kustomize repository på GitHub). Kustomize kan kjøres direkte eller, fra og med Kubernetes 1.14, brukes kubectl -k for å få tilgang til funksjonaliteten (selv om fra og med Kubernetes 1.15 er den separate binære filen nyere enn funksjonene innebygd i kubectl). (Merk. overs.: Og med den nylige utgivelsen Kubernetes 1.16 tilpasse støttet av også i kubeadm-verktøyet.) I dette innlegget vil jeg introdusere leserne til det grunnleggende om kustomize.

I sin enkleste form/applikasjon er kustomize ganske enkelt en samling av ressurser (YAML-filer som definerer Kubernetes-objekter: Deployments, Services, etc.) pluss en liste med instruksjoner for endringer som må gjøres i disse ressursene. Akkurat som make bruker instruksjonssettet i Makefile, og Docker bygger containeren basert på instruksjoner fra Dockerfile, tilpasse bruksområder kustomization.yaml for å lagre instruksjoner om hvilke endringer brukeren ønsker å gjøre i et sett med ressurser.

Her er en eksempelfil kustomization.yaml:

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

Jeg vil ikke prøve å snakke om alle mulige felt i filen. kustomization.yaml (dette er godt skrevet om her), men jeg vil gi en kort forklaring på et spesifikt eksempel:

• Feltet resources angir hva (hvilke ressurser) kustomize vil endre. I dette tilfellet vil den se etter ressurser i filer deployment.yaml и service.yaml i katalogen din (du kan spesifisere hele eller relative stier om nødvendig).
• Feltet namePrefix instruerer kustomize å legge til et bestemt prefiks (i dette tilfellet - dev-) å tillegge name alle ressurser definert i feltet resources. Således, hvis Deployment har name med mening nginx-deployment, tilpasse vil gjøre det dev-nginx-deployment.
• Feltet namespace instruerer kustomize å legge til det gitte navneområdet til alle ressurser. I dette tilfellet vil Deployment and Service falle inn i navneområdet development.
• Endelig feltet commonLabels inneholder et sett med etiketter som vil bli lagt til alle ressurser. I vårt eksempel vil kustomize tildele en etikett til ressursene med navnet environment og mening development.

Hvis brukeren gjør det kustomize build . i katalogen med filen kustomization.yaml og de nødvendige ressursene (dvs. filer deployment.yaml и service.yaml), så vil den ved utgangen motta en tekst med endringene spesifisert i kustomization.yaml.

Merk. overs.: Illustrasjon fra prosjektdokumentasjonen om «enkel» bruk av kustomize

Utgangen kan omdirigeres hvis endringer må forpliktes:

kustomize build . > custom-config.yaml

Utdataene er deterministiske (de samme inndataene vil gi de samme utdataene), så du trenger ikke å lagre resultatet i en fil. I stedet kan den sendes direkte til en annen kommando:

kustomize build . | kubectl apply -f -

Kutomize-funksjonene kan også nås via kubectl -k (siden Kubernetes versjon 1.14). Husk imidlertid at den frittstående kustomize-pakken oppdateres raskere enn den integrerte kubectl-pakken (i det minste er dette tilfellet med Kubernetes 1.15-utgivelsen).

Lesere kan spørre: "Hvorfor all denne kompleksiteten hvis du kan redigere filene direkte?" Flott spørsmål. I vårt eksempel, faktisk man kan endre filer deployment.yaml и service.yaml direkte, men hva om de er en gaffel av andres prosjekt? Å endre filer direkte gjør det vanskelig (om ikke umulig) å rebase en gaffel når det gjøres endringer i opprinnelsen/kilden. Ved å bruke kustomize kan du sentralisere disse endringene i en fil kustomization.yaml, og lar originalfilene være intakte og gjør det lettere å rebase de originale filene om nødvendig.

Fordelene med kustomize blir tydelige i mer komplekse brukssaker. I eksemplet ovenfor kustomization.yaml og ressursene er i samme katalog. Kutomize støtter imidlertid brukstilfeller der det er en basiskonfigurasjon og mange varianter av den, også kjent som overlegg. For eksempel ønsket en bruker å ta Deployment and Service for nginx, som jeg brukte som eksempel, og lage utviklings-, iscenesettelses- og produksjonsversjoner (eller varianter) av disse filene. For å gjøre dette vil han trenge de ovennevnte overleggene og faktisk selve de grunnleggende ressursene.

For å illustrere ideen om overlegg og underliggende ressurser (grunnressurser), la oss anta at katalogene har følgende struktur:

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

I fil base/kustomization.yaml brukere som bruker feltet resources bare erklære ressursene som kustomize bør inkludere.

I hver av filene overlays/{dev,staging,prod}/kustomization.yaml brukere refererer til basiskonfigurasjonen i feltet resources, og angi deretter spesifikke endringer for gitt miljø. For eksempel fil overlays/dev/kustomization.yaml kan se ut som eksemplet gitt tidligere:

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

I dette tilfellet filen overlays/prod/kustomization.yaml kan være helt annerledes:

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

Når brukeren løper kustomize build . i katalogen overlays/dev, vil kustomize generere utbyggingsalternativet. Hvis du løper kustomize build . i katalogen overlays/prod - du får produksjonsalternativet. Og alt dette - uten å gjøre noen endringer i originalen (utgangspunkt) filer, alt på en deklarativ og deterministisk måte. Du kan forplikte basiskonfigurasjonen og overleggskatalogene direkte til versjonskontroll, vel vitende om at basert på disse filene kan du reprodusere ønsket konfigurasjon når som helst.

Merk. overs.: Illustrasjon fra prosjektdokumentasjonen om bruk av overlegg i kustomize

Tilpass boks mye mer enn det som er dekket i denne artikkelen. Jeg håper imidlertid det fungerer som en god introduksjon.

Tilleggsressurser

Det finnes mange gode artikler og publikasjoner om kustomize. Her er noen som jeg fant spesielt nyttige:

• Endre base YAML-konfigurasjon for forskjellige miljøer prod/test med Kustomize;
• Kustomize — Den riktige måten å gjøre maler på i Kubernetes;
• Deklarativ administrasjon av Kubernetes-objekter ved hjelp av Customize;
• Tilpasse Upstream Helm Charts med Customize.

Merk. overs.: Du kan også anbefale en blokk med lenker publisert som Ressurser på verktøyets nettside, etterfulgt av en samling videoer med de siste rapportene om kustomize.

Hvis du har spørsmål eller forslag for å forbedre dette materialet, er jeg alltid åpen for tilbakemeldinger. Du kan kontakte meg på Twitter eller Kubernetes Slack-kanal. Ha det gøy med å endre manifestene dine med kustomize!

PS fra oversetter

Les også på bloggen vår:

• «Verktøy for utviklere av applikasjoner som kjører på Kubernetes";
• «Kubernetes 1.14: oversikt over de viktigste nyvinningene";
• «Fem hovedresultater fra Helm Summit 2019 i Amsterdam";
• «Praktisk introduksjon til pakkeansvarlig for Kubernetes - Helm'.

Kilde: www.habr.com