En kort introduktion till Kustomize

Notera. transl.: Artikeln skrevs av Scott Lowe, en ingenjör med lång erfarenhet av IT, som är författare/medförfattare till sju tryckta böcker (främst på VMware vSphere). Han arbetar nu för dess VMware-dotterbolag Heptio (förvärvade 2016), specialiserat på cloud computing och Kubernetes. Texten i sig fungerar som en kortfattad och lättförståelig introduktion till konfigurationshantering för Kubernetes med hjälp av teknik Anpassa, som nyligen blev en del av K8s.

Kustomize är ett verktyg som gör det möjligt för användare att "anpassa enkla, mallfria YAML-filer för olika ändamål, och lämna den ursprungliga YAML intakt och användbar" (beskrivning lånad direkt från kustomisera repository på GitHub). Kustomize kan köras direkt eller, från och med Kubernetes 1.14, användas kubectl -k för att komma åt dess funktionalitet (även om från och med Kubernetes 1.15 är den separata binären nyare än de funktioner som är inbyggda i kubectl). (Notera. transl.: Och med den senaste releasen Kubernetes 1.16 anpassa stöds av även i kubeadm-verktyget.) I det här inlägget vill jag introducera läsarna till grunderna i kustomize.

I sin enklaste form/applikation är kustomize helt enkelt en samling resurser (YAML-filer som definierar Kubernetes-objekt: Deployments, Services, etc.) plus en lista med instruktioner för ändringar som måste göras i dessa resurser. Precis som make använder instruktionsuppsättningen som finns i Makefile, och Docker bygger behållaren baserat på instruktioner från Dockerfile,anpassa användningsområden kustomization.yaml för att lagra instruktioner om vilka ändringar användaren vill göra i en uppsättning resurser.

Här är en exempelfil kustomization.yaml:

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

Jag ska inte försöka prata om alla möjliga fält i filen. kustomization.yaml (det här är välskrivet om här), men jag kommer att ge en kort förklaring av ett specifikt exempel:

• Fält resources indikerar vad (vilka resurser) kustomize kommer att förändras. I det här fallet kommer den att leta efter resurser i filer deployment.yaml и service.yaml i din katalog (du kan ange fullständiga eller relativa sökvägar om det behövs).
• Fält namePrefix instruerar kustomize att lägga till ett visst prefix (i det här fallet - dev-) att tillskriva name alla resurser definierade i fältet resources. Således, om Deployment har name med mening nginx-deployment, anpassa kommer att göra det dev-nginx-deployment.
• Fält namespace instruerar kustomize att lägga till det givna namnområdet till alla resurser. I det här fallet faller Deployment and Service in i namnområdet development.
• Äntligen fältet commonLabels innehåller en uppsättning etiketter som kommer att läggas till alla resurser. I vårt exempel kommer kustomize att tilldela en etikett till resurserna med namnet environment och mening development.

Om användaren gör det kustomize build . i katalogen med filen kustomization.yaml och nödvändiga resurser (d.v.s. filer deployment.yaml и service.yaml), då kommer den att ta emot en text med de ändringar som anges i kustomization.yaml.

Notera. transl.: Illustration från projektdokumentationen om den "enkla" användningen av kustomize

Utgången kan omdirigeras om ändringar behöver genomföras:

kustomize build . > custom-config.yaml

Utdata är deterministiska (samma indata ger samma utdata), så du behöver inte spara resultatet i en fil. Istället kan det skickas direkt till ett annat kommando:

kustomize build . | kubectl apply -f -

Kutomize-funktionerna kan också nås via kubectl -k (sedan Kubernetes version 1.14). Kom dock ihåg att det fristående kustomize-paketet uppdateras snabbare än det integrerade kubectl-paketet (åtminstone är det fallet med Kubernetes 1.15-utgåvan).

Läsare kan fråga sig: "Varför all denna komplexitet om du kan redigera filerna direkt?" Bra fråga. I vårt exempel, faktiskt kan man ändra filer deployment.yaml и service.yaml direkt, men vad händer om de är en gaffel av någon annans projekt? Att ändra filer direkt gör det svårt (om inte omöjligt) att basera om en gaffel när ändringar görs i ursprunget/källan. Genom att använda kustomize kan du centralisera dessa ändringar i en fil kustomization.yaml, lämnar originalfilerna intakta och gör det enklare att basera om originalfilerna om det behövs.

Fördelarna med kustomize blir uppenbara i mer komplexa användningsfall. I exemplet ovan kustomization.yaml och resurserna finns i samma katalog. Emellertid stöder kustomize användningsfall där det finns en baskonfiguration och många varianter av den, även känd som överlag. Till exempel ville en användare ta Deployment and Service för nginx, som jag använde som exempel, och skapa utvecklings-, iscensättnings- och produktionsversioner (eller varianter) av dessa filer. För att göra detta kommer han att behöva de ovan nämnda överläggen och faktiskt själva de grundläggande resurserna.

För att illustrera idén med överlägg och underliggande resurser (basresurser), låt oss anta att katalogerna har följande struktur:

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

I fil base/kustomization.yaml användare som använder fältet resources deklarera helt enkelt vilka resurser som kustomize ska inkludera.

I var och en av filerna overlays/{dev,staging,prod}/kustomization.yaml användare hänvisar till baskonfigurationen i fältet resources, och ange sedan specifika ändringar för given miljö. Till exempel fil overlays/dev/kustomization.yaml kan se ut som exemplet tidigare:

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

I det här fallet filen overlays/prod/kustomization.yaml kan vara helt annorlunda:

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

När användaren kör kustomize build . i katalogen overlays/dev, kommer kustomize att generera utvecklingsalternativet. Om du springer kustomize build . i katalogen overlays/prod - du får produktionsalternativet. Och allt detta - utan att göra några ändringar i originalet (bas) filer, allt på ett deklarativt och deterministiskt sätt. Du kan överföra baskonfigurationen och överläggskatalogerna direkt till versionskontroll, med vetskapen om att du kan återskapa den önskade konfigurationen när som helst baserat på dessa filer.

Notera. transl.: Illustration från projektdokumentationen om användning av överlägg i kustomize

Anpassa burken mycket mer än vad som tas upp i den här artikeln. Jag hoppas dock att det fungerar som en bra introduktion.

Ytterligare resurser

Det finns många bra artiklar och publikationer om kustomize. Här är några som jag tyckte var särskilt användbara:

• Ändra bas YAML-konfiguration för olika miljöer prod/test med Kustomize;
• Kustomize — Rätt sätt att göra mallar i Kubernetes;
• Deklarativ hantering av Kubernetes-objekt med hjälp av Customize;
• Anpassa Upstream Helm Charts med Customize.

Notera. transl.: Du kan också rekommendera ett block med länkar publicerade som Resurser på verktygets webbplats, följt av en samling videor med de senaste rapporterna om kustomize.

Om du har frågor eller förslag för att förbättra detta material är jag alltid öppen för feedback. Du kan kontakta mig på Twitter eller Kubernetes Slack-kanal. Ha kul med att modifiera dina manifest med kustomize!

PS från översättaren

Läs även på vår blogg:

• «Verktyg för utvecklare av applikationer som körs på Kubernetes";
• «Kubernetes 1.14: översikt över de viktigaste innovationerna";
• «Fem huvudresultat från Helm Summit 2019 i Amsterdam";
• «Praktisk introduktion till pakethanteraren för Kubernetes - Helm".

Källa: will.com