🥇Korte introductie tot Kustomize

Opmerking. vert.: Het artikel is geschreven door Scott Lowe, een ingenieur met uitgebreide ervaring in IT, die de auteur/co-auteur is van zeven gedrukte boeken (voornamelijk over VMware vSphere). Hij werkt nu voor zijn VMware-dochter Heptio (overgenomen in 2016), gespecialiseerd in cloud computing en Kubernetes. De tekst zelf dient als een beknopte en gemakkelijk te begrijpen introductie tot configuratiebeheer voor Kubernetes met behulp van technologie Aanpassen, dat onlangs onderdeel werd van K8s.

Kustomize is een tool waarmee gebruikers “eenvoudige, sjabloonvrije YAML-bestanden voor verschillende doeleinden kunnen aanpassen, waarbij de originele YAML intact en bruikbaar blijft” (beschrijving rechtstreeks ontleend aan kustomize-repository op GitHub). Kustomize kan direct worden uitgevoerd of, vanaf Kubernetes 1.14, worden gebruikt kubectl -k om toegang te krijgen tot de functionaliteit ervan (hoewel vanaf Kubernetes 1.15 het afzonderlijke binaire bestand nieuwer is dan de mogelijkheden die in kubectl zijn ingebouwd). (Opmerking. vert.: En met de recente release Kubernetes 1.16 aanpassen ondersteund door ook in het kubeadm-hulpprogramma.) In dit bericht wil ik lezers kennis laten maken met de basisprincipes van kustomize.

In de eenvoudigste vorm/toepassing is kustomize eenvoudigweg een verzameling bronnen (YAML-bestanden die Kubernetes-objecten definiëren: implementaties, services, enz.) plus een lijst met instructies voor wijzigingen die in die bronnen moeten worden aangebracht. Net zoals make gebruik maakt van de instructieset in Makefile, en Docker bouwt de container op basis van instructies uit Dockerfile, pas het gebruik aan kustomization.yaml om instructies op te slaan over welke wijzigingen de gebruiker wil aanbrengen in een reeks bronnen.

Hier is een voorbeeldbestand kustomization.yaml:

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

Ik zal niet proberen alle mogelijke velden in het bestand te bespreken. kustomization.yaml (hier is goed over geschreven hier), maar ik zal een korte uitleg geven van een specifiek voorbeeld:

Veld resources geeft aan wat (welke middelen) kustomize gaat veranderen. In dit geval zoekt het naar bronnen in bestanden deployment.yaml и service.yaml in uw map (u kunt indien nodig volledige of relatieve paden opgeven).
Veld namePrefix instrueert kustomize om een bepaald voorvoegsel toe te voegen (in dit geval - dev-) toe te schrijven name alle bronnen die in het veld zijn gedefinieerd resources. Dus als Deployment dat heeft gedaan name met betekenis nginx-deployment, aanpassen zal het redden dev-nginx-deployment.
Veld namespace instrueert kustomize om de opgegeven naamruimte aan alle bronnen toe te voegen. In dit geval vallen Implementatie en Service in de naamruimte development.
Tenslotte het veld commonLabels bevat een set labels die aan alle bronnen worden toegevoegd. In ons voorbeeld wijst kustomize een label toe aan de bronnen met de naam environment en betekenis development.

Als de gebruiker dat doet kustomize build . in de map met het bestand kustomization.yaml en de benodigde bronnen (d.w.z. bestanden deployment.yaml и service.yaml), dan ontvangt het bij de uitvoer een tekst met de wijzigingen gespecificeerd in kustomization.yaml.

Opmerking. vert.: Illustratie uit de projectdocumentatie over het “eenvoudige” gebruik van kustomize

De uitvoer kan worden omgeleid als er wijzigingen moeten worden vastgelegd:

kustomize build . > custom-config.yaml

De uitvoergegevens zijn deterministisch (dezelfde invoergegevens zullen dezelfde uitvoerresultaten opleveren), dus u hoeft het resultaat niet in een bestand op te slaan. In plaats daarvan kan het rechtstreeks aan een ander commando worden doorgegeven:

kustomize build . | kubectl apply -f -

De kustomize-functies zijn ook toegankelijk via kubectl -k (sinds Kubernetes versie 1.14). Houd er echter rekening mee dat het standalone kustomize-pakket sneller wordt bijgewerkt dan het geïntegreerde kubectl-pakket (dit is tenminste het geval met de Kubernetes 1.15-release).

Lezers vragen zich misschien af: “Waarom al deze complexiteit als je de bestanden rechtstreeks kunt bewerken?” Grote vraag. In ons voorbeeld inderdaad men kan bestanden wijzigen deployment.yaml и service.yaml direct, maar wat als ze een afsplitsing zijn van het project van iemand anders? Het rechtstreeks wijzigen van bestanden maakt het moeilijk (zo niet onmogelijk) om een fork opnieuw te baseren wanneer er wijzigingen worden aangebracht in de oorsprong/bron. Met behulp van kustomize kunt u deze wijzigingen centraliseren in een bestand kustomization.yaml, waardoor de originele bestanden intact blijven en het dus gemakkelijker wordt om de originele bestanden indien nodig opnieuw te baseren.

De voordelen van kustomize worden duidelijk in complexere gebruikssituaties. In het bovenstaande voorbeeld kustomization.yaml en de bronnen bevinden zich in dezelfde map. Kustomize ondersteunt echter gebruiksscenario's waarbij er een basisconfiguratie is en vele varianten daarvan, ook wel bekend als overlays. Een gebruiker wilde bijvoorbeeld Deployment and Service voor nginx nemen, dat ik als voorbeeld gebruikte, en ontwikkelings-, staging- en productieversies (of varianten) van die bestanden maken. Om dit te doen heeft hij de bovengenoemde overlays nodig, en in feite de basisbronnen zelf.

Om het idee van overlays en onderliggende bronnen te illustreren (basisbronnen)Laten we aannemen dat de mappen de volgende structuur hebben:

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

In bestand base/kustomization.yaml gebruikers die het veld gebruiken resources geef eenvoudigweg de bronnen aan die kustomize zou moeten bevatten.

In elk van de bestanden overlays/{dev,staging,prod}/kustomization.yaml gebruikers verwijzen naar de basisconfiguratie in het veld resourcesen geef vervolgens specifieke wijzigingen aan voor gegeven omgeving. Bestand bijvoorbeeld overlays/dev/kustomization.yaml zou eruit kunnen zien als het eerder gegeven voorbeeld:

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

In dit geval het bestand overlays/prod/kustomization.yaml kan heel anders zijn:

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

Wanneer de gebruiker draait kustomize build . in de catalogus overlays/dev, kustomize zal de ontwikkelingsoptie genereren. Als je vlucht kustomize build . in de catalogus overlays/prod - je krijgt de productieoptie. En dit alles - zonder enige wijziging aan het origineel aan te brengen (baseren) bestanden, allemaal op een declaratieve en deterministische manier. U kunt de basisconfiguratie en overlay-mappen rechtstreeks aan versiebeheer doorgeven, wetende dat u op basis van deze bestanden op elk gewenst moment de gewenste configuratie kunt reproduceren.

Opmerking. vert.: Illustratie uit de projectdocumentatie over het gebruik van overlays in kustomize

Aanpassen kan veel meer dan wat in dit artikel wordt behandeld. Ik hoop echter dat het een goede introductie is.

Aanvullende bronnen

Er zijn veel goede artikelen en publicaties over kustomize. Hier zijn er een paar die ik bijzonder nuttig vond:

Opmerking. vert.: U kunt ook een blok links aanbevelen dat is gepubliceerd als Resources op de website van het hulpprogramma, gevolgd door een verzameling video's met de laatste berichten over kustomize.

Als je vragen of suggesties hebt om dit materiaal te verbeteren, sta ik altijd open voor feedback. U kunt contact met mij opnemen via Twitter of Kubernetes Slack-kanaal. Veel plezier met het aanpassen van uw manifesten met kustomize!

Een korte introductie tot Kustomize

Aanvullende bronnen

PS van vertaler

Voeg een reactie Reactie annuleren