Kort introduksjon til Kustomize

Obs. overs.: Artikkelen er skrevet av Scott Lowe – en ingeniør med lang erfaring innen IT, som er forfatter/medforfatter av syv trykte bøker (først og fremst om VMware vSphere). Han jobber nå i datterselskapet til VMware – Heptio (oppkjøpt i 2016), og spesialiserer seg på skybasert databehandling og Kubernetes. Selve teksten fungerer som en konsis og lettfattelig innføring i konfigurasjonsadministrasjon for Kubernetes ved hjelp av teknologi Kustomize, nylig integrert i K8s.

Kustomize – er et verktøy som lar brukere «tilpasse enkle og malfrie YAML-filer for ulike formål, mens original-YAML forblir intakt og brukbart» (beskrivelsen er direkte hentet fra kustomize-repositoriet på GitHub). Kustomize kan kjøres direkte eller, fra og med Kubernetes 1.14, bruke kubectl -k for å få tilgang til funksjonene sine (selv om en egen binærfil fra Kubernetes 1.15 er nyere enn funksjonene innebygd i kubectl). (Obs. overs.: Med den nyeste utgivelsen av Kubernetes 1.16 (forresten, utviklingen hans foregår nå i et eget repository), altså for behandling av tillegg YAML-filer fra spesielle kustomiseringsmapper (detaljer om deres bruk finnes i støttes også i kubeadm-verktøyet.) I denne publikasjonen ønsker jeg å introdusere leserne for grunnleggende om kustomize.

I sin enkleste form/bruk er kustomize bare et sett med ressurser (YAML-filer som definerer Kubernetes-objekter: Deployment, Services osv.) pluss en liste med instruksjoner for endringene som må gjøres i disse ressursene. På samme måte som make bruker et sett med instruksjoner som finnes i Makefile, og Docker bygger et container basert på instruksjoner fra Dockerfile, bruker kustomize kustomization.yaml for å lagre foreskriftene om hvilke endringer brukeren ønsker å gjøre i settet av ressurser.

Her er et eksempel på en fil kustomization.yaml:

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

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

• Felt resources angir hvilke (ressurser) kustomize vil endre. I dette tilfellet vil den søke etter ressurser i filene deployment.yaml og service.yaml i sin mappe (fullstendige eller relative baner kan angis om nødvendig).
• Felt namePrefix instrukserer kustomize om å legge til et spesifikt prefiks (i dette tilfellet – dev-) til attributtet name til alle ressursene definert i feltet resources. Dermed, hvis det i Deployment er name med verdien nginx-deployment, vil kustomize lage dev-nginx-deployment.
• Felt namespace og instruerer kustomize om å legge til det angitte navnerommet i alle ressursene. I dette tilfellet vil Deployment og Service havne i navnerommet utvikling.
• Endelig, feltet commonLabels inneholder et sett med etiketter som vil bli lagt til alle ressursene. I vårt eksempel vil kustomize tildele ressursene en etikett med navnet miljø og verdien utvikling.

Hvis brukeren kjører kustomize build . i katalogen med filen kustomization.yaml og nødvendige ressurser (dvs. filer deployment.yaml og service.yaml), vil utdataene bli tekst med endringene spesifisert i kustomization.yaml.

Obs. overs.: Illustrasjon fra prosjektets dokumentasjon om «enkelt» bruk av kustomize

Utdataene kan viderekobles hvis det er nødvendig å faste endringer:

kustomize build . > custom-config.yaml

Utdataene er deterministiske (med samme inngangsdata vil alltid gi de samme utdataene), så det er ikke nødvendig å lagre resultatet i en fil. I stedet kan det umiddelbart sendes til en annen kommando:

kustomize build . | kubectl apply -f -

Tilgang til kustomize-funksjoner kan også fås gjennom kubectl -k (fra versjon 1.14 av Kubernetes). Men vær oppmerksom på at den separate kustomize-pakken oppdateres raskere enn den som er integrert i kubectl (i det minste er det tilfelle med Kubernetes-utgivelsen 1.15).

Leserne kan spørre: «Hvorfor alle disse kompleksitetene, hvis man kan redigere filene direkte?». Flott spørsmål. I vårt eksempel kan man faktisk i endre filene deployment.yaml og service.yaml direkte, men hva hvis de er en fork av et prosjekt? Å endre filene direkte kompliserer (om ikke gjør det umulig) rebase av forken når det blir gjort endringer i kilden. Å bruke kustomize gjør at man kan sentralisere disse endringene i filen kustomization.yaml, noe som lar de originale filene være uspolerte og dermed gjør det lettere å rebase de opprinnelige filene om nødvendig.

Fordelene med kustomize blir åpenbare i mer komplekse bruksscenarier. I det ovennevnte eksemplet kustomization.yaml og ressursene er i samme katalog. Men kustomize støtter scenarier der det er en grunnleggende konfigurasjon og mange varianter av den, også kjent som kubectl create cronjob. For eksempel ønsket brukeren å ta Deployment og Service for nginx, som jeg har brukt som eksempel, og lage utviklings-, staging- og produksjonsversjoner (eller varianter) av disse filene. For dette vil han trenge de nevnte overlayene og de grunnleggende ressursene.

For å illustrere ideen om overlays og grunnleggende ressurser (base resources), 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 filen base/kustomization.yaml brukere med feltet resources enkelt erklærer ressursene som skal inkluderes i kustomize.

I hver av filene overlays/{dev,staging,prod}/kustomization.yaml brukere refererer til den grunnleggende konfigurasjonen i feltet resources, og angir deretter spesifikke endringer for det aktuelle miljøet. For eksempel kan filen overlays/dev/kustomization.yaml se ut som eksempelet nevnt tidligere:

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

Derfor kan filen overlays/prod/kustomization.yaml være helt annerledes:

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

Når brukeren kjører kustomize build . i katalogen overlays/dev, vil kustomize generere versjonen for utvikling. Hvis man derimot kjører kustomize build . i katalogen overlays/prod , vil man få produksjonsversjonen. Og alt dette skjer uten å gjøre noen endringer i de opprinnelige (base) filene, og alt blir gjort på en deklarativ og deterministisk måte. Man kan kommitte den grunnleggende konfigurasjonen og overleggkatalogene direkte til versjonskontrollsystemet, vel vitende om at man når som helst kan gjenskape den ønskede konfigurasjonen basert på disse filene.

Obs. overs.: Illustrasjon fra prosjektets dokumentasjon om bruk av overlays i kustomize

Kustomize kan mye mer enn det som er beskrevet i denne artikkelen. Jeg håper imidlertid at den vil fungere som en god introduksjon.

Ytterligere ressurser

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

• Endre base YAML-konfigurasjon for forskjellige miljøer prod/test ved hjelp av Kustomize;
• Kustomize - Den riktige måten å gjøre templating i Kubernetes;
• Deklarativ administrasjon av Kubernetes-objekter ved hjelp av Kustomize;
• Tilpassede upstream Helm-diagrammer med Kustomize.

Obs. overs.: Det kan også anbefales en lenkeblok, publisert som Ressurser på verktøyet sitt nettsted, etterfulgt av en samling videoer med de nyeste innleggene om kustomize.

Hvis du har spørsmål eller forslag til forbedringer av dette materialet, er jeg alltid åpen for tilbakemeldinger. Du kan kontakte meg i Twitter eller inn i Kubernetes Slack-kanal. Ha det moro med å modifisere manifestene dine med kustomize!

P.S. from the translator

Also read in our blog:

• «Verktøy for utviklere av applikasjoner som kjører i Kubernetes»;
• «Kubernetes 1.14: oversikt over hovednyhetene.»;
• «Fem hovedpunkter fra Helm Summit 2019 i Amsterdam»;
• «Praktisk introduksjon til pakkehåndtereren for Kubernetes — Helm».

Kilde: habr.com