ArgoCD in production on Tom Meurs

ArgoCD voor beginners: je eerste GitOps deployment

Sun, 16 Mar 2025 19:15:00 +0100

Dit wil ik nooit meer doen: een cluster vragen wat het draait en het antwoord niet vertrouwen. Jarenlang was dat normaal. Iemand draaide kubectl apply, misschien vanaf een laptop, misschien vanuit een CI-job die niemand meer kon vinden, en de live staat dreef langzaam weg van alles wat ergens opgeschreven stond. Toen ik op GitOps overstapte, verdween die hele categorie onzekerheid. Ik push naar Git, en het cluster convergeert tot het matcht. Wil ik weten wat gedeployed is, dan lees ik een bestand.

ArgoCD vs Flux: wanneer kies je wat

Fri, 28 Mar 2025 21:33:00 +0200

“Moet ik ArgoCD of Flux gebruiken?”

Ik krijg deze vraag bij de koffie, in Slack, in PR-comments, waarschijnlijk een keer per week. Mensen willen dat ik een winnaar aanwijs zodat ze er niet meer over hoeven na te denken en gewoon iets kunnen bouwen.

Hier is mijn bias, vooraf, zodat je alles wat volgt kunt wegen: ik draai ArgoCD op mijn eigen clusters. Ik heb er een paar jaar mee onder de gordel en ik vind het prettig. Die voorkeur lekt overal doorheen hoe voorzichtig ik ook ben, dus ik zeg het nu maar in plaats van te doen alsof ik neutraal ben.

App-of-Apps pattern in ArgoCD: schaalbare GitOps architectuur

Mon, 21 Apr 2025 20:18:00 +0200

Mijn homelab begon met één ArgoCD Application. Daarna een handvol. Toen ik mezelf voor de vijftiende keer kubectl apply -f zag draaien om weer een Application te registreren, wist ik dat ik precies had gebouwd wat ik wilde vermijden: handmatige stappen die ik moest onthouden, in een volgorde die ik moest onthouden, zonder enige administratie van wat er zou moeten bestaan.

Het App-of-Apps pattern lost dat op met één idee. Je maakt met de hand een enkele root Application, en die maakt de rest aan. Na een gewist cluster bouw ik het geheel terug met één kubectl apply. Die eigenschap is de hele reden dat ik het draai, en het is dezelfde reden dat ik überhaupt self-host: ik wil dat de repository de waarheid is, niet mijn geheugen.

Drift detection met ArgoCD: hoe weet je of je cluster nog in sync is

Sat, 03 May 2025 19:27:00 +0200

De hele belofte van GitOps is dat Git de source of truth is. Die belofte houdt stand tot het moment dat iemand om 2 uur ’s nachts kubectl edit runt op een deployment om een incident te stoppen, een mutating webhook stilletjes een resource herschrijft, of een half afgemaakte sync je cluster ergens tussen wat Git wilde en wat het kreeg achterlaat. Nu zegt Git het ene en doet het cluster het andere, en niemand heeft het je verteld.

Progressive delivery met Argo Rollouts: canary en blue-green deployments

Fri, 20 Jun 2025 10:00:00 +0200

Een standaard Kubernetes Deployment heeft me lang prima gediend. Push een nieuwe image tag, kijk hoe de pods rollen, klaar. Simpel, declaratief, en meestal ging er niks mis. De rolling update gaf me zelfs een warm gevoel van veiligheid: oude pods verdwijnen pas als de nieuwe ready zijn.

Dat gevoel is een leugen. Een rolling update beschermt je tegen pods die niet opstarten. Hij doet niks tegen pods die perfect opstarten en vervolgens kapotte responses serveren. De container is gezond, de readiness probe is groen, en je nieuwe code stuurt stilletjes 500’s naar elke gebruiker. Binnen seconden raakt 100% van je traffic code die niemand onder echte load heeft gevalideerd.

GitOps disaster recovery: je cluster herstellen vanuit Git

Wed, 09 Apr 2025 19:52:00 +0200

Een paar jaar lang draaide mijn homelab cluster zonder veel drama. Nodes kwamen en gingen, workloads schoven rond, en het ergste waar ik mee te maken kreeg was af en toe een pod die vastzat in CrashLoopBackOff. Het soort stabiliteit waarbij je stopt met nadenken over wat er gebeurt als het allemaal verdwijnt.

Toen runde ik op een avond een terraform destroy tegen de verkeerde workspace. Tegen de tijd dat ik het doorhad, was de control plane weg. Niet degraded. Weg.