🥇Korte introductie tot Kustomize

Opmerking vertaler.: Het artikel is geschreven door Scott Lowe, een ervaren IT-engineer en auteur/co-auteur van zeven gedrukte boeken (voornamelijk over VMware vSphere). Momenteel werkt hij voor de dochteronderneming van VMware - Heptio (overgenomen in 2016), gespecialiseerd in cloud computing en Kubernetes. De tekst dient als een beknopte en begrijpelijke inleiding tot het configuratiemanagement voor Kubernetes met behulp van technologie Kustomize, recent toegevoegd aan K8s.

Kustomize is een tool die gebruikers in staat stelt om "eenvoudige en sjabloonvrije YAML-bestanden aan te passen voor verschillende doeleinden, terwijl het originele YAML onaangetast en bruikbaar blijft" (beschrijving rechtstreeks ontleend aan de Kustomize-repository op GitHub). Kustomize kan rechtstreeks worden uitgevoerd of, vanaf Kubernetes 1.14, gebruikt worden met kubectl -k om toegang te krijgen tot de functionaliteiten (hoewel, op basis van Kubernetes 1.15, de aparte binaire versie nieuwer is dan de ingebouwde mogelijkheden in kubectl). (Opmerking vertaler.: Met de recente release van Kubernetes 1.16 kustomize ondersteunt dus ook binnen de kubeadm-tool.) In deze publicatie wil ik de lezers kennismaken met de basisprincipes van Kustomize.

In zijn eenvoudigste vorm/toepassing is Kustomize gewoon een verzameling resources (YAML-bestanden die de Kubernetes-objecten definiëren: Deployments, Services, enz.) plus een lijst met instructies over de wijzigingen die in deze resources moeten worden aangebracht. Net zoals make een set instructies gebruikt die zijn opgenomen in Makefile, en Docker een container bouwt op basis van de instructies uit Dockerfile, gebruikt Kustomize kustomization.yaml om de voorschriften op te slaan over welke wijzigingen de gebruiker wil aanbrengen in de verzameling resources.

Hier is een voorbeeld van een bestand kustomization.yaml:

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

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

Veld geeft aan welke (resources) Kustomize zal wijzigen. In dit geval zal het resources zoeken in de bestanden deployment.yaml service.yaml en in zijn directory (indien nodig kunnen volledige of relatieve paden worden opgegeven). namePrefix
Veld geeft aan dat Kustomize een bepaald voorvoegsel (in dit geval - dev- ) aan het attribuutvan alle resources die in het veld zijn gedefinieerd, moet toevoegen. Dus, als de Deployment een naam nginx-deployment geeft aan welke (resources) Kustomize zal wijzigen. In dit geval zal het resources zoeken in de bestandenheeft, zal Kustomize het omzetten naar naam met de waarde dev-nginx-deployment, kustomize zal dit maken van dev-nginx-deployment.
Veld namespace voorschrijft aan kustomize om de opgegeven namespace aan alle bronnen toe te voegen. In dit geval zullen Deployment en Service in de namespace vallen ontwikkeling.
Ten slotte, het veld commonLabels bevat een set labels die aan alle bronnen zal worden toegevoegd. In ons voorbeeld zal kustomize de bronnen labelen met de naam omgeving en waarde. ontwikkeling.

Als de gebruiker kustomize build . uitvoert in de directory met het bestand kustomization.yaml en de benodigde bronnen (d.w.z. bestanden service.yaml en in zijn directory (indien nodig kunnen volledige of relatieve paden worden opgegeven).), dan ontvangt hij tekst met de wijzigingen zoals beschreven in kustomization.yaml.

Opmerking vertaler.: Illustratie uit de documentatie van het project voor het 'eenvoudige' gebruik van kustomize

De uitvoer kan worden omgeleid als het nodig is om de wijzigingen vast te leggen:

kustomize build . > custom-config.yaml

De output is deterministisch (met dezelfde gegevens als invoer zullen dezelfde resultaten als uitvoer worden verkregen), dus het is niet nodig om het resultaat in een bestand op te slaan. In plaats daarvan kan het direct aan een ander commando worden doorgegeven:

kustomize build . | kubectl apply -f -

Toegang tot de functies van kustomize kan ook worden verkregen via kubectl -k (vanaf versie 1.14 van Kubernetes). Houd er echter rekening mee dat het afzonderlijke kustomize-pakket sneller wordt bijgewerkt dan dat het is geïntegreerd in kubectl (althans, zo is de situatie met de release van Kubernetes 1.15).

Lezers kunnen zich afvragen: 'Waarom al deze complexiteit als we de bestanden rechtstreeks kunnen bewerken?'. Goede vraag. In ons voorbeeld is het inderdaad mogelijk kan de bestanden service.yaml en in zijn directory (indien nodig kunnen volledige of relatieve paden worden opgegeven). rechtstreeks te bewerken, maar wat als ze een fork zijn van iemands project? Directe wijziging van bestanden bemoeilijkt (of maakt het zelfs onmogelijk) om rebase van de fork uit te voeren wanneer er wijzigingen in de bron worden aangebracht. Het gebruik van kustomize maakt het mogelijk om deze wijzigingen te centraliseren in een bestand kustomization.yaml, waardoor de oorspronkelijke bestanden intact blijven en zo rebase van de originele bestanden indien nodig vergemakkelijkt wordt.

De voordelen van kustomize worden duidelijk in meer complexe gebruikscases. In het bovenstaande voorbeeld kustomization.yaml en de bronnen bevinden zich in dezelfde directory. Kustomize ondersteunt echter gebruiksscenario's waarbij er een basisconfiguratie is met verschillende varianten, ook wel bekend als overlays. Bijvoorbeeld, de gebruiker wil de Deployment en Service voor nginx die ik als voorbeeld heb gebruikt, en development-, staging- en productieversies (of varianten) van die bestanden maken. Hiervoor heeft hij de eerder genoemde overlays en de eigenlijke basisbronnen nodig.

Om het idee van overlays en basisresources te illustreren (basisresources), laten we aannemen dat de mappen de volgende structuur hebben:

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

In het bestand basis/kustomization.yaml gebruikers verklaren via het veld geeft aan welke (resources) Kustomize zal wijzigen. In dit geval zal het resources zoeken in de bestanden gewoon de resources die kustomize moet opnemen.

In elk van de bestanden overlays/{dev,staging,prod}/kustomization.yaml verwijzen gebruikers naar de basisconfiguratie in het veld geeft aan welke (resources) Kustomize zal wijzigen. In dit geval zal het resources zoeken in de bestanden, en geven vervolgens specifieke wijzigingen aan voor deze omgeving. Bijvoorbeeld, het bestand overlays/dev/kustomization.yaml kan eruitzien als het voorbeeld dat eerder werd gegeven:

resources:
- ..//..//basis
namePrefix: dev-
namespace: ontwikkeling
commonLabels:
  environment: ontwikkeling

Tegelijkertijd kan het bestand overlays/prod/kustomization.yaml helemaal anders zijn:

resources:
- ..//..//basis
namePrefix: prod-
namespace: productie
commonLabels:
  environment: productie
  sre-team: blauw

Wanneer een gebruiker kustomize build . in de catalogus overlays/dev, genereert kustomize een variant voor ontwikkeling. Als je echter kustomize build . in de catalogus overlays/prod start, krijg je een variant voor productie. En dit alles — zonder enige wijzigingen in de oorspronkelijke (basis) bestanden, en dit alles — op een declaratieve en deterministische manier. Je kunt de basisconfiguratie en de overlay-mappen direct in het versiebeheersysteem commits doen, wetende dat je op basis van deze bestanden op elk moment de gewenste configuratie kunt reproduceren.

Opmerking vertaler.: Illustratie uit de documentatie van het project over het gebruik van overlays in kustomize

Kustomize kan veel meer dan wat in dit artikel wordt verteld. Ik hoop echter dat het een goede inleiding zal zijn.

Aanvullende bronnen

Er zijn veel goede artikelen en publicaties over kustomize. Hier zijn enkele waarvan ik vond dat ze bijzonder nuttig waren:

Opmerking vertaler.: Ook kan ik een linksebloque aanraden, gepubliceerd als Bronnen op de site van de utility, en de daaropvolgende verzameling video's met de laatste presentaties over kustomize.

Als je vragen of suggesties hebt voor het verbeteren van dit materiaal, sta ik altijd open voor feedback. Je kunt me bereiken in Twitter of naar de Slack-kanaal van Kubernetes. Geniet van het modificeren van je manifesten met kustomize!

Korte introductie tot Kustomize

Aanvullende bronnen

P.S. van de vertaler