En kort introduktion til Kustomize

Bemærk. overs.: Artiklen er skrevet af Scott Lowe, en ingeniør med stor erfaring inden for IT, som er forfatter/medforfatter til syv trykte bøger (hovedsageligt på VMware vSphere). Han arbejder nu for dets VMware-datterselskab Heptio (erhvervet i 2016), med speciale i cloud computing og Kubernetes. Selve teksten fungerer som en kortfattet og letforståelig introduktion til konfigurationsstyring for Kubernetes ved hjælp af teknologi Tilpas, som for nylig blev en del af K8s.

Kustomize er et værktøj, der giver brugerne mulighed for at "tilpasse enkle, skabelonfrie YAML-filer til forskellige formål, og efterlade den originale YAML intakt og brugbar" (beskrivelse lånt direkte fra kystomize repository på GitHub). Kustomize kan køres direkte eller, fra Kubernetes 1.14, bruges kubectl -k for at få adgang til dens funktionalitet (selvom fra Kubernetes 1.15 er den separate binære nyere end de indbyggede muligheder i kubectl). (Bemærk. overs.: Og med den seneste udgivelse Kubernetes 1.16 tilpasse støttet af også i kubeadm-værktøjet.) I dette indlæg vil jeg introducere læserne til det grundlæggende i kustomize.

I sin enkleste form/applikation er kustomize simpelthen en samling af ressourcer (YAML-filer, der definerer Kubernetes-objekter: Implementeringer, tjenester osv.) plus en liste over instruktioner til ændringer, der skal foretages i disse ressourcer. Ligesom make bruger instruktionssættet indeholdt i Makefile, og Docker bygger containeren baseret på instruktioner fra Dockerfile, tilpasse anvendelser kustomization.yaml at gemme instruktioner om, hvilke ændringer brugeren ønsker at foretage på et sæt ressourcer.

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

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

Jeg vil ikke forsøge at tale om alle de mulige felter i filen. kustomization.yaml (det er godt skrevet om her), men jeg vil give en kort forklaring på et specifikt eksempel:

• Field resources angiver, hvad (hvilke ressourcer) kustomize vil ændre. I dette tilfælde vil den lede efter ressourcer i filer deployment.yaml и service.yaml i din mappe (du kan angive fulde eller relative stier om nødvendigt).
• Field namePrefix instruerer kustomize om at tilføje et bestemt præfiks (i dette tilfælde - dev-) at tilskrive name alle ressourcer defineret i feltet resources. Således, hvis Deployment har name med betydningen nginx-deployment, tilpasse vil gøre det dev-nginx-deployment.
• Field namespace instruerer kustomize om at tilføje det givne navneområde til alle ressourcer. I dette tilfælde vil Deployment og Service falde ind i navneområdet development.
• Endelig feltet commonLabels indeholder et sæt etiketter, der vil blive tilføjet til alle ressourcer. I vores eksempel vil kustomize tildele en etiket til ressourcerne med navnet environment og mening development.

Hvis brugeren gør det kustomize build . i mappen med filen kustomization.yaml og de nødvendige ressourcer (dvs. filer deployment.yaml и service.yaml), så vil den ved udgangen modtage en tekst med de ændringer, der er angivet i kustomization.yaml.

Bemærk. overs.: Illustration fra projektdokumentationen om "simpel" brug af kustomize

Outputtet kan omdirigeres, hvis der skal foretages ændringer:

kustomize build . > custom-config.yaml

Outputdataene er deterministiske (de samme inputdata vil producere de samme outputresultater), så du behøver ikke at gemme resultatet i en fil. I stedet kan den sendes direkte til en anden kommando:

kustomize build . | kubectl apply -f -

Kutomize-funktionerne kan også tilgås via kubectl -k (siden Kubernetes version 1.14). Husk dog, at den selvstændige kustomize-pakke opdateres hurtigere end den integrerede kubectl-pakke (det er i hvert fald tilfældet med Kubernetes 1.15-udgivelsen).

