ArgoCD vs Flux: wanneer kies je wat

“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.

Maar dat ArgoCD voor mij wint, betekent niet dat het voor jou wint. Beide tools zijn CNCF graduated, beide zijn saai in de goede zin, en de keuze hangt bijna volledig af van je context. Laat me dus de criteria uitleggen waar het mij echt om gaat, beide tools langs elk criterium lopen, en dan vertellen waar elk past.

Waar ik op vergelijk

Een feature-checklist zou hier nutteloos zijn. Beide tools doen Helm, beide doen Kustomize, beide reconcilen Git naar clusters. Als ik alleen features opsom, leer je niks.

De dingen die het voor mij beslissen:

• Operating model - hoe de tool geïnstalleerd, geconfigureerd en geüpgraded wil worden
• Zichtbaarheid - wat je kunt zien wanneer er iets misgaat
• Faalgedrag - wat er gebeurt als de GitOps-engine zelf omvalt
• Multi-cluster vorm - hoe het schaalt van één cluster naar twintig

Deze sluiten direct aan op de waarden die de meeste van mijn infrastructuurkeuzes sturen. Begrijpen wat ik draai (zichtbaarheid), ontwerpen voor dingen die kapotgaan (faalgedrag), en operationele frictie laag houden (operating model) zijn geen abstracte voorkeuren. Ze bepalen welke tool ik om 2 uur ’s nachts kan verdragen.

De filosofie-splitsing

Voordat we bij de criteria komen, moet je begrijpen dat deze tools het oneens zijn over iets fundamenteels.

ArgoCD is applicatie-centrisch. Je definieert Applications die naar Git sources wijzen, en ArgoCD beheert ze via een centraal control plane dat met een UI komt. Dat control plane is iets wat je draait en onderhoudt.

Flux is GitOps-native tot op het bot. Het installeert een set controllers die Git repositories watchen, en het hele systeem, inclusief Flux’s eigen configuratie, leeft in Git. Er is geen centraal iets. Er is geen UI.

Deze splitsing is de wortel van bijna elk verschil dat volgt.

ArgoCD: de Application Controller

ArgoCD watcht Git repos en synct ze naar clusters. Wat je krijgt voor het draaien van een centraal control plane is zichtbaarheid en controle, op één plek, met een scherm waar je naar kunt wijzen.

flowchart TD
    subgraph argo["ArgoCD Architectuur"]
        subgraph control["ArgoCD Control Plane"]
            API["API Server"]
            UI["UI"]
            AppCtrl["Application Controller"]
        end
        control -->|"Watcht Git, Synct naar clusters"| clusters
        subgraph clusters["Beheerde Clusters"]
            C1["Cluster 1"]
            C2["Cluster 2"]
            C3["Cluster 3"]
        end
    end

Waar ArgoCD zich terugverdient

De UI is echt nuttig, en dat zeg ik niet zomaar. Ik ben een terminal-mens. Ik vermijd muizen. En toch, als een sync misgaat, is de ArgoCD resource tree die me precies laat zien welk object out of sync is, met de diff er meteen bij, sneller dan wat ik ook met kubectl in elkaar zou zetten. Voor iemand die nieuw is met GitOps doet het iets nog waardevollers: het maakt de link tussen een Git commit en cluster state zichtbaar, zodat het hele model op zijn plek valt.

De application-abstractie matcht hoe teams denken. Elke Application is een unit die je onafhankelijk synct, rollbackt of verwijdert. Dat mapt schoon op hoe mensen al over services redeneren, wat minder vertaalwerk in je hoofd betekent.

Multi-cluster is een hub-spoke verhaal. Eén ArgoCD-installatie beheert veel clusters. Voor een centraal platform team is dat een net model: één plek om te kijken, één plek om toegang te verlenen.

