GitOps in 2026: reconciliatie, drift en de keuze tussen Argo CD en Flux

GitOps hield ergens rond 2023 op een discussiepunt te zijn. In de GitOps-microsurvey van de CNCF draaide 60% van de respondenten het al langer dan een jaar en was nog eens 31% de voorgaande twaalf maanden begonnen, wat de adoptie boven de 90% brengt onder cloud-native professionals (CNCF, 2023). Beide referentie-implementaties, Argo CD en Flux, bereikten eind 2022 de status "graduated" binnen de CNCF, de hoogste volwassenheidstier die de foundation toekent (CNCF, 2025). De interessante vraag voor een senior engineer in 2026 is dus niet langer "moeten we GitOps doen", maar "waar committeren we ons precies aan, en op welke engine draaien we het". Dit stuk beantwoordt beide, met de audit- en driftinvalshoeken die ertoe doen voor gereguleerde Benelux-teams.

Pijplijndiagram van een GitOps-leverstroom: broncode, build en geautomatiseerde tests voeden een Git-repository die een agent in het cluster continu reconcilieert tegen de live Kubernetes-staat

Wat is GitOps precies?

GitOps is niet "Git gebruiken voor infrastructuur", wat de meeste teams al doen. Het is een specifiek operationeel model met vier principes, geformaliseerd door de CNCF-gestuurde werkgroep OpenGitOps (OpenGitOps, v1.0.0). Een systeem doet alleen GitOps als alle vier gelden:

Declaratief. De gewenste staat van het hele systeem wordt uitgedrukt als data, niet als scripts. Je beschrijft wat er moet bestaan, niet de stappen om het te maken.
Geversioneerd en onveranderlijk. Die gewenste staat wordt zo opgeslagen dat hij onveranderlijk is, volledig geversioneerd, en een complete historie bewaart. In de praktijk is dat een Git-repository, waar de naam vandaan komt, maar het principe is de versieopslag, niet de tool.
Automatisch opgehaald. Software-agents halen de gewenste staat zelf op uit de bron. Niemand draait kubectl apply vanaf een laptop, en het CI-systeem pusht niet naar productie.
Continu gereconcilieerd. Agents observeren continu de daadwerkelijke draaiende staat en werken eraan die gelijk te maken aan de gedeclareerde staat.

De laatste twee onderscheiden GitOps van een goed opgezette CI/CD-pijplijn. In een klassieke push-pijplijn authenticeert een job zich naar het cluster en past een wijziging eenmalig toe; daarna heeft de pijplijn geen mening meer over wat er met het cluster gebeurt. Bij GitOps haalt een agent die in het cluster leeft de repository op en blijft die afdwingen. Die omkering, van push naar pull en van eenmalig naar continu, is de hele kern.

Drift, reconciliatie en zelfherstel

Het probleem dat GitOps moet uitroeien is configuratiedrift: het langzaam uiteenlopen van wat je denkt dat draait en wat er werkelijk draait, veroorzaakt door een handmatige hotfix tijdens een incident, een mislukte gedeeltelijke deploy, een mutatie door de autoscaler, of een goedbedoelende engineer met clustertoegang en een deadline. Drift is verraderlijk juist omdat het onzichtbaar blijft tot de volgende deploy faalt om redenen die niemand kan verklaren, of tot een audit je vraagt de draaiende configuratie te bewijzen en dat niet lukt.

Continue reconciliatie is het tegengif. De agent in het cluster vergelijkt de live staat met de gedeclareerde staat in een lus en corrigeert bij afwijking automatisch, of markeert het als niet-gesynchroniseerd. Verwijder handmatig een resource waarvan Git zegt dat hij moet bestaan en de agent maakt hem opnieuw aan. Bewerk een draaiende config met de hand en de agent zet hem terug naar wat de repository declareert. Die gesloten lus geeft GitOps zijn reputatie van zelfherstel, en het is waarom de reconciliatie-engine, niet de Git-repository, het onderdeel is dat zijn waarde echt verdient. Git is slechts de bron van waarheid; de controller is de afdwinging.

GitOps versus Infrastructure as Code en CI/CD

Deze drie overlappen genoeg om echte verwarring te veroorzaken, dus het loont de lijnen te trekken. Infrastructure as Code is de praktijk van resources declareren in bestanden; een Terraform- of OpenTofu-plan beschrijft wat er moet bestaan. IaC zegt niets over wie het toepast of hoe vaak. CI/CD is de automatisering die commits omzet in artefacten en die ergens naartoe pusht. GitOps is een opiniërende manier om die twee aan elkaar te knopen voor de runtime: declaratieve definities (het IaC-deel), opgeslagen in versiebeheer, opgehaald en continu gereconcilieerd door een agent (het operationele-model-deel).

