ArgoCD en GitOps in 2026: Kubernetes Continuous Deployment en Sollicitatievragen

ArgoCD heeft zich gevestigd als het toonaangevende GitOps-tool voor Kubernetes Continuous Deployment. Met de release van versie 3.4 in mei 2026 en meer dan 64% van de bedrijven die GitOps als primair leveringsmechanisme inzetten, is het onderwerp relevanter dan ooit. Deze tutorial behandelt de kernconcepten van ArgoCD, praktische configuratiepatronen en de meest voorkomende sollicitatievragen voor DevOps- en platform engineering-rollen.

Hoe ArgoCD het GitOps-model implementeert

ArgoCD draait als een verzameling microservices binnen een Kubernetes-cluster: een API-server, een repo-server, een application controller en een Redis-cache. De controller bewaakt Git-repositories en vergelijkt de gewenste status (manifests in Git) met de live-status in het cluster. Wanneer een verschil wordt gedetecteerd, genereert ArgoCD een waarschuwing of voert het automatisch een synchronisatie uit, afhankelijk van het geconfigureerde beleid.

Dit pull-based model biedt een beveiligingsvoordeel ten opzichte van traditionele CI-gestuurde push-deployments. Het cluster haalt wijzigingen op uit Git in plaats van een inkomend endpoint beschikbaar te stellen voor een CI-tool. De inloggegevens voor het cluster verlaten nooit de clustergrens.

De eerste stap is het installeren van ArgoCD en het definiëren van een Application-resource:

# argocd-application.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-web-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/acme/my-web-app-config
    targetRevision: main
    path: overlays/production
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true        # Remove resources deleted from Git
      selfHeal: true     # Revert manual changes in the cluster
    syncOptions:
      - CreateNamespace=true

Het source-blok verwijst naar de Git-repository met Kubernetes-manifests. Het destination-blok specificeert het doelcluster en de namespace. De instelling automated.selfHeal: true zorgt ervoor dat handmatige kubectl-wijzigingen binnen enkele seconden worden overschreven door de in Git gedeclareerde status.

Sync Waves en Hooks voor geordende deployments

Deployments in de praktijk bestaan zelden uit een enkel manifest. Databasemigraties moeten worden uitgevoerd voordat applicatie-pods starten. ConfigMaps en Secrets moeten bestaan voordat Deployments ernaar verwijzen. ArgoCD lost dit op met sync waves en resource hooks.

Sync waves kennen een numerieke volgorde toe aan resources. Lagere nummers worden eerst uitgerold, en ArgoCD wacht tot elke wave als healthy is gerapporteerd voordat het verdergaat:

# migration-job.yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: db-migrate
  annotations:
    argocd.argoproj.io/sync-wave: "-1"   # Runs before wave 0
    argocd.argoproj.io/hook: PreSync      # Executes before main sync
    argocd.argoproj.io/hook-delete-policy: HookSucceeded
spec:
  template:
    spec:
      containers:
        - name: migrate
          image: acme/my-web-app:latest
          command: ["python", "manage.py", "migrate"]
      restartPolicy: Never

De PreSync-hook voert de migratie-job uit voordat ArgoCD de hoofdmanifests van de applicatie toepast. Het HookSucceeded-verwijderbeleid ruimt de Job op na succesvolle afronding. ArgoCD 3.3 introduceerde daarnaast PreDelete-hooks, waarmee het langdurige probleem van verweesde resources bij het verwijderen van applicaties werd opgelost.

Multi-cluster beheer met ApplicationSets

Het beheren van tientallen clusters vanuit één ArgoCD-instantie vereist meer dan het kopiëren van Application-manifests. ApplicationSets genereren Application-resources dynamisch op basis van templates en generatoren:

# applicationset-clusters.yaml
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: my-web-app-all-clusters
  namespace: argocd
spec:
  generators:
    - clusters:
        selector:
          matchLabels:
            env: production
  template:
    metadata:
      name: 'my-web-app-{{name}}'
    spec:
      project: default
      source:
        repoURL: https://github.com/acme/my-web-app-config
        targetRevision: main
        path: 'overlays/{{metadata.labels.region}}'
      destination:
        server: '{{server}}'
        namespace: production
      syncPolicy:
        automated:
          prune: true
          selfHeal: true

De clustergenerator itereert over alle geregistreerde clusters met het label env: production en maakt één Application per cluster aan. De placeholders {{name}}, {{server}} en {{metadata.labels.region}} worden opgelost vanuit de clusterregistratiegegevens. Het toevoegen van een nieuw productiecluster aan ArgoCD triggert automatisch de deployment van de applicatie naar dat cluster.

