Namespace Management met ArgoCD en Kustomize - Revisited

Sudo Friday ArgoCD Kustomize Kubernetes Components
  Wander Boessenkool

In het verleden hebben we hier gekeken naar een manier om namespaces op een Kubernetes cluster te managen met een ArgoCD ApplicationSet en Kustomize. Toen gebruikten we veelvuldig “Replacements”, maar omdat deze buiten de Kustomize tree stonden moesten we ArgoCD vertellen om de Kustomize LoadRestrictor op None te zetten.

Maar in 2½ jaar tijd veranderd er veel, tools krijgen nieuwe functionaliteit, mensen krijgen voortschrijdende inzichten, en we worden allemaal wat ouder en wijzer.

Daarom kijken we in deze video naar exact hetzelfde, maar de Replacements worden nu in “Components” verpakt, waardoor ze makkelijker herbruikbaar zijn als bouwblokjes. Wel komen we er dan achter dat Kustomize Components toepast voor Transformers (zoals de Namespace Transformer), en daar hebben we dus weer een ander trucje voor nodig…

Het gebruikte repository kun je hier vinden

Gerelateerde posts

Kubernetes GUIs deel 3: Freelens

In het verleden hebben we op dit kanaal al vaker gekeken naar grafische management tools voor Kubernetes. Een grote die we toen niet gedaan hebben was Lens, aangezien deze niet meer open-source is. Gelukkig is er ook Freelens, een fork van de open core van Lens (Openlens) die actief ontwikkelt wordt.

Promoties met Kustomize

Wanneer je kustomize gebruikt om met Overlays de lifecycle-fases van je applicatie te beheren dan ga je vroeger dan later een keer de vragen stellen hoe je promoties van images (en Bases) tussen deze fases kunt automatiseren. Met de hand references en image transformers doorzetten is meestal geen optie vanwege de kans op fouten, en het willen automatiseren van de promotie pipelines. Nu zijn er bestaande oplossingen met tools als Renovate die dit (gedeeltelijk) voor je kunnen oplossen, maar die hebben vaak wat meer infrastructuur nodig. Als je deze tools nog niet gebruikt dan zou je zelf wat scriptjes kunnen schrijven, maar nu heb je nog iets extras om te beheren en bij te houden.

Promotions Between Kustomizations

In a typical containerized application we have a lifecycle that goes a little like this: Developers push code to an application repository. A pipeline builds the latest code and pushes the resulting image to a registry The pipeline updates the images: transformer in a Kustomization Overlay for the dev environment with the new image by using a command like kustomize edit set image foobar=registry.example.com/foobar@sha256:deadbeef A tool like ArgoCD picks up the new image and starts a new deployment. This works well for the dev environment, but when that image needs to be promoted to a new environment like tst we either need to copy the updated image transformer manually, or try to read the updated version from the dev Kustomization. And images are not the only thing. A typical Kustomize Overlay will include a versioned Base with something like this: 1apiVersion: kustomize.config.k8s.io/v1beta1 2kind: Kustomization 3resources: 4- git.example.com/foobar.git/deploy/base?ref=v0.2.1 In this example we see that the Base that is being used comes from the Git tag or branch called v0.2.1. If a newer version of the application needs a newer Base a developer can update that reference in the dev Overlay, but promotions will need to be handled as well. Simply copying the kustomization.yaml file between Overlays will most likely not work, since different Overlays typically use different Replica transformers, different ConfigMap en Secret Generators etc. Read on to learn how you can automate this.