🥇Kubernetes 1.16: oversigt over de vigtigste nyheder | ProHoster

Bem. overs.: Artiklen er skrevet af Scott Lowe – en ingeniør med mange års erfaring inden for IT, som er forfatter/medforfatter til syv trykte bøger (primært om VMware vSphere). Han arbejder nu i VMware's datterselskab Heptio (opkøbt i 2016), hvor han specialiserer sig i cloud computing og Kubernetes. Selve teksten fungerer som en kortfattet og letforståelig introduktion til konfigurationsstyring for Kubernetes ved hjælp af teknologien Kustomize, som for nylig er blevet en del af K8s.

Kustomize er et værktøj, der giver brugerne mulighed for at 'tilpasse enkle og skabelonfrie YAML-filer til forskellige formål, samtidig med at den originale YAML forbliver uændret og brugbar' (beskrivelsen er taget direkte fra kustomize-repositoriet på GitHub). Kustomize kan køres direkte eller, fra Kubernetes 1.14, bruges med kubectl -k for at få adgang til dens funktioner (selvom pr. Kubernetes 1.15 er den separate binære fil nyere end de funktioner, der er indbygget i kubectl). (Bem. overs.: Og med den nylige udgivelse af Kubernetes 1.16 kustomize understøttes også i kubeadm-værktøjet.) I denne publikation vil jeg introducere læserne til grundlæggende om kustomize.

I sin enkleste form/anvendelse er kustomize blot et sæt ressourcer (YAML-filer, der definerer Kubernetes-objekter: Deployments, Services osv.) plus en liste over instrukser om de ændringer, der skal foretages i disse ressourcer. Ligesom make bruger et sæt instrukser, der findes i Makefil, og Docker bygger en container baseret på instrukser fra Dockerfile, bruger kustomize kustomization.yaml til at gemme anvisningerne om, hvilke ændringer brugeren ønsker at foretage i sæt af 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 (dette er godt beskrevet her), men jeg vil give en kort forklaring af et specifikt eksempel:

• Felt resources angiver, hvilke ressourcer kustomize vil ændre. I dette tilfælde vil det lede efter ressourcer i filer deployment.yaml og service.yaml i sin mappe (det er muligt at angive fulde eller relative stier, hvis nødvendigt).
• Felt namePrefix angiver kustomize at tilføje et bestemt præfiks (i dette tilfælde – dev-) til attributten name for alle ressourcer, der er defineret i feltet resources. Så hvis der i Deployment'et er name med værdien nginx-deployment, vil kustomize gøre det til dev-nginx-deployment.
• Felt namespace angiver kustomize at tilføje det specificerede namespaces til alle ressourcer. I dette tilfælde vil Deployment og Service blive placeret i namespace udvikling.
• Endelig feltet commonLabels indeholder et sæt labels, der vil blive tilføjet til alle ressourcer. I vores eksempel vil kustomize tildele ressourcerne en label med navnet environment og værdi udvikling.

Hvis brugeren udfører kustomize build . i mappen med filen kustomization.yaml og de nødvendige ressourcer (dvs. filerne deployment.yaml og service.yaml), vil output være tekst med ændringerne angivet i kustomization.yaml.

Bem. overs.: Illustration fra projektets dokumentation om "simpel" brug af kustomize

Output kan omdirigeres, hvis det er nødvendigt at registrere ændringer:

kustomize build . > custom-config.yaml

Output er deterministisk (med de samme inputdata vil man opnå de samme outputresultater), så der er ikke behov for at gemme resultatet i en fil. I stedet kan det straks overføres til en anden kommando:

kustomize build . | kubectl apply -f -

Adgang til kustomize funktioner kan også fås gennem kubectl -k (fra version 1.14 Kubernetes). Men vær opmærksom på, at det separate kustomize-pakke opdateres hurtigere end den, der er integreret i kubectl (i det mindste er det sådan, det står til med Kubernetes version 1.15).

Læsere kan spørge: "Hvorfor alt dette besvær, når man kan redigere filerne direkte?". Godt spørgsmål. I vores eksempel kan man faktisk you can modificere filer deployment.yaml og service.yaml direkte, men hvad hvis de er en fork af et andet projekt? Direkte ændring af filer gør det besværligt (hvis overhovedet muligt) at rebase fork’en, når der foretages ændringer i kilden/originalen. Brug af kustomize muliggør centralisering af disse ændringer i filen kustomization.yaml, hvilket efterlader de originale filer intakte og dermed letter rebase af de originale filer, når det er nødvendigt.

Fordelene ved kustomize bliver tydelige i mere komplekse brugsscenarier. I det ovenfor nævnte eksempel kustomization.yaml og ressourcerne er i den samme mappe. Men kustomize understøtter brugsscenarier, hvor der er en grundlæggende konfiguration og mange variationer af den, også kendt som den nye kommando. For eksempel ønskede brugeren at tage Deployment og Service for nginx, som jeg brugte som eksempel, og skabe udviklings-, staging- og produktionsversioner (eller variationer) af disse filer. For dette vil han have brug for de førnævnte overlays og selve de grundlæggende ressourcer.

For at illustrere ideen om overlays og basisressourcer (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 filen base/kustomization.yaml brugere bruger feltet resources til blot at erklære de ressourcer, som kustomize skal inkludere.

I hver af filerne overlays/{dev,staging,prod}/kustomization.yaml henviser brugere til den grundlæggende konfiguration i feltet resources, og angiver derefter specifikke ændringer for denne miljø. For eksempel kan filen overlays/dev/kustomization.yaml se ud som eksemplet, der blev givet tidligere:

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

I mellemtiden kan filen overlays/prod/kustomization.yaml se helt anderledes ud:

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

Når brugeren kører kustomize build . i katalogen overlays/dev, vil kustomize generere en variant til development. Hvis der derimod køres kustomize build . i katalogen overlays/prod , får man en variant til production. Og alt dette – uden at ændre noget i de oprindelige (basis) filer, og alt dette – på en deklarativ og deterministisk måde. Man kan commite den grundlæggende konfiguration og overlay-mapper direkte i versionskontrolsystemet, velvidende at den ønskede konfiguration når som helst kan reproduceres baseret på disse filer.

Bem. overs.: Illustration fra dokumentationen om brug af overlays i kustomize

Kustomize kan meget mere, end der er beskrevet i denne artikel. Jeg håber dog, det vil være en god introduktion.

Yderligere ressourcer

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

• Skift basis YAML-konfiguration for forskellige miljøer prod/test ved hjælp af Kustomize;
• Kustomize — Den rigtige måde at lave templating i Kubernetes;
• Deklarativ administration af Kubernetes-objekter ved hjælp af Kustomize;
• Tilpasning af upstream Helm Charts med Kustomize.

Bem. overs.: Det er også værd at nævne et link, der er offentliggjort som Ressourcer på værktøjets hjemmeside, og den efterfølgende samling af videoer med de seneste oplæg 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 i Twitter eller på Kubernetes Slack-kanal. Hav det sjovt med at modificere dine manifester ved hjælp af kustomize!

P.S. fra oversætteren

Læs også på vores blog:

• «Værktøjer til udviklere af applikationer, der køres i Kubernetes»;
• «Kubernetes 1.14: oversigt over hovednyhederne»;
• «Fem vigtigste konklusioner fra Helm Summit 2019 i Amsterdam»;
• «Praktisk introduktion til pakken manager for Kubernetes — Helm».

Kilde: habr.com