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.
Belangrijkste punten
- GitOps is een specifiek operationeel model en niet alleen Git voor infrastructuur: een systeem doet pas GitOps als alle vier de OpenGitOps-principes gelden, van declaratieve staat tot continue reconciliatie.
- Continue reconciliatie is wat configuratiedrift uitroeit, dus de controller in het cluster, niet de Git-repository, is het onderdeel dat zijn waarde echt verdient.
- Infrastructure as Code declareert wat er moet bestaan; GitOps voegt een pull-gebaseerde regellus toe die het toepast en op drift let.
- Argo CD en Flux zijn allebei CNCF graduated: kies Argo CD als mensen de staat moeten zien en Flux als het publiek vooral andere automatisering is.
- Voor gereguleerde teams levert GitOps een gratis audittrail en een productieomgeving zonder permanente menselijke schrijftoegang, mits je het uitrolt als een verandering van het operationele model, met een echte secrets-strategie en getrainde mensen.
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 applyvanaf 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
- 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
- De automatisering die commits omzet in artefacten en die ergens naartoe pusht.
- GitOps
- 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).
Terraform alleen is nog geen GitOps
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:
| Aspect | Argo CD | Flux |
|---|---|---|
| Komt als | Een opiniërend platform voor applicatielevering, met een applicatiegericht model. | Een modulaire toolkit van Kubernetes-controllers die je zelf samenstelt, volgens het Lego-model. |
| Web-UI | Een sterke ingebouwde web-UI, met een dashboard en een visuele diff tussen gewenste en live staat. | Er is bewust geen meegeleverde UI. |
| Past het best bij | De makkelijkere keuze voor teams die reliability engineers en developers naar hetzelfde scherm willen laten kijken. | Bouw je een platform en wil je GitOps ingebed als een set primitieven die je assembleert en waartegen je automatiseert, dan past Flux vaak beter. |
| Adoptie | Die zichtbaarheid verklaart een groot deel van zijn dominantie in de cijfers. | 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.
Steek de energie in structuur en toegang
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 (CNCF, 2023):
69%
noemde het vervangen van handmatige processen door automatisering als de grootste beveiligingswinst
62%
waardeerde het afschermen van live productie tegen directe menselijke toegang
60%
wees op snel herstel en rollback
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.
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.
Bronnen
- CNCF End User Survey Finds Argo CD as Majority Adopted GitOps Solution for Kubernetes - Cloud Native Computing Foundation, 24 juli 2025
- CNCF GitOps Microsurvey: Learning on the Job as GitOps Goes Mainstream - Cloud Native Computing Foundation, 7 november 2023
- OpenGitOps Principles (v1.0.0) - OpenGitOps / CNCF GitOps Working Group
- GitOps in 2025: From Old-School Updates to the Modern Way - Cloud Native Computing Foundation, 9 juni 2025