Het ecosysteem is rijk. Argo Rollouts voor progressive delivery, ApplicationSets voor het dynamisch genereren van Applications, Notifications voor alerting. Voor de meeste behoeften is er al een tool die inplugt.

Waar ArgoCD je kost

Het is een systeem dat je opereert. ArgoCD heeft zijn eigen state in Redis, vereist regelmatige upgrades, en kan ongelukkig worden op schaal. Je draait nu niet alleen je apps, je draait ook het ding dat je apps draait.

Het is standaard geen puur GitOps. ArgoCD’s eigen config leeft vaak in de UI of wordt met kubectl applied, in plaats van beheerd door ArgoCD zelf. Je kunt dat gat dichten met App-of-Apps, waarbij ArgoCD zijn eigen Applications vanuit Git beheert, maar dat is werk dat je bewust moet doen.

Het control plane is een single point of failure. Als ArgoCD down gaat, stopt syncing. Je clusters blijven verkeer serveren, de reconciliatie-engine is wat offline is, maar je kunt geen updates shippen tot het terugkomt.

Flux: de GitOps Toolkit

Flux benadert het probleem van de andere kant. Het is een set gefocuste controllers, elk verantwoordelijk voor één taak.

flowchart TD
    subgraph flux["Flux Architectuur"]
        subgraph git["Git Repository"]
            clusters["clusters/<br/>├── production/<br/>│   ├── flux-system/<br/>│   ├── infrastructure/<br/>│   └── apps/<br/>└── staging/"]
        end
        git -->|"Flux controllers"| cluster
        subgraph cluster["Elk Cluster"]
            Source["Source Controller"]
            Kustomize["Kustomize Controller"]
            Helm["Helm Controller"]
        end
    end

Waar Flux zich terugverdient

Puur GitOps vanaf het allereerste commando. flux bootstrap schrijft alle configuratie van Flux in Git. Daarna gaat alles via pull requests, inclusief Flux’s eigen upgrades. Er is geen out-of-band state die kan driften, want er is geen out-of-band iets. Als je een systeem wilt waar Git de enige source of truth is zonder voetnoten, is dit het.

Lichtere footprint. De controllers zijn klein en gefocust, je installeert alleen wat je nodig hebt, en het resource gebruik landt meestal onder ArgoCD. Op kleine of beperkte clusters is dat verschil reëel.

Geen centraal ding om te verliezen. Elk cluster draait zijn eigen Flux. De Flux van één cluster die omvalt raakt de anderen niet, want er is om te beginnen geen gedeeld control plane om te beschermen.

Het duwt je richting GitOps-discipline. Zonder UI om op te klikken is de weg van de minste weerstand een pull request. De tool haalt stilletjes de verleiding weg om een handmatige wijziging te maken, een feature vermomd als een afwezigheid.

Waar Flux je kost

Geen UI. Flux levert geen webinterface. Je werkt via kubectl, de flux CLI, of een third-party dashboard zoals Weave GitOps. Voor een terminal-native team is dat prima. Voor mensen die GitOps nog leren, is de ontbrekende zichtbaarheid een echte barrière, het spiegelbeeld van wat ArgoCD zo vriendelijk maakt voor nieuwkomers.

Steilere leercurve. Het modulaire ontwerp betekent meer CRDs om in je hoofd te houden: GitRepository, Kustomization, HelmRelease, HelmRepository. Die modulariteit is kracht, en het zijn ook meer concepten om te leren voordat er iets werkt.

Multi-cluster is meer werk. Flux draait per cluster. Twintig clusters betekent twintig Flux-installaties, en die coördineren vereist externe tooling. Het ding dat Flux resilient maakt (geen centraal plane) is hetzelfde ding dat fleet management moeilijker maakt.

Directe vergelijking

Het “het hangt ervan af” deel

Dit is het stuk dat de dingen daadwerkelijk beslist, en een tabel kan het niet vasthouden.

Grijp naar ArgoCD wanneer:

