Argo CD-architectuur: hoe de sync loop werkt
Argo CD is de populairste GitOps-operator voor Kubernetes. Deze onderdelen werken samen om jouw Git-repository automatisch naar het cluster te vertalen.
Argo CD is een concrete implementatie van het GitOps-principe. Het bestaat uit een paar op zichzelf staande componenten die samen de sync-loop vormen.
De kerncomponenten
- API server — de laag waarmee de UI, CLI en externe systemen praten. Regelt ook authenticatie en autorisatie (RBAC).
- Repo server — haalt de manifests op uit Git en rendert ze indien nodig (bijvoorbeeld door een Helm-chart of Kustomize-overlay om te zetten naar platte Kubernetes-YAML).
- Application controller — de motor van Argo CD. Vergelijkt continu de gerenderde manifests (gewenste staat) met wat er echt in het cluster staat (live staat), en berekent het verschil.
- Redis — caching-laag om herhaalde berekeningen te versnellen.
Het Application-object
In Argo CD beschrijf je elke te beheren applicatie als een Application custom resource: welke Git-repo, welk pad/branch, en naar welk cluster/namespace het gedeployed moet worden. Dit object is zelf ook gewoon een Kubernetes-resource.
Sync: automatisch of handmatig
Standaard kun je kiezen tussen automatische sync (elke wijziging in Git wordt direct doorgevoerd) en handmatige sync (een engineer keurt de wijziging eerst goed in de UI). Bij drift-detectie toont Argo CD de status OutOfSync, met een diff tussen gewenst en werkelijk.
Examentip: Onthoud het verschil tussen Sync Status (komt de staat overeen met Git?) en Health Status (draaien de resources daadwerkelijk gezond?) — dit zijn twee losse concepten die vaak door elkaar gehaald worden.