Læsere kan spørge: "Hvorfor al denne kompleksitet, hvis du kan redigere filerne direkte?" Godt spørgsmål. I vores eksempel, faktisk man kan ændre filer deployment.yaml и service.yaml direkte, men hvad nu hvis de er en forgrening af en andens projekt? Ændring af filer direkte gør det svært (hvis ikke umuligt) at rebase en gaffel, når der foretages ændringer i oprindelsen/kilden. Ved at bruge kustomize kan du centralisere disse ændringer i en fil kustomization.yaml, efterlader de originale filer intakte og gør det lettere at rebase de originale filer, hvis det er nødvendigt.

Fordelene ved kustomize bliver tydelige i mere komplekse brugssager. I ovenstående eksempel kustomization.yaml og ressourcerne er i samme mappe. Kustomize understøtter dog anvendelsestilfælde, hvor der er en basiskonfiguration og mange varianter af den, også kendt som overlejringer. For eksempel ønskede en bruger at tage Deployment and Service til nginx, som jeg brugte som eksempel, og oprette udviklings-, iscenesættelses- og produktionsversioner (eller varianter) af disse filer. For at gøre dette har han brug for de ovennævnte overlejringer og faktisk selve de grundlæggende ressourcer.

For at illustrere ideen om overlejringer og underliggende ressourcer (basisressourcer), lad os antage, at mapperne 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 brugere, der bruger feltet resources blot erklære de ressourcer, som kustomize skal omfatte.

I hver af filerne overlays/{dev,staging,prod}/kustomization.yaml brugere henviser til basiskonfigurationen i feltet resources, og angiv derefter specifikke ændringer for givet miljø. For eksempel fil overlays/dev/kustomization.yaml kan se ud som eksemplet givet tidligere:

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

I dette tilfælde filen overlays/prod/kustomization.yaml kunne være helt anderledes:

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

Når brugeren løber kustomize build . i kataloget overlays/dev, vil kustomize generere udviklingsmuligheden. Hvis du løber kustomize build . i kataloget overlays/prod - du får produktionsmuligheden. Og alt dette - uden at foretage ændringer i originalen (grundlag) filer, alt sammen på en deklarativ og deterministisk måde. Du kan forpligte basiskonfigurationen og overlejringsbibliotekerne direkte til versionskontrol, vel vidende, at du baseret på disse filer kan gengive den ønskede konfiguration til enhver tid.

Bemærk. overs.: Illustration fra projektdokumentationen om brug af overlejringer i kustomize

Tilpas dåse mere mere end hvad der er beskrevet i denne artikel. Jeg håber dog, det fungerer som en god introduktion.

Yderligere ressourcer

Der er mange gode artikler og publikationer om kustomize. Her er et par stykker, som jeg fandt særligt nyttige:

• Skift base YAML-konfiguration for forskellige miljøer prod/test ved hjælp af Kustomize;
• Kustomize — Den rigtige måde at lave skabeloner på i Kubernetes;
• Deklarativ styring af Kubernetes-objekter ved hjælp af Customize;
• Tilpasning af Upstream Helm Charts med Customize.

Bemærk. overs.: Du kan også anbefale en blok af links udgivet som Ressourcer på værktøjets hjemmeside, efterfulgt af en samling af videoer med de seneste rapporter om kustomize.

Hvis du har spørgsmål eller forslag til forbedring af dette materiale, er jeg altid åben for feedback. Du kan kontakte mig på Twitter eller Kubernetes Slack kanal. God fornøjelse med at ændre dine manifester med kustomize!

PS fra oversætteren

Læs også på vores blog:

• «Værktøjer til udviklere af applikationer, der kører på Kubernetes";
• «Kubernetes 1.14: Højdepunkter i det nye";
• «Fem hovedresultater af Helm Summit 2019 i Amsterdam";
• «Praktisk introduktion til pakkehåndteringen for Kubernetes - Helm'.

Kilde: www.habr.com