Themagids
Wat is GitOps? De reconciliatielus uitgelegd
GitOps legt de gewenste staat van een systeem vast in Git en laat de deploy over aan een agent. De agent haalt die staat op, vergelijkt hem met wat er draait, past het verschil toe en meldt drift terug. Alles op deze pagina volgt uit die lus.
- Ophalen De agent haalt de nieuwste commit op, met een timer of via een webhook.
- Vergelijken Hij maakt een diff tussen die gewenste staat en het draaiende systeem.
- Toepassen Hij wijzigt wat afwijkt, of markeert het alleen als hij niet mag ingrijpen.
- Rapporteren Syncstatus, health en drift gaan terug naar de mensen die er eigenaar van zijn.
De regels achter de lus
Wat zijn de vier principes van GitOps?
OpenGitOps, dat onder toezicht staat van een CNCF-werkgroep, legt GitOps vast in vier principes (v1.0.0). Alle vier moeten gelden. Een pipeline die manifests uit Git toepast, voldoet aan hooguit twee daarvan.
-
01
Declaratief
“A system managed by GitOps must have its desired state expressed declaratively.”
In de praktijkManifests beschrijven wat er moet bestaan, niet hoe u het maakt. Een deploy-script in Git is geen declaratie.
-
02
Geversioneerd en onveranderlijk
“Desired state is stored in a way that enforces immutability, versioning and retains a complete version history.”
In de praktijkBeschermde branches, geen force pushes, en verwijzingen vastgepind op een tag of commit, nooit op een branch die meebeweegt.
-
03
Automatisch opgehaald
“Software agents automatically pull the desired state declarations from the source.”
In de praktijkNiemand past wijzigingen toe vanaf een laptop, en CI heeft geen credentials voor productie.
-
04
Continu gereconcilieerd
“Software agents continuously observe actual system state and attempt to apply the desired state.”
In de praktijkDe agent blijft na de deploy vergelijken. Continu betekent dat het vergelijken doorgaat, niet dat het direct gebeurt.
Stap 1 van de lus: ophalen
Wat is het verschil tussen GitOps en CI/CD?
Uw CI-pipeline blijft bestaan: die bouwt, test en publiceert nog steeds artifacts. GitOps verandert wie er deployt. Een push-pipeline eindigt met een deploy-job; een GitOps-pipeline eindigt met een commit, en de agent deployt. Volgens de begrippenlijst van OpenGitOps wordt traditionele CI/CD aangestuurd door vooraf ingestelde triggers, terwijl reconciliatie start zodra er een afwijking ontstaat.
| Aspect | Push-gebaseerde CI/CD | Pull-gebaseerde GitOps |
|---|---|---|
| Wie deployt | Een pipelinejob | Een agent in of naast de doelomgeving |
| Wat een deploy start | Een merge, een schema of een knop | Elk verschil tussen Git en het draaiende systeem |
| Credentials | CI kan naar elke doelomgeving schrijven | CI schrijft alleen naar Git; de agent heeft toegang tot de doelomgeving |
| Na de deploy | De job stopt; latere wijzigingen blijven onopgemerkt | De agent blijft vergelijken en meldt drift of draait die terug |
| Rollback | Een oudere pipeline opnieuw draaien | De commit terugdraaien; de agent past dat toe |
| Audittrail | Pipelinelogs | Git-historie: auteur, review en diff |
| Past het best bij | Alles met een API of SSH, en werk met een vaste volgorde | Declaratieve doelomgevingen die een agent kan observeren, meestal Kubernetes |
Waar CI het stokje overdraagt
- CIBouwt, test en publiceert de image
- GitKrijgt een commit met de nieuwe tag, of een pull request
- AgentHaalt op, vergelijkt en past toe
De documentatie van Argo CD beschrijft deze overdracht, en Flux kan de commit zelf maken zodra er een nieuwe image verschijnt.
Waar de lus draait
Is GitOps alleen voor Kubernetes?
De principes niet: de begrippenlijst accepteert elke state store die aan de criteria voldoet, niet alleen Git. De gangbare agents wel. Argo CD en Flux zijn gebouwd voor Kubernetes, dat zelf al met regellussen werkt. Daarbuiten leent u de principes en neemt u genoegen met een zwakkere lus.
Past goed
- Kubernetes, met meer dan één cluster of omgeving
- Draai een agent zoals Argo CD of Flux. Begin met één service.
- Productie wordt met de hand aangepast
- De agent toont elk verschil voordat u hem iets laat terugdraaien.
Leen de principes
- Cloudresources in Terraform of OpenTofu
- Draai de apply vanuit een pipeline en laat volgens een schema een plan lopen met
-detailed-exitcode(Terraform, OpenTofu). Exitcode 2 betekent wijzigingen: drift, of code die niemand heeft toegepast. - Servers die met Ansible worden beheerd
- ansible-pull draait de standaard push-architectuur van Ansible om naar een pull-architectuur.
Gebruik een pipeline
- Werk dat een vaste volgorde vraagt of eenmalig is: upgrades van een hele vloot, datacorrecties, app store-releases
- Een reconciler houdt een staat in stand; een pipeline voert een reeks stappen uit. Toch kunnen agents stappen in volgorde zetten, met sync hooks in Argo CD of afhankelijkheden in Flux.
- Eén service, één omgeving, een klein team
- Nog een controller om te draaien en te beveiligen kan meer kosten dan de drift die hij voorkomt.
Uit een echte opdrachtBij Nike bracht es.nl de Windows-serverupgrades voor 900+ winkels, waar meerdere teams aan te pas kwamen, samen in één self-service pipeline. De doorlooptijd per server daalde van 6-8 uur naar ongeveer 3, met 8 servers veilig parallel in plaats van 2. Een lange procedure in kleine batches leent zich goed voor pipelinefasen. Lees de Nike-case
Stap 2 en 3: vergelijken en toepassen
Argo CD of Flux: welke GitOps-tool past bij u?
Beide hebben bij de CNCF de status graduated, Argo sinds december 2022 en Flux sinds november 2022, en beide draaien de lus hierboven. Hun standaardgedrag verschilt.
Argo CD
- Wat het is
- Een declaratieve GitOps-tool voor continuous delivery op Kubernetes, met een webinterface.
- Wanneer het synchroniseert
- Op verzoek, tenzij automated sync aanstaat. Argo CD controleert Git standaard minstens eens per 3 minuten, of bij een webhook.
- Drift
- Zichtbaar als OutOfSync. Een live wijziging op zich start alleen een sync als self-heal aanstaat.
- Verwijderde manifests
- Automated sync laat de bijbehorende resources als veiligheidsmaatregel draaien, totdat u pruning aanzet.
- Inzicht in de staat
- Een webinterface die drift zichtbaar maakt, plus audittrails.
Flux
- Wat het is
- Controllers die Kubernetes-clusters in sync houden. Gebruikersinterfaces zijn aparte projecten.
- Wanneer het synchroniseert
- Elke Kustomization reconcilieert op een eigen interval: ophalen, bouwen, toepassen.
- Drift
- Kustomizations corrigeren drift bij elk interval. Voor Helm-releases zet u driftdetectie zelf aan, in een waarschuwende of corrigerende modus.
- Verwijderde manifests
- Pruning is op elke Kustomization een verplichte keuze: ja of nee.
- Inzicht in de staat
- Meldingen naar Slack en vergelijkbare tools wanneer de configuratie gesynchroniseerd en gereed is.
Het es.nl-artikel GitOps in 2026: reconciliatie, drift en de keuze tussen Argo CD en Flux geeft een vuistregel: Argo CD wanneer mensen de staat moeten zien, Flux wanneer het publiek andere automatisering is.
Andere GitOps-tools
Argo CD en Flux zijn niet de enige manieren om de lus te draaien. Vier andere tools komt u tegen:
- Fleet (Rancher) Kubernetes-custom resources en controllers die GitOps draaien voor één cluster of een grote vloot clusters, vanuit gewone YAML, Helm-charts of Kustomize.
- Red Hat OpenShift GitOps Een Operator gebaseerd op Argo CD, voor OpenShift- en Kubernetes-clusters.
- GitLab De agent voor Kubernetes werkt met Flux, en de documentatie van GitLab raadt aan beide te gebruiken voor GitOps-deployments.
- Kargo Een promotielaag die Argo CD aanvult, om een wijziging in volgorde door uw omgevingen te brengen.
Drie van de vier draaien op Argo CD of Flux, dus de keuze tussen die twee komt meestal eerst.
De gewenste staat
Hoe richt u een GitOps-repository in?
De structuur bepaalt wie wat kan wijzigen, en hoe een wijziging in productie terechtkomt. Vier beslissingen komen eerst.
fleet-config/
├── apps/
│ ├── base/ # shared
│ ├── staging/ # overrides
│ └── production/ # overrides
├── infrastructure/ # ingress, policy
└── clusters/
├── staging/ # entry point
└── production/ # entry pointHoud configuratie apart van de broncode
De best practices van Argo CD raden een aparte repository voor manifests sterk aan: een schonere audithistorie, aparte toegang tot productie, en geen CI-commit die een eindeloze reeks buildjobs in gang zet.
Gebruik mappen voor omgevingen, geen branches
In het voorbeeld van Flux voor een monorepo staan alle omgevingen in dezelfde branch, bijvoorbeeld main. Promotie is een pull request op de productiemap, en het verschil tussen omgevingen is een diff die iedereen kan lezen.
Splits repositories naar toegangsrechten
Een monorepo is het eenvoudigst. Met een aparte productierepository kunt u toegang geven aan een deel van het team.
Pin vast waarnaar u verwijst
Een base of chart die een branch volgt, kan van de ene op de andere dag iets anders betekenen. Pin in plaats daarvan een Git-tag of commit-SHA.
Stap 3 en 4: toepassen en rapporteren
Hoe werken rollback en drift in GitOps?
Rollback is een revert
Draai de wijziging in Git terug en de agent past de vorige staat toe. De revert wordt gereviewd en vastgelegd zoals elke andere wijziging.
git switch -c rollback-4c2e9f1
git revert --no-edit 4c2e9f1
git push -u origin rollback-4c2e9f1
# merge the pull request, and the
# agent applies the previous stateTwee beperkingen. De eigen rollback van Argo CD werkt niet bij een applicatie waarop automated sync aanstaat, omdat de lus de app dan weer gelijk zou trekken met Git. En een revert herstelt configuratie, geen data: de gewenste staat bevat doorgaans geen persistente applicatiedata. Over rollback op basis van metrics leest u meer in Progressive Delivery in 2026: canary vs blue-green vs feature flags.
Drift: melden of terugdraaien
Drift is elk verschil tussen Git en het draaiende systeem. Bepaal per app wat de agent ermee doet: melden of terugdraaien. Argo CD meldt standaard, terwijl Flux-Kustomizations drift bij elk interval corrigeren.
Dat verandert hoe u incidenten aanpakt. Herstelt u iets met de hand terwijl de agent draait, dan kan de lus uw hotfix terugdraaien. Pauzeer eerst de agent voor die app (Flux heeft suspend; Argo CD kan zonder automated sync draaien), commit daarna de fix en hervat de agent.
Wat er in de eerste maanden misgaat
| Symptoom | Waarschijnlijke oorzaak | Oplossing |
|---|---|---|
| Een hotfix verdwijnt na een incident | De agent heeft een handmatige wijziging teruggedraaid | Pauzeer de agent, herstel, commit dezelfde wijziging, hervat |
| Een app staat nooit in sync | Een autoscaler of andere controller wijzigt een veld dat Git ook zet | Laat dat veld weg uit Git, zoals de richtlijnen van Argo CD aanraden voor replica's |
| Een verwijderd manifest laat zijn resource draaien | Pruning staat uit | Zet pruning aan, app voor app |
| Driftmeldingen stapelen zich ongelezen op | Niemand is er eigenaar van | Stuur elke melding als defect naar het team dat eigenaar is |
Secrets in de gewenste staat
Hoe beheert u secrets in GitOps?
De gewenste staat bevat vaak wel credentials, merkt de begrippenlijst van OpenGitOps op, en als platte tekst kunnen die niet in de repository. Drie patronen verschillen in hoeveel geheim materiaal er in Git staat.
-
Versleuteld in Git
- Git bevat
- Versleutelde waarden, geversioneerd met de rest.
- Bij het toepassen
- Een controller ontsleutelt ze. Flux ontsleutelt SOPS-bestanden met sleutels van age, OpenPGP of een cloud-KMS.
- Let op
- De sleutel. Wie die heeft, kan de hele historie lezen.
-
Verwijzing naar een secret store
- Git bevat
- Een verwijzing, nooit de waarde.
- Bij het toepassen
- Een operator zoals External Secrets Operator haalt de waarde op uit een vault of uit de secret manager van een cloud.
- Let op
- Rotatie en audit verhuizen naar de store, buiten Git.
-
Geen permanent secret
- Git bevat
- Niets geheims.
- Bij het toepassen
- De workload bewijst zijn identiteit en krijgt kortlevende credentials.
- Let op
- Dit vereist een provider die identity federation ondersteunt.
Twee aandachtspunten. Injecteer geen secrets terwijl de manifests worden gegenereerd: Argo CD slaat gegenereerde manifests als platte tekst op in zijn Redis-cache, waarschuwt de documentatie. En een Kubernetes Secret wordt standaard onversleuteld opgeslagen in etcd, dus vraagt de Kubernetes-documentatie om encryptie at rest en toegang met minimale rechten. Meer hierover leest u in Secrets Management in 2026: Sprawl, Non-Human Identities en de Keuze tussen Vault en Workload Identity.
Uw eerste lus
Hoe begint u met GitOps?
Waar uw team staat
Het onderzoek van DORA toont aan dat uitgebreid gebruik van versiebeheer continuous delivery voorspelt. Vijf vragen laten zien hoe dicht u erbij bent.
- Kunt u een cluster opnieuw opbouwen met alleen de repository?
- Begint elke deploy bij een commit, of beginnen sommige in een terminal?
- Wie kan productie vandaag met de hand wijzigen?
- Staan er al geen secrets meer in uw repositories?
- Als iemand productie met de hand wijzigt, hoe lang duurt het voordat u dat weet?
Een eerste uitrol in vijf stappen
Eén service, één cluster
Een service die ertoe doet maar niet kritiek is, in een niet-productiecluster.
Eerst kijken, dan afdwingen
Draai Argo CD zonder automated sync, of bekijk vooraf wat Flux zou doen met
flux diff kustomization. Zet elk verschil op een rij.Zorg dat Git klopt
Zet elk verschil in Git of verwijder het, tot de app in sync staat.
Zet de lus aan
Zet eerst automatische sync en driftcorrectie aan. Voeg pruning als laatste toe.
Haal handmatige toegang weg
Trek permanente schrijftoegang tot productie in. Houd een gelogde break-glass-procedure achter de hand.
Laat u het liever voor u bouwen? Zie de Self-Service Release Build.
Waar u begint
Meet eerst uw laatste release
GitOps verandert hoe de laatste stap van een release verloopt. De gratis Release Check laat in minder dan 5 minuten zien waar de tijd van uw laatste release naartoe ging en wat dat per jaar kost, zonder gesprek.