ArgoCD vs Flux: het juiste GitOps-tool kiezen

De vergelijking tussen ArgoCD en Flux is een van de meest voorkomende DevOps-sollicitatieonderwerpen. Beide zijn CNCF Graduated-projecten die het GitOps-patroon implementeren, maar ze verschillen in architectuur en afwegingen:

| Kenmerk | ArgoCD 3.4 | Flux 2.8 | |---------|-----------|----------| | Architectuur | Gecentraliseerde server met UI | Gedistribueerde controllers per cluster | | Web UI | Ingebouwd, volwassen dashboard | Geen ingebouwde UI (opties van derden) | | Helm-ondersteuning | Rendert templates server-side | Native Helm SDK-integratie | | Multi-cluster | Hub-and-spoke vanuit één instantie | Onafhankelijke installatie per cluster | | RBAC | Op applicatieniveau met SSO | Alleen Kubernetes-native RBAC | | Image-automatisering | Apart Image Updater-component | Ingebouwde image reflector/automation | | Progressive delivery | Argo Rollouts-integratie | Flagger-integratie | | Resourceverbruik | Hoger (API-server, repo-server, Redis) | Lager (alleen benodigde controllers) |

ArgoCD past bij teams die waarde hechten aan gecentraliseerd overzicht, een webdashboard en fijnmazig RBAC op applicatieniveau. Flux past bij teams die edge- of resource-beperkte omgevingen beheren, of die sterk afhankelijk zijn van native Helm-lifecyclefuncties. Sommige organisaties gebruiken beide: ArgoCD voor applicatiedeployments waar de UI meerwaarde biedt, en Flux voor infrastructuurcomponenten waar gedistribueerde werking en Helm-getrouwheid belangrijker zijn.

Repositorystructuur voor GitOps in productie

Een veelgemaakte fout bij de adoptie van GitOps is het opslaan van Kubernetes-manifests naast de broncode van de applicatie. Het scheiden van de configuratie-repository van de app-repository biedt een schonere Git-historie, onafhankelijke review-cycli en eenvoudigere CI-triggers:

# Recommended repository structure
my-web-app-config/
  base/
    deployment.yaml
    service.yaml
    kustomization.yaml
  overlays/
    staging/
      kustomization.yaml       # Patches for staging
      replica-count.yaml
    production/
      kustomization.yaml       # Patches for production
      replica-count.yaml
      hpa.yaml

De base-directory bevat gedeelde manifests. Elke overlay past omgevingsspecifieke patches toe via Kustomize. De CI-pipeline bouwt en pusht de container-image en werkt vervolgens de image-tag bij in de configuratie-repository. ArgoCD detecteert de commit en synchroniseert de nieuwe versie naar het cluster.

ArgoCD 3.4-features die het kennen waard zijn

ArgoCD 3.4, uitgebracht in mei 2026, richt zich op Day 2-operaties met features die regelmatig aan bod komen in senior DevOps-sollicitatiegesprekken:

Pause cluster reconciliation stelt operators in staat om de ArgoCD-synchronisatie tijdens productie-incidenten te bevriezen. Dit voorkomt dat ArgoCD noodhotfixes terugdraait die rechtstreeks op het cluster zijn toegepast terwijl het team het probleem oplost:

# Pause reconciliation on a specific cluster
apiVersion: v1
kind: Secret
metadata:
  name: prod-cluster
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: cluster
  annotations:
    argocd.argoproj.io/pause-reconciliation: "true"
stringData:
  server: https://prod-cluster.example.com
  config: |
    { "tlsClientConfig": { "insecure": false } }

Helm value globs vervangen uitgebreide valueFiles-arrays door patronen, wat merge-conflicten vermindert in teams die veel omgevingsspecifieke value-bestanden onderhouden:

# Before ArgoCD 3.4
source:
  helm:
    valueFiles:
      - values.yaml
      - values-production.yaml
      - values-production-eu.yaml
      - values-production-eu-secrets.yaml

# With ArgoCD 3.4 value globs
source:
  helm:
    valueFiles:
      - values.yaml
      - values-production*.yaml

Veelgestelde ArgoCD-sollicitatievragen

