'n Kort inleiding tot Kustomize

Let wel. vertaal.: Die artikel is geskryf deur Scott Lowe, 'n ingenieur met uitgebreide ervaring in IT, wat die skrywer/mede-outeur van sewe gedrukte boeke is (hoofsaaklik op VMware vSphere). Hy werk nou vir sy VMware-filiaal Heptio (in 2016 verkry), wat spesialiseer in wolkrekenaars en Kubernetes. Die teks self dien as 'n bondige en maklik verstaanbare inleiding tot konfigurasiebestuur vir Kubernetes wat tegnologie gebruik Pasmaak, wat onlangs deel geword het van K8s.

Kustomize is 'n instrument wat gebruikers toelaat om "eenvoudige, sjabloonvrye YAML-lêers vir verskillende doeleindes aan te pas, wat die oorspronklike YAML ongeskonde en bruikbaar laat" (beskrywing direk geleen van kustomiseer bewaarplek op GitHub). Kustomize kan direk uitgevoer word of, vanaf Kubernetes 1.14, gebruik word kubectl -k om toegang tot sy funksionaliteit te verkry (hoewel vanaf Kubernetes 1.15, die aparte binêre is nuwer as die vermoëns wat in kubectl ingebou is). (Let wel. vertaal.: En met die onlangse vrystelling Kubernetes 1.16 pasmaak ondersteun deur ook in die kubeadm-hulpprogram.) In hierdie pos wil ek lesers bekendstel aan die basiese beginsels van kustomize.

In sy eenvoudigste vorm/toepassing is kustomize bloot 'n versameling hulpbronne (YAML-lêers wat Kubernetes-voorwerpe definieer: Ontplooiings, Dienste, ens.) plus 'n lys van instruksies vir veranderinge wat aan daardie hulpbronne aangebring moet word. Net soos maak gebruik die instruksiestel vervat in Makefile, en Docker bou die houer op grond van instruksies van Dockerfile, pas gebruike aan kustomization.yaml om instruksies te stoor oor watter veranderinge die gebruiker aan 'n stel hulpbronne wil maak.

Hier is 'n voorbeeld lêer kustomization.yaml:

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

Ek sal nie probeer om oor al die moontlike velde in die lêer te praat nie. kustomization.yaml (hieroor is goed geskryf hier), maar ek sal 'n kort verduideliking van 'n spesifieke voorbeeld gee:

• Veld resources dui aan wat (watter hulpbronne) kustomize sal verander. In hierdie geval sal dit na hulpbronne in lêers soek deployment.yaml и service.yaml in jou gids (jy kan volle of relatiewe paaie spesifiseer indien nodig).
• Veld namePrefix gee kustomize opdrag om 'n sekere voorvoegsel by te voeg (in hierdie geval - dev-) toe te skryf name alle hulpbronne wat in die veld gedefinieer is resources. Dus, as Ontplooiing het name met betekenis nginx-deployment, pasmaak sal dit maak dev-nginx-deployment.
• Veld namespace gee opdrag aan kustomize om die gegewe naamruimte by alle hulpbronne te voeg. In hierdie geval sal Ontplooiing en Diens in die naamruimte val development.
• Ten slotte, die veld commonLabels bevat 'n stel etikette wat by alle hulpbronne gevoeg sal word. In ons voorbeeld sal kustomize 'n etiket aan die hulpbronne toeken met die naam environment en betekenis development.

As die gebruiker dit doen kustomize build . in die gids met die lêer kustomization.yaml en die nodige hulpbronne (d.w.s. lêers deployment.yaml и service.yaml), dan sal dit by die afvoer 'n teks ontvang met die veranderinge gespesifiseer in kustomization.yaml.

Let wel. vertaal.: Illustrasie uit die projekdokumentasie oor die “eenvoudige” gebruik van kustomize

Die uitset kan herlei word as veranderinge toegepas moet word:

kustomize build . > custom-config.yaml

Die uitsetdata is deterministies (dieselfde insetdata sal dieselfde uitsetresultate lewer), so jy hoef nie die resultaat in 'n lêer te stoor nie. In plaas daarvan kan dit direk na 'n ander opdrag oorgedra word:

kustomize build . | kubectl apply -f -

Die kustomize-kenmerke kan ook verkry word via kubectl -k (sedert Kubernetes weergawe 1.14). Hou egter in gedagte dat die selfstandige kustomize-pakket vinniger opgedateer word as die geïntegreerde kubectl-pakket (dit is ten minste die geval met die Kubernetes 1.15-vrystelling).