• Je een platform draait voor andere teams. De UI laat developers zien wat gedeployed is zonder diepe kubectl kennis. Self-service met guardrails, precies wat een platform team verkoopt.
• Je veel clusters vanuit één pane of glass wilt. Hub-spoke is simpeler voor gecentraliseerd beheer. ArgoCD op een management cluster, gericht op je workload clusters, is een schone vorm.
• Je team nieuw is met GitOps. De visuele feedback bouwt sneller intuïtie dan het lezen van reconciliatie-logs ooit zal doen.
• Je progressive delivery in de doos nodig hebt. Argo Rollouts integreert nauw, dus canary deployments met automatische analyse zijn geen apart project.

Grijp naar Flux wanneer:

• GitOps-puurheid het punt is. Als je alles in Git wilt zonder uitzonderingen en zonder handmatige ontsnappingsroute, maakt Flux dat de standaard in plaats van iets wat je moet afdwingen.
• Footprint telt. Edge deployments, kleine clusters, of een fleet groot genoeg dat ArgoCD’s overhead zich opstapelt tot reële kosten.
• Je een gedecentraliseerd model draait. Elk team bezit zijn cluster en zijn Flux, zonder centraal platform team in de loop.
• Je al in dat ecosysteem zit. Als Weave GitOps of vergelijkbare tools deel zijn van je wereld, is Flux de natuurlijke fit.

Er zijn ook hybrides. Sommige clubs draaien ArgoCD voor de developer-facing apps en Flux voor cluster bootstrap, zodat elke tool het deel doet waar het het best in is. Dat zijn meer bewegende delen, maar als de trade-offs zo voor je uitkomen, is het een echte optie en geen hack.

Mijn keuze

Ik koos ArgoCD, en terugkoppelend naar mijn criteria van bovenaan: ik waardeer de UI voor het begrijpen van state, hub-spoke past bij de multi-cluster vorm die ik daadwerkelijk draai, en de Application-abstractie matcht de manier waarop ik al over mijn workloads denk. Dat zijn persoonlijke redenen geworteld in mijn context, geen vonnis.

Draai een paar daarvan om en mijn antwoord draait mee. Als ik een enkel cluster draaide, met een team van ervaren Kubernetes-mensen die in de terminal leefden en Git als enige source of truth wilden zonder uitzonderingen, zou ik serieus Flux draaien. De case ervoor is sterk. Het is alleen niet mijn case.

Later wisselen

Als je er één kiest en wilt verhuizen, is het goede nieuws dat het dure deel overdraagt.

ArgoCD naar Flux: exporteer je Application-definities en converteer ze naar Flux Kustomizations en HelmReleases. De Git repos blijven staan.

Flux naar ArgoCD: maak van GitRepositories ArgoCD repo-connecties en van Kustomizations Applications. Opnieuw, de repos verhuizen niet.

Omdat Git in beide de source of truth is, is het harde werk (je manifests verstandig organiseren) het deel dat je houdt. De tool die erbovenop zit is het goedkope deel om te wisselen.

Denk er niet te lang over na

Dit is wat ik mensen vertel die vragen:

1. Probeer beide op een wegwerpcluster. Een dag met elk vertelt je meer dan een week lezen van vergelijkingen zoals deze.
2. Let op welke goed voelt. GitOps is een workflow voordat het een tool is. Kies degene die matcht met hoe je team al werkt.
3. Begin simpel. Beide tools dekken de gangbare 90% out of the box.
4. Onthoud dat je kunt wisselen. Je investering leeft in je Git repos, dus de tool is geen lock-in.

De principes zijn wat gewicht dragen: declaratief, versioned, reconciled. ArgoCD en Flux zijn twee manieren om hetzelfde idee te eren. De beste is degene die je team daadwerkelijk gebruikt, elke dag, zonder mopperen. Perfecte GitOps met een tool die niemand opent verslaat beide als ze stof staan te verzamelen.