Concreet: je kunt prachtige Terraform schrijven en toch geen GitOps doen, als een mens terraform apply vanaf zijn machine draait en er daarna niets op drift let. GitOps is minder een nieuwe technologie dan een discipline bovenop IaC en CI, die het toepassen van wijzigingen weghaalt uit imperatieve pijplijnen en in een pull-gebaseerde regellus plaatst. Voor de bredere redenering rond declaratieve infrastructuur en drift behandelt ons stuk over Infrastructure as Code in 2026 de policy- en Terraform-versus-OpenTofu-kant.

Argo CD versus Flux: welke GitOps-engine?

Beide zijn CNCF graduated, beide zijn bewezen in productie, en de keuze ertussen is vooral een kwestie van teamvorm dan van functionaliteit. De markt heeft een duidelijke koploper: de CNCF end-user-survey van 2025 vond dat bijna 60% van de Kubernetes-clusters die respondenten beheren op Argo CD draait, met 97% van de gebruikers die het in productie draaien (op van 93% in 2023) en een Net Promoter Score van 79 (CNCF, 2025).

Het praktische onderscheid:

Argo CD komt als een opiniërend platform voor applicatielevering met een sterke ingebouwde web-UI. Het dashboard, de visuele diff tussen gewenste en live staat, en het applicatiegerichte model maken het de makkelijkere keuze voor teams die reliability engineers en developers naar hetzelfde scherm willen laten kijken. Die zichtbaarheid verklaart een groot deel van zijn dominantie in de cijfers.
Flux komt als een modulaire toolkit van Kubernetes-controllers die je zelf samenstelt. Er is bewust geen meegeleverde UI. Bouw je een platform en wil je GitOps ingebed als een set primitieven die je assembleert en waartegen je automatiseert, dan past het Lego-model van Flux vaak beter, en meerdere managed cloudplatforms hebben het onder de motorkap ingebed.

Een bruikbare vuistregel: kies Argo CD wanneer het publiek voor GitOps mensen omvat die de staat moeten zien, en Flux wanneer het publiek vooral andere automatisering is. Geen van beide is een fout, en beide zijn saai in de goede zin. Laat het tooldebat niet de energie opslokken die thuishoort bij repositorystructuur en toegangsbeheer, want daar slagen of falen GitOps-implementaties werkelijk.

Waarom gereguleerde teams erom geven: audit en toegang

Voor teams onder DORA, financieel toezicht, of enig regime dat vraagt "wie wijzigde wat, wanneer, en wie keurde het goed", is GitOps minder een productiviteitsverhaal dan een compliancekwestie. Omdat elke wijziging aan productie een versiebeheerde commit is, erf je gratis een audittrail: auteur, tijdstempel, reviewer en diff, voor elke mutatie, zonder een apart change-managementsysteem erbij te bouwen. Dezelfde professionals in de CNCF-survey rangschikten de beveiligingsvoordelen navenant - 69% noemde het vervangen van handmatige processen door automatisering als de grootste beveiligingswinst, 62% waardeerde het afschermen van live productie tegen directe menselijke toegang, en 60% wees op snel herstel en rollback (CNCF, 2023).

Die eigenschap van "geen directe toegang" is de ondergewaardeerde. Wanneer het enige gesanctioneerde pad naar productie een gemergede pull request is die een agent vervolgens toepast, kun je permanente menselijke schrijftoegang tot het cluster volledig verwijderen. Break-glass-toegang wordt een uitzondering die je logt en reviewt, niet de dagelijkse norm. Voor een auditor is "productie kan alleen worden gewijzigd via gereviewde Git-commits, afgedwongen door een controller zonder interactieve menselijke credentials" een veel sterkere controlebewering dan "we hebben een goedkeuringsproces dat mensen geacht worden te volgen".

Waar GitOps lastig wordt

Twee faalmodi zijn het waard vooraf te benoemen. Ten eerste secrets: je kunt geen credentials in platte tekst committen naar de repository die nu je bron van waarheid is, dus GitOps dwingt een echte secrets-strategie af (sealed secrets, een external secrets operator, of een vault-integratie) in plaats van je toe te staan die uit te stellen. Ten tweede vaardigheden: dezelfde CNCF-survey vond dat bijna 70% van de respondenten geen GitOps-training had gedaan en dat ook niet van plan was, wat zich later uit in reconciliatielussen die niemand volledig begrijpt en driftmeldingen die niemand oppakt. GitOps verplaatst het operationele model, en een team dat de tool adopteert zonder de discipline te adopteren krijgt een controller die stilletjes hun handmatige fixes terugdraait en geen gedeeld mentaal model van waarom.

Niets hiervan pleit tegen GitOps; het pleit ervoor het te behandelen als een verandering van het operationele model met een echte uitrol, niet als een tool-installatie op een vrijdagmiddag. Goed gedaan is de opbrengst voor een gereguleerd team op schaal precies de combinatie die ze elders moeilijk kunnen kopen: een systeem dat zichzelf herstelt richting een bekende goede staat, een audittrail die gratis meekomt, en een productieomgeving die geen mens stilletjes kan aanraken.