Lesers kan vra: "Waarom al hierdie kompleksiteit as jy die lêers direk kan wysig?" Goeie vraag. In ons voorbeeld, inderdaad kan 'n mens wysig lêers deployment.yaml и service.yaml direk, maar wat as hulle 'n vurk van iemand anders se projek is? Om lêers direk te verander, maak dit moeilik (indien nie onmoontlik nie) om 'n vurk te rebaseer wanneer veranderinge aan die oorsprong/bron gemaak word. Die gebruik van kustomize laat jou toe om hierdie veranderinge in 'n lêer te sentraliseer kustomization.yaml, laat die oorspronklike lêers ongeskonde en maak dit dus makliker om die oorspronklike lêers te herbaseer indien nodig.

Die voordele van kustomize word duidelik in meer komplekse gebruiksgevalle. In die voorbeeld hierbo kustomization.yaml en die hulpbronne is in dieselfde gids. Kustomize ondersteun egter gebruiksgevalle waar daar 'n basiskonfigurasie is en baie variante daarvan, ook bekend as overlays. Byvoorbeeld, 'n gebruiker wou Ontplooiing en Diens vir nginx, wat ek as voorbeeld gebruik het, neem en ontwikkelings-, opstel- en produksieweergawes (of variante) van daardie lêers skep. Om dit te kan doen, sal hy die bogenoemde oorlegsels benodig en eintlik die basiese hulpbronne self.

Om die idee van oorlegsels en onderliggende hulpbronne te illustreer (basis hulpbronne), kom ons neem aan dat die gidse die volgende struktuur het:

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

In lêer base/kustomization.yaml gebruikers wat die veld gebruik resources verklaar bloot die hulpbronne wat kustomize moet insluit.

In elk van die lêers overlays/{dev,staging,prod}/kustomization.yaml gebruikers verwys na die basiskonfigurasie in die veld resources, en dui dan spesifieke veranderinge aan vir gegewe omgewing. Byvoorbeeld, lêer overlays/dev/kustomization.yaml kan lyk soos die voorbeeld wat vroeër gegee is:

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

In hierdie geval die lêer overlays/prod/kustomization.yaml kan heeltemal anders wees:

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

Wanneer die gebruiker hardloop kustomize build . in die katalogus overlays/dev, sal kustomize die ontwikkelingsopsie genereer. As jy hardloop kustomize build . in die katalogus overlays/prod - jy kry die produksie-opsie. En dit alles – sonder om enige veranderinge aan die oorspronklike aan te bring (basis) lêers, alles op 'n verklarende en deterministiese manier. U kan die basiskonfigurasie en oorleggidse direk aan weergawebeheer toewys, met die wete dat u op grond van hierdie lêers die verlangde konfigurasie te eniger tyd kan reproduseer.

Let wel. vertaal.: Illustrasie uit die projekdokumentasie oor die gebruik van oorlegsels in kustomize

Pasmaak blikkie veel meer as wat in hierdie artikel gedek word. Ek hoop egter dit dien as 'n goeie inleiding.

Bykomende hulpbronne

Daar is baie goeie artikels en publikasies oor kustomize. Hier is 'n paar wat ek veral nuttig gevind het:

• Verander basis YAML-konfigurasie vir verskillende omgewings prod/toets met Kustomize;
• Kustomize - Die regte manier om sjablone in Kubernetes te doen;
• Verklarende bestuur van Kubernetes-voorwerpe met behulp van Pasmaak;
• Pas stroomop stuurkaarte aan met Pasmaak.

Let wel. vertaal.: Jy kan ook 'n blok skakels aanbeveel wat gepubliseer is as hulpbronne op die nutsprogram se webwerf, gevolg deur 'n versameling video's met die jongste verslae oor kustomize.

As jy vrae of voorstelle het om hierdie materiaal te verbeter, is ek altyd oop vir terugvoer. Jy kan my kontak by Twitter of Kubernetes Slack-kanaal. Geniet dit om jou manifeste met kustomize te wysig!

PS van vertaler

Lees ook op ons blog:

• «Gereedskap vir ontwikkelaars van toepassings wat op Kubernetes loop»;
• «Kubernetes 1.14: Hoogtepunte van wat nuut is»;
• «Vyf hoofresultate van Helm Summit 2019 in Amsterdam»;
• «Hands-on met die Kubernetes Pakketbestuurder - Helm".

Bron: will.com