Kustomize

De periode waarin ik met Kubernetes begon (rond 2018) kan je samenvatten als een periode waarin Kubernetes en de cloud native filosofie een enorme tractie krijgt. Veel “problemen” werden opgelost met nieuwe hippe projecten. Het was een tijd waarin het soms lastig was om je weg te vinden in een situatie vol wildgroei en onbekende dingen. Nu, jaren later is er veel meer duidelijk geworden en gestandaardiseerd. Ook zie je dat bepaalde softwareprojecten een integraal onderdeel worden en bijvoorbeeld ook hun plek gevonden hebben in de certificeringen. Zo ook Kustomize.

In die periode werd ook begonnen de ontwikkeling van Kustomize. Een Kubernetes native manier om generieke Kubernetes yaml-definities te patchen voor verschillende environments. Ik kende het niet en het project bevond zich ook nog in een beginfase. Wel moest ik mijn yaml files geschikt maken voor verschillende environments. Je kan je voorstellen dat je voor een testomgeving andere waardes gebruikt dan in een productieomgeving voor namespaces, CPU en Memory limieten en het aantal replicas. Uiteraard zijn er veel meer voorbeelden te verzinnen.

Hoe ik dat toen deed? Ik maakte bijvoorbeeld Python scripts om yaml files uit een externe GIT repository van een project te patchen voor ik ze op een k8s cluster ging installeren. Helm was in opkomst en veel software maakte daar nog geen gebruik van. Ook gebruikte ik Jinja2 templates om een generiek yaml-manifest geschikt te maken voor bijvoorbeeld test en productieomgevingen. Het werkte verder prima en je moet wat als het echte gereedschap ontbreekt of je geen weet van hebt van het bestaan er van.

Tegenwoordig is Kustomize een Kubernetes native manier om yaml files te patchen zodat ze voor verschillende environments gebruikt kunnen worden zonder dat je de originele files aan hoeft te passen. De tool zit inmiddels al een tijdje ingebouwd in kubectl. Je hoeft er dus geen extra software voor te installeren. Ook is het onderdeel geworden van het CKAD (Certified Kubernetes Application Developer) curriculum. Momenteel bereid ik me voor op het CKAD examen. Kustomize is niet super nieuw meer maar samen met deze terugblik geeft het wel aan dat ook op dit vlak Kubernetes de afgelopen jaren grote stappen heeft gezet qua volwassenheid. Tijd om even te belichten hoe het voor je kan werken.

Voorbeeld

Hieronder zie je een voorbeeld mappenstructuur waarin Kustomize gebruikt wordt voor het patchen van een yaml manifest zodat het geschikt wordt voor productie. Uiteraard is het een demonstratie en is er meer nodig om het echt toe te passen.

• kustomize-map/
• kustomize-map/base (De directory voor de generieke yaml manifesten en de basis kustomization.yaml file)
• kustomize-map/deployment.yaml: ( een voorbeeld van een generieke definitie die een patch moet krijgen:

• kustomize-map/bas/kustomization.yaml: ( De basis Kustomize file ):

• kustomize-map/overlays: De directory waarin je de verschillende environment mappen kan zetten waar patches voor gemaakt moeten worden.
• kustomize-map/overlays/env-prod: De directory die de Customise instructies voor productie bevat.
• kustomize-map/overlays/env-prod/kustomization.yaml: De file met instructies voor Kustomize om manifesten te patchen voor productie.

• kustomize-map/overlays/env-prod/patch-deployment.yaml: De daadwerkelijke patch die de generieke manifest geschikt maakt voor productie.

Met een Kubectl dry-run commando kan getest worden hoe je het voorbeeld hierboven kan gebruiken om je generieke manifest voor een specifieke omgeving geschikt te maken:

kubectl apply -k ./kustomize-map/overlays/env-prod/ --dry-run=client -o yaml

In de afbeelding in de tabel hierboven is het origineel van de generieke deployment te zien. Hieronder staat de door Kustomize aangepaste versie. Te zien is dat bijvoorbeeld de namespace is aangepast:

Tot slot

In de afgelopen jaren is Kubernetes een stuk volwassener geworden. Tools als Kustomize en de integratie er van in Kubectl zijn hier een mooi voorbeeld van. Deze ontwikkelingen tonen ook het nut aan van actuele recente certificeringen. Wees je altijd bewust van wat je doet, welke tools je gebruikt en wat er in de markt al dan niet open source te te krijgen is. Het gegeven voorbeeld is puur indicatief. Het kan je helpen om in je eigen real world scenario op basis van 1 generiek manifest toch maatwerk patches te maken zodat het past bij de omgeving waarop je werkt. De gebruikte bestanden zijn te vinden op mijn git repository in de map kustomize-project-1.

Zelf heb ik recent Kustomize gebruikt om de cloudnative MySQL compatible database operator Vitess te installeren. Standaard staat daar alles in de “example” namespace. Dat is functioneel geen enkel probleem maar het staat wel een beetje gek op productie of test. Verder is het nog wel een beetje gek dat de te gebruiken api versie “kustomize.config.k8s.io/v1beta1” is. Beta is toch niet the new stable?

Over de auteur

Geurt

See author's posts

• Containers vanaf scratch
• Service Accounts
• Kustomize
• Cilium en BGP