Deze vragen komen regelmatig voor in sollicitatiegesprekken voor DevOps- en platform engineering-rollen. Ze toetsen het begrip van GitOps-principes, niet alleen ArgoCD-syntax. Voor een bredere Kubernetes-voorbereiding behandelt de Kubernetes Advanced-module scheduling, security contexts en custom controllers.

"Leg het verschil uit tussen automatische sync en handmatige sync in ArgoCD."

Automatische sync past wijzigingen toe op het cluster zodra ArgoCD een verschil detecteert tussen Git en de live-status. Handmatige sync vereist een expliciete trigger vanuit de UI, CLI of API. Automatische sync met selfHeal: true corrigeert continu drift en is de standaard voor productieomgevingen waar configuratieconsistentie cruciaal is. Handmatige sync is geschikt voor staging-omgevingen waar teams wijzigingen willen beoordelen voordat ze worden toegepast.

"Wat gebeurt er wanneer ArgoCD drift detecteert tussen Git en het cluster?"

ArgoCD vergelijkt de gewenste status (Git-manifests gerenderd via Helm, Kustomize of plain YAML) met de live-status in het cluster. Als automatische sync met selfHeal is ingeschakeld, zet ArgoCD het cluster onmiddellijk terug naar de Git-status. Als selfHeal is uitgeschakeld, markeert ArgoCD de applicatie als OutOfSync en wacht op handmatig ingrijpen. Het resourceverschil is zichtbaar in de UI en toont precies welke velden afwijken.

"Hoe zou u databasemigraties afhandelen in een GitOps-workflow?"

Databasemigraties worden uitgevoerd als PreSync-hook Jobs met een negatief sync wave-nummer. De migratie-Job wordt uitgevoerd voordat ArgoCD de nieuwe applicatieversie uitrolt. Als de migratie mislukt, wordt de synchronisatie afgebroken en blijft de vorige applicatieversie actief. Het HookSucceeded-verwijderbeleid ruimt succesvolle migratie-Jobs op. Voor rollback-scenario's moeten migratiescripts als idempotente operaties worden ontworpen.

"Vergelijk ArgoCD en Flux voor een multi-cluster productie-setup."

ArgoCD beheert meerdere clusters vanuit één control plane en biedt gecentraliseerd overzicht via het dashboard en uniform RBAC over alle clusters. Flux draait onafhankelijk in elk cluster, wat de blast radius verkleint doordat een uitval van het control plane slechts één cluster treft. Bij 100+ clusters vereist het gecentraliseerde model van ArgoCD een robuust managementcluster, terwijl de gedistribueerde aanpak van Flux dat single point of failure elimineert. De keuze hangt af van de prioriteit van het team: operationele eenvoud (ArgoCD) of foutisolatie (Flux). De CI/CD Pipeline Security-module behandelt gerelateerde vragen over het beveiligen van deployment-pipelines.

"Wat is een ApplicationSet en wanneer wordt het gebruikt?"

Een ApplicationSet is een controller die ArgoCD Application-resources genereert vanuit templates. Het maakt gebruik van generatoren (cluster, Git directory, list, matrix, merge) om meerdere Applications te produceren vanuit één definitie. Typische gebruiksscenario's zijn het deployen van dezelfde applicatie over alle productieclusters, het genereren van per-tenant applicaties in een multi-tenant SaaS-platform, of het aanmaken van Applications voor elke directory in een monorepo.

Conclusie

• ArgoCD 3.4 (mei 2026) voegt pause reconciliation en Helm value globs toe, gericht op Day 2-operationele behoeften in Kubernetes-productieclusters
• Het pull-based GitOps-model elimineert de noodzaak om clusterinloggegevens aan CI-tools bloot te stellen en houdt secrets binnen de clustergrens
• Sync waves en hooks lossen de volgorde van deployments op: migraties vóór app-pods, ConfigMaps vóór Deployments, opruiming na verwijdering
• ApplicationSets automatiseren multi-cluster deployment door Application-resources te genereren vanuit clusterlabels, Git-directories of aangepaste lijsten
• Configuratie-repositories dienen gescheiden te worden van app-repositories voor een schonere Git-historie, onafhankelijke review-cycli en eenvoudigere CI-triggers
• ArgoCD is geschikt voor gecentraliseerd multi-cluster beheer met dashboard en RBAC; Flux is geschikt voor gedistribueerde, resource-beperkte of Helm-intensieve omgevingen
• De voorbereiding op sollicitatiegesprekken voor GitOps-rollen moet driftdetectie, sync-strategieën, faalscenario's en concrete productiescenario's omvatten in plaats van uit het hoofd geleerde definities