Zoals je tools als k9s kunt gebruiken om je Kubernetes cluster vanuit de terminal te beheren met een TUI, zo is er tegenwoordig ook argo9s om hetzelfde te doen met je ArgoCD instanties.

ArgoCD Applications hebben een optionele Finalizer die gezet kan worden waardoor ArgoCD alle resources van een Application verwijderd als de Application zelf wordt verwijderd. Standaard wordt deze niet gezet, maar…

Wanneer een Application wordt aangemaakt vanuit een ApplicationSet wordt deze Finalizer standaard wel gezet.

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.

Met ArgoCD kun je op meerdere manieren een groep van (verwante) applicaties beheren. Een klassieke methode is met het zogenaamde “App-of-Apps” patroon. Één applicatie die andere applicaties aanmaakt binnen ArgoCD. Dit kan in sommige gevallen handig zijn, maar soms wil je wat meer automatisering en wat minder handwerk. In die gevallen kan een ArgoCD “ApplicationSet” nuttig zijn: Een ArgoCD objectr dat automagisch aan de hand van een lijst van “generators” applicaties opbouwt.

Argo Rollouts op OpenShift

Met Argo Rollouts kun je Deployment objecten vervangen door Rollout objecten die meer controle geven over hoe updates aan een Deployment uitgerold worden. Langzaam aan met Canaries, atomisch met Green-Blue changeover, en meer. Dit alles kan automatisch gebeuren, met handmatige promotie stappen, combinaties daarvan, en zelfs met probes die kijken of een nieuwe versie goed werkt.

Als je een applicatie die via Hem charts wordt gedistribueerd in je OpenShift GitOps (ArgoCD) wilt opnemen heb je twee opties:

1. Een ArgoCD applicatie van het type “Helm” maken
2. De Helm chart via kustomize laten renderen, en de kustomization.yaml in je ArgoCD opnemen.

De eerste oplossing is het makkelijkst, en heeft weinig extra configuratie nodig. Het nadeel is wel dat je wat betreft aanpassingen gelimiteerd bent op wat de schrijver van de chart via de values.yaml heeft aangeboden.

Wanneer je extra aanpassingen nodig hebt kom je dus al snel uit op de tweede methode: De helm chart via kustomize laten renderen (inclusief aanpassingen via values.yaml), en daar extra aanpassingen op doen via de bekende kustomize transformers zoals images:, patches:, replicas:, etc.

In een vorige video hebben we gekeken hoe je namespaces kunt beheren met behulp van GitOps methodologieën. Deze week gaan we hierop verder bouwen en gaan we ook (Cluster)ResourceQuotas introduceren.

In het verleden hebben we op dit kanaal al vaker gekeken naar het managen van namespaces voor applicatie-teams op Kubernetes en OpenShift clusters. Deze keer kijken we naar hetzelfde probleem, maar pakken we het op een GitOps methode aan.