Ik heb Argo CD opgezet op lokale Kubernetes — Zo heb ik het gedaan

Ik heb Argo CD opgezet op lokale Kubernetes — Zo heb ik het gedaan

De pod draaide al elf dagen. Stabiel. Gezond. Stilletjes zijn werk aan het doen in mijn lokale Kubernetes cluster. Ik heb hem met opzet verwijderd. Zes seconden later verscheen er een gloednieuwe pod op zijn plek. Dezelfde specificatie, dezelfde configuratie, nul downtime. Ik heb kubectl apply niet aangeraakt. Ik heb geen pipeline geactiveerd. Ik heb helemaal niets gedaan. Argo CD bewaakte mijn Git repo, zag dat de gewenste toestand zei "deze pod hoort te bestaan," en bracht hem weer tot leven voordat ik van browsertab kon wisselen. Dat moment — een verwijderde pod zien herrijzen op een lokale Docker Desktop cluster op mijn MacBook — was het moment waarop GitOps ophield een abstract concept te zijn dat ik had gelezen in CNCF blogposts en iets werd dat ik kon voelen. Iets tastbaars. Je Git repo wordt de enige bron van waarheid, en Kubernetes buigt zich om ermee overeen te komen. Niet uiteindelijk. Niet nadat een pipeline draait. Nu meteen. Ik was al maanden van plan om Argo CD op te zetten. Bleef het uitstellen tot "volgend weekend." De aanname was dat het ingewikkeld zou zijn — tooling van productiekwaliteit is dat meestal. Ik dacht dat ik een cloud cluster nodig zou hebben, een CI/CD pipeline die al op zijn plek stond, misschien een heel vrij middagje worstelen met Helm charts en RBAC configuraties. De daadwerkelijke installatie duurde minder dan tien minuten. En het project dat ik gebruikte om het te testen — infrawhisper, een data- en AI-platform dat ik aan het bouwen ben met componenten zoals een API server, AI engine, stream processor en een realtime dashboard — gaf me een perfecte stresstest om te zien of Argo CD een echt complexe lokale deployment aankon. Hier is alles wat ik deed, alles wat ik leerde, en die ene Docker Desktop valkuil die bijna het hele project liet ontsporen.

Waarom ik eindelijk ben gestopt met kubectl apply met de hand draaien

Ik heb een bekentenis. Beschamend lang zag mijn deployment workflow voor lokale Kubernetes er zo uit:

1. Code aanpassen
2. Docker image bouwen
3. kubectl apply -f deployment.yaml draaien
4. Beseffen dat ik vergeten was de image tag bij te werken
5. De YAML bewerken, opnieuw toepassen
6. Me afvragen waarom de oude pods nog steeds draaien
7. De deployment verwijderen, opnieuw toepassen
8. Morgen hetzelfde herhalen met dezelfde frustratie Als je enige tijd met Kubernetes hebt gewerkt, herken je deze pijn. Het is niet dat kubectl apply kapot is — het werkt prima. Het probleem is dat het jou, de mens, in het kritieke pad van elke deployment plaatst. Jij wordt de pipeline. En mensen zijn verschrikkelijke pipelines. Het diepere probleem is drift. Je past een manifest toe. Een teamgenoot (of de versie van jezelf om 2 uur 's nachts) maakt een snelle handmatige wijziging met kubectl edit. Nu is de toestand van je cluster stilletjes afgeweken van wat er in je Git repo staat. Niemand merkt het tot er iets kapot gaat. En als het kapot gaat, veel succes met uitzoeken of de "juiste" toestand in Git staat, in het cluster, of in iemands terminal geschiedenis. GitOps lost dit op door één regel niet-onderhandelbaar te maken: Git is waarheid. Het cluster komt overeen met Git. Altijd. Als ze afwijken, verandert het cluster — niet Git. Volgens een CNCF End User Survey van medio 2025 vertrouwt bijna 60% van de Kubernetes clusters nu op Argo CD voor applicatielevering. Dat percentage stijgt elk kwartaal. En 97% van de respondenten die Argo CD gebruiken, draaien het in productie — ten opzichte van 93% in 2023. Dit is geen experimentele tool meer. Het is de standaardmanier waarop serieuze teams deployen naar Kubernetes. Maar de meeste handleidingen die ik vond gingen ervan uit dat je EKS of GKE draait. Een productiecluster met degelijke networking, load balancers en ingress controllers die al geconfigureerd zijn. Ik wilde weten: werkt dit op Docker Desktop? Op een lokaal cluster waar je experimenteert, dingen kapotmaakt en leert? Het antwoord is ja — met één belangrijke workaround die ik je laat zien in stap twee.

Wat Argo CD eigenlijk doet (Het mentale model dat ertoe doet)

Voordat ik de installatie doorloop, wil ik je het mentale model geven dat alles voor mij op zijn plek liet vallen. Want de commando's zijn simpel. Begrijpen waarom ze werken is wat iemand die Argo CD installeert onderscheidt van iemand die het daadwerkelijk goed gebruikt. Argo CD is een Kubernetes controller. Het draait in je cluster als een set pods — een server, een repo server, een application controller en een paar ondersteunende diensten. Eenmaal geïnstalleerd, wijs je het naar een Git repository en zeg je: "Deze directory bevat de gewenste toestand van mijn applicatie. Bewaak het." Vanaf dat moment werkt Argo CD op een continue reconciliatielus:

1. Observeren — De Git repo pollen op wijzigingen (of webhook notificaties ontvangen)
2. Vergelijken — Het verschil bepalen tussen de gewenste toestand in Git en de live toestand in het cluster
3. Handelen — Als ze verschillen, je waarschuwen (handmatige sync) of automatisch de wijzigingen toepassen (auto sync) Die derde stap is waar de magie zit. Met auto-sync ingeschakeld wordt de workflow:

Push naar Git → Argo CD detecteert wijziging → Deployt automatisch → Herstelt zichzelf bij drift

Geen CI/CD pipeline die een deploy stap activeert. Geen mens die commando's draait. Je pusht code, en het cluster convergeert om overeen te komen. De feedbacklus is zo strak dat het mijn hele kijk op deployments veranderde. Dit is wat het voor mij concreet maakte: ik pushte een Helm chart update naar mijn infrawhisper repo om 23:15. Om 23:15 en ongeveer acht seconden had Argo CD de wijziging al gesynchroniseerd en waren de nieuwe pods aan het uitrollen. Ik heb niet eens mijn code-editor verlaten. Het commit bericht verscheen in het Argo CD dashboard — feat(deploy): add Argo CD application manifest for GitOps deployment — en de sync status las "Sync OK." Dat niveau van directheid laat handmatige deploys aanvoelen als deployment instructies versturen per postduif. Nog één ding over het mentale model. Argo CD deployt niet alleen. Het bewaakt actief op drift. Als iemand (of iets) de clustertoestand buiten Git om wijzigt — een handmatige kubectl edit, een ongeautoriseerd script, een per ongeluk verwijdering — detecteert Argo CD het verschil en corrigeert het. Het cluster herstelt zichzelf. Ik bewijs verderop in dit bericht dat dit werkt met een live test. Maar laten we het eerst draaiend krijgen.

De complete installatie: Argo CD op Docker Desktop Kubernetes

Vereisten — Wat je nodig hebt voordat je begint

Je hebt precies twee dingen nodig:

• Docker Desktop met Kubernetes ingeschakeld (Instellingen → Kubernetes → Enable Kubernetes → Apply & Restart). Ik draai Docker Desktop op macOS, maar de stappen zijn identiek op Windows en Linux.
• kubectl geconfigureerd en gericht op je Docker Desktop cluster. Verifieer met:

kubectl config current-context
# Zou moeten tonen: docker-desktop

Als je een andere context ziet, wissel dan met kubectl config use-context docker-desktop. Je wilt niet per ongeluk Argo CD installeren op een productiecluster. Vraag me hoe ik weet dat het de moeite waard is om dit te controleren. Dat is alles. Geen Helm nodig voor de basisinstallatie. Geen cloud provider account. Geen load balancer. Docker Desktop's ingebouwde Kubernetes is genoeg.

Stap 1 — Argo CD installeren in je cluster

Twee commando's. Het eerste maakt een speciale namespace aan. Het tweede haalt de officiële Argo CD manifests op en installeert alles.

kubectl create namespace argocd
kubectl apply -n argocd -f \
  https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

Dit installeert Argo CD v3.3.4 (de stabiele release per maart 2026), inclusief PreDelete hooks, OIDC achtergrond token verversing, verbeterde RBAC controls en KEDA integratie. Het manifest deployt verschillende componenten in de argocd namespace:

• argocd-server — De API server en web UI
• argocd-repo-server — Kloont en verwerkt je Git repo's
• argocd-application-controller — De reconciliatie-engine die bewaakt op drift
• argocd-redis — Cachinglaag
• argocd-dex-server — SSO authenticatie (optioneel voor lokale installaties) Wacht ongeveer 60-90 seconden tot alle pods de Running status bereiken. Je kunt ze zien opstarten:

kubectl get pods -n argocd -w

Wanneer je vijf of zes pods ziet die allemaal 1/1 Running tonen, ben je klaar voor de volgende stap. En de volgende stap is degene waar ik een goede twintig minuten op vastliep.

Stap 2 — NetworkPolicies verwijderen (De Docker Desktop valkuil)

Dit is de stap die geen enkele "quick start" handleiding noemde. Ik installeerde Argo CD, probeerde de UI te openen, en kreeg niets. Connection refused. Timeout. De pods draaiden, de service bestond, maar port-forwarding... werkte gewoon niet. Na twintig minuten service selectors en pod logs controleren, vond ik het probleem: Argo CD wordt geleverd met NetworkPolicy resources die verkeer tussen zijn componenten beperken. Op een echt cluster met een CNI plugin die NetworkPolicies ondersteunt (Calico, Cilium, etc.), werken deze perfect. Op Docker Desktop's ingebouwde Kubernetes netwerk? Ze breken stilletjes alles. Docker Desktop's standaard CNI handhaaft geen NetworkPolicies, maar de policies worden wel aangemaakt en kunnen op subtiele manieren service discovery verstoren. De oplossing is simpel:

kubectl delete networkpolicies --all -n argocd

Dat is alles. Eén commando. Twintig minuten van mijn leven die ik niet terugkrijg. Ik schrijf dit op zodat jij niet dezelfde twintig minuten verliest.

Na het uitvoeren hiervan werkt port-forwarding meteen. Als je een echt cluster draait met Calico of Cilium, sla deze stap dan over — je wilt die policies behouden.

Stap 3 — Toegang tot het Argo CD Dashboard

Stel nu de Argo CD server beschikbaar voor je lokale machine:

kubectl port-forward svc/argocd-server -n argocd 8443:443

Open je browser en navigeer naar https://localhost:8443. Je krijgt een certificaatwaarschuwing — dat is verwacht voor een self-signed certificaat op localhost. Klik erdoorheen. Je zou het Argo CD inlogscherm moeten zien. Strak. Minimalistisch. Die donkere UI die uitstraalt "dit is serieuze tooling."

Stap 4 — Je inloggegevens ophalen

De standaard gebruikersnaam is admin. Het initiële wachtwoord wordt automatisch gegenereerd en opgeslagen als een Kubernetes secret. Haal het op met:

kubectl -n argocd get secret argocd-initial-admin-secret \
  -o jsonpath="{.data.password}" | base64 -d

Kopieer die uitvoer — dat is je tijdelijke wachtwoord. Log in met admin en het gedecodeerde wachtwoord. Pro tip: Wijzig dit wachtwoord direct na de eerste keer inloggen, vooral als iemand anders toegang heeft tot je netwerk. In een lokale dev omgeving is het minder kritiek, maar goede gewoontes opbouwen is belangrijk. Je kunt het wijzigen via de Argo CD CLI of via de UI onder User Info → Update Password. Op dit punt heb je een volledig functionele Argo CD installatie draaien op je lokale Kubernetes cluster. Het dashboard is leeg — nog geen applicaties. Dat verandert nu.

Stap 5 — Je Application Manifest aanmaken

Dit is waar Argo CD verbinding maakt met je Git repository en je deployments gaat beheren. Je hebt een Application manifest nodig — een Kubernetes custom resource die Argo CD vertelt wat het moet bewaken en waar het moet deployen. Hier is het manifest dat ik gebruikte voor mijn infrawhisper project:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/your-repo.git
    targetRevision: main
    path: deploy/helm/my-app
    helm:
      valueFiles:
        - values.yaml
  destination:
    server: https://kubernetes.default.svc
    namespace: my-app
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

Laat me uitleggen wat elke sectie doet, want het begrijpen van deze velden bespaart je uren debuggen later: source — Waar Argo CD je manifests moet zoeken:

• repoURL: Je Git repository (openbare repo's werken direct; privérepo's vereisen geconfigureerde credentials in Argo CD instellingen)
• targetRevision: Welke branch gevolgd moet worden. Ik gebruik main, maar je kunt dit richten op elke branch, tag of commit SHA
• path: De directory binnen de repo die je Kubernetes manifests of Helm chart bevat
• helm.valueFiles: Als je Helm gebruikt (ik wel), specificeert dit welk values bestand toegepast moet worden destination — Waar Argo CD moet deployen:
• server: De Kubernetes API server URL. https://kubernetes.default.svc betekent "deploy naar hetzelfde cluster waar Argo CD in draait." Voor lokale installaties is dit altijd wat je wilt.
• namespace: De doelnamespace voor de resources van je applicatie syncPolicy — Hoe Argo CD zich moet gedragen:
• automated: Schakelt auto-sync in. Zonder dit zou je elke keer handmatig op "Sync" moeten klikken in de UI
• prune: true: Als je een resource uit Git verwijdert, verwijdert Argo CD het uit het cluster. Zonder dit laten verwijderde manifests verweesd resources achter
• selfHeal: true: Dit is de grote. Als iemand of iets de clustertoestand buiten Git om wijzigt, draait Argo CD het terug. Je cluster komt altijd overeen met Git.
• CreateNamespace=true: Argo CD maakt de doelnamespace aan als deze niet bestaat Sla dit op als application.yaml in je projectdirectory. Pas de repoURL, path en namespace aan zodat ze overeenkomen met jouw werkelijke installatie.

Stap 6 — Deployen en de magie bekijken

Pas het manifest toe:

kubectl apply -f application.yaml

Schakel nu over naar je Argo CD dashboard op https://localhost:8443. Binnen enkele seconden zou je applicatie moeten verschijnen. Argo CD begint meteen met synchroniseren — je repo klonen, de Helm chart renderen (of gewone manifests), en de resources toepassen op je cluster. Voor mijn infrawhisper project lichtte het dashboard op met de complete applicatietopologie: api-server met 3 pods, dashboard met 2 pods, ai-engine met 2 pods, stream-processor met 2 pods, collector met 2 pods, plus de infrawhisper-agent en ingress controller. Allemaal zichtbaar in één netwerkoverzicht. De commit hash 776a48f van mijn laatste push was direct zichtbaar in de UI, met het commit bericht dat ik minuten eerder had geschreven.

De Docker Desktop containerlijst vertelde hetzelfde verhaal vanuit een ander perspectief — 38 draaiende containers, met de argocd componenten naast mijn applicatie pods: ai-engine, api-server, clickhouse, collector, dashboard, kafka, postgres, redis, stream-processor. Een volledig dataplatform dat lokaal draait, volledig beheerd via Git.

Dat is de installatie. Zes stappen, minder dan tien minuten. Maar de installatie is slechts het fundament. De echte vraag is: werkt het daadwerkelijk zoals de documentatie belooft? Ik heb drie tests gedaan om erachter te komen.

De zelfhersteltest: Met opzet een pod verwijderen

Dit is de test die ik uitvoerde om te bewijzen dat zelfherstel werkt op een lokaal cluster. Mijn infrawhisper dashboard component draaide met 2 replica pods. Eén specifieke pod — dashboard-75fd8b8ddb-55x9h — draaide al 11 dagen stabiel en gezond. Stabiel, verkeer aan het afhandelen, zijn werk aan het doen. Ik heb hem verwijderd.

kubectl delete pod dashboard-75fd8b8ddb-55x9h -n my-app

Toen keek ik toe. Niet naar het Argo CD dashboard — ik keek naar de terminal. Binnen zes seconden:

• VOOR: dashboard-75fd8b8ddb-55x9h — Running, Leeftijd: 11 dagen
• VERWIJDERD: Pod beëindigd
• NA: dashboard-75fd8b8ddb-lt5bn — Running, Leeftijd: 6 seconden Een gloednieuwe pod, andere naam, dezelfde spec. Kubernetes' ReplicaSet controller verzorgde de directe vervanging (dat is standaard Kubernetes gedrag). Maar hier is het deel dat ertoe doet: Argo CD's reconciliatielus bevestigde dat de clustertoestand nog steeds overeenkwam met de gewenste toestand in Git. Als de pod verwijdering had geleid tot drift van de deployment ten opzichte van Git's definitie — bijvoorbeeld als iemand handmatig het aantal replica's had verlaagd — had Argo CD dat ook opgepikt en gecorrigeerd. Dit is geen hypothetische veerkracht. Het is meetbaar. Ik zag het gebeuren op mijn laptop, op een lokaal cluster, met tools die je in tien minuten kunt installeren. De diepere implicatie had een dag nodig om te bezinken. Met zelfherstel ingeschakeld zijn je deployment manifests in Git niet zomaar configuratiebestanden. Ze zijn een contract. Een belofte over hoe het cluster er te allen tijde uit moet zien. Breek het contract handmatig, en het systeem handhaaft het automatisch. Die verschuiving in denken — van "ik deploy dingen" naar "ik declareer dingen en het systeem onderhoudt ze" — is de kern van GitOps. En het voelt compleet anders als je het eenmaal zelf ervaart.

Driftdetectie: De stille bewaker

De zelfhersteltest dekt onbedoelde verwijderingen. Maar hoe zit het met opzettelijke handmatige wijzigingen? Het soort dat gebeurt wanneer iemand kubectl edit deployment draait om iets "snel te fixen" in productie om 3 uur 's nachts? Ik testte dit door handmatig mijn api-server deployment te schalen van 3 replica's naar 1:

kubectl scale deployment api-server --replicas=1 -n my-app

Gedurende ongeveer vijftien seconden had het cluster 1 api-server pod in plaats van de 3 die in mijn Git repo gedefinieerd stonden. Toen detecteerde Argo CD's reconciliatielus de drift, vergeleek de live toestand met Git, en schaalde het terug naar 3. Geen alarm. Geen handmatige interventie. Het Argo CD dashboard toonde de app health kort als "Degraded" (wat klopt — minder replica's draaien dan gewenst is gedegradeerd), en schakelde daarna weer terug naar "Healthy" zodra de reconciliatie voltooid was. Dit is het gedrag dat GitOps transformatief maakt voor teams. Het voorkomt niet alleen problemen — het corrigeert ze actief. En het creëert een audittrail. Elke sync operatie verschijnt in Argo CD's geschiedenis. Je kunt precies zien wanneer drift optrad en wanneer het gecorrigeerd werd. Probeer dat maar eens te krijgen van kubectl apply.

Auto-Sync: Push naar Git, zie het deployen

De derde test was de simpelste en de meest bevredigende. Ik wijzigde een waarde in de values.yaml van mijn Helm chart — verhoogde het aantal dashboard replica's van 2 naar 3 — committede, en pushte naar main. Ik had het Argo CD dashboard open in een browser en mijn terminal met kubectl get pods -n my-app -w naast elkaar. Binnen ongeveer vijftien seconden na de push detecteerde Argo CD de nieuwe commit, haalde de bijgewerkte chart op, renderde de manifests en paste de wijziging toe. Een derde dashboard pod begon op te starten terwijl ik toekeek. De sync status in het dashboard werd bijgewerkt om de nieuwe commit hash te tonen. Het commit bericht dat ik net had geschreven stond daar in de UI. Geen pipeline. Geen webhook configuratie. Geen deploy script. Ik pushte code en het cluster veranderde. Dat is de belofte van GitOps, en op een lokale Docker Desktop cluster met Argo CD v3.3.4 werd die belofte exact waargemaakt.

Wat Argo CD goed doet — En waar het eerlijk is

Na deze setup enkele dagen te hebben gedraaid op mijn infrawhisper project, hier is mijn eerlijke beoordeling. Wat oprecht indrukwekkend is:

• Het dashboard alleen al is de installatie waard. Je hele applicatietopologie zien — elke deployment, service, pod en ingress — in één visueel overzicht is iets dat kubectl je nooit kan geven. Voor mijn infrawhisper project met zijn ruim twaalf componenten ging dit van "leuk om te hebben" naar "hoe heb ik ooit zonder dit gewerkt" in ongeveer drie uur.
• De syncsnelheid is echt. Ik verwachtte minuten. Ik kreeg seconden. De vertraging tussen pushen naar Git en de wijziging live zien in het cluster was consistent onder de 20 seconden op mijn lokale installatie.
• Rollback is één klik. Argo CD bewaart een geschiedenis van elke sync. Als een deployment misgaat, klik je op "Rollback" en selecteer je een vorige commit. Het cluster keert terug. Probeer dat maar eens met kubectl apply en een gebed.
• Helm chart rendering wordt voor je gedaan. Ik hoefde lokaal geen helm template of helm install te draaien. Argo CD's repo-server rendert de chart en past de uitvoer toe. Dit betekent dat je Git repo alleen de chart broncode nodig heeft — Argo CD doet de rest. Wat ik wilde dat iemand me had verteld:
• De resource overhead is niet verwaarloosbaar. Op Docker Desktop voegden de Argo CD componenten ruwweg 500MB-700MB RAM-gebruik toe en meerdere CPU cores aan achtergrondactiviteit. Op een moderne machine is dat prima. Op een oudere laptop voel je het. Mijn Docker Desktop draaide al 38 containers voor de infrawhisper stack — Argo CD's pods erbij bracht het totale geheugengebruik boven de 8GB.
• Privérepo's vereisen extra configuratie. Als je Git repository privé is (de meeste zijn dat), moet je repository credentials configureren in Argo CD's instellingen. Dit omvat een SSH key, een personal access token, of een GitHub App. De officiële docs behandelen dit goed, maar het is een extra stap die de "twee-commando installatie" handleidingen handig overslaan.
• De initiële admin wachtwoord workflow is onhandig. Base64-decoderen van een Kubernetes secret om je eerste wachtwoord te krijgen werkt, maar het is geen geweldige developer experience. Ik zou graag een interactieve setup wizard zien voor lokale installaties.
• NetworkPolicies op Docker Desktop zijn een echte tijdverspiller. Ik heb dit al behandeld in de installatiestappen, maar het is het herhalen waard: als je op Docker Desktop draait en dingen niet verbinden, verwijder eerst de NetworkPolicies. Dit enkele probleem veroorzaakt waarschijnlijk meer afgebroken Argo CD lokale installaties dan welke echte bug dan ook. Als je liever hebt dat iemand dit soort infrastructuur vanaf nul opbouwt — Kubernetes clusters, GitOps pipelines, de hele platform engineering stack — neem ik DevOps en cloud engineering projecten aan. Je kunt zien wat ik heb gebouwd op fiverr.com/s/EgxYmWD.

Waar dit past in een echte workflow

Argo CD lokaal draaien is niet alleen een leerexercitie. Het is de eerste fase van een workflow die direct schaalt naar productie. Dit is de progressie die ik plan voor mijn infrawhisper project: Fase 1 (waar ik nu ben): Lokaal Docker Desktop cluster met Argo CD die Helm deployments beheert. Perfect voor ontwikkeling, sync gedrag testen en manifests valideren voordat ze een echt cluster raken. Fase 2: Dezelfde manifests — ongewijzigd — verplaatsen naar een staging cluster op AWS EKS of een zelfbeheerd cluster. Argo CD's Application manifest blijft identiek. Alleen de destination.server verandert. Fase 3: Productie deployment met Argo CD die meerdere omgevingen beheert via ApplicationSets. Dezelfde Git repo, verschillende value bestanden per omgeving, Argo CD die de uitrol naar elk beheert. Het belangrijkste inzicht: het Application manifest dat ik schreef in stap 5 van deze handleiding verandert niet tussen fasen. De Helm chart verandert niet. Het sync beleid verandert niet. Ik bouw nu de productie workflow, op mijn laptop, met dezelfde tools die ik gebruik wanneer infrawhisper live gaat. Dat is geen bijkomend voordeel van lokale Argo CD — het is het primaire voordeel. Platform engineers vertegenwoordigen nu 37% van de Argo CD gebruikers volgens de CNCF survey, en dit is precies waarom. De patronen die je lokaal vaststelt, gaan direct door naar productie. Er is geen "herschrijf de deployment pipeline" stap wanneer je klaar bent om te shippen.

De vijf dingen die Argo CD je geeft die kubectl apply nooit zal bieden

Na met deze setup te hebben geleefd, kan ik precies verwoorden wat er veranderde. Niet in abstracte termen — in concrete, dagelijkse workflow termen: 1. Auto Sync elimineert de deploy stap volledig. Push naar Git. Loop weg. Het cluster wordt bijgewerkt. Dit klinkt klein totdat je beseft hoe vaak per dag je kubectl apply draait. Voor mij was dat 15-20 keer tijdens actieve ontwikkeling. Elke keer is een contextswitch, een terminal venster, een kans om het verkeerde manifest toe te passen op de verkeerde namespace. Allemaal weg. 2. Zelfherstel vangt fouten op die je nooit zou opmerken. Per ongeluk verwijderde pods. Ongeautoriseerde scripts. Verkeerd geconfigureerde autoscalers. Argo CD detecteert drift en corrigeert het. Op mijn infrawhisper stack met 10+ microservices is dit geen luxe — het is het verschil tussen een stabiele lokale omgeving en een die langzaam wegrot. 3. Driftdetectie creëert verantwoordelijkheid. Elke handmatige wijziging wordt teruggedraaid en gelogd. Dit is beveiliging en operationele hygiëne in één. Je kunt zien wie (of wat) het cluster wijzigde, wanneer, en hoe Argo CD het corrigeerde. 4. Het visuele dashboard vervangt een dozijn kubectl commando's. Pod status, replica counts, health checks, sync geschiedenis, applicatietopologie — alles in één browsertab. Ik draaide vroeger kubectl get pods, kubectl get svc, kubectl describe deployment en kubectl logs in snelle opeenvolging alleen maar om de toestand van mijn cluster te begrijpen. Nu werp ik een blik op het Argo CD dashboard. 5. Rollback wordt een enkele klik. Niet "vind de laatst werkende commit, check het manifest uit, pas het toe, controleer of het werkte." Eén klik. Selecteer de commit. Klaar. Voor een project als infrawhisper met onderling afhankelijke services rechtvaardigt dit alleen al de installatie.

Wat ik de volgende keer anders zou doen

Als ik dit helemaal opnieuw zou instellen, zouden drie dingen veranderen: Ik zou de Argo CD CLI vanaf het begin installeren. De web UI is geweldig voor visualisatie, maar de CLI (argocd) is sneller voor het beheren van applicaties, synchroniseren en status controleren vanuit de terminal. Ik installeerde het aanvankelijk niet omdat ik de installatie minimaal wilde houden, en ik had er binnen een dag spijt van. Installeer het met:

brew install argocd

Ik zou ApplicationSets vanaf dag één gebruiken. Mijn infrawhisper project heeft één Application manifest, maar naarmate ik meer omgevingen toevoeg (staging, productie), heb ik één Application per omgeving nodig. ApplicationSets laten je Application resources templaten — één definitie die meerdere Applications genereert op basis van parameters. Met dit patroon vroeg beginnen bespaart een migratie later. Ik zou repository credentials direct configureren. Ik begon met een openbare repo fork voor testen, en verplaatste daarna naar mijn daadwerkelijke privérepo. De credential configuratiestap onderbrak mijn flow. Stel het eerst in, zelfs als je repo momenteel openbaar is. Je toekomstige ik zal het waarderen.

Aan de slag: De tien-minuten checklist

Hier is de verkorte versie. Als je alles hierboven hebt gelezen en gewoon de stappen op één scherm wilt:

# 1. Verifieer je Kubernetes context
kubectl config current-context  # Moet zijn: docker-desktop
# 2. Installeer Argo CD
kubectl create namespace argocd
kubectl apply -n argocd -f \
  https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
# 3. Wacht op pods (ongeveer 60-90 seconden)
kubectl get pods -n argocd -w
# 4. Verwijder NetworkPolicies (alleen Docker Desktop!)
kubectl delete networkpolicies --all -n argocd
# 5. Port-forward de UI
kubectl port-forward svc/argocd-server -n argocd 8443:443
# 6. Haal admin wachtwoord op
kubectl -n argocd get secret argocd-initial-admin-secret \
  -o jsonpath="{.data.password}" | base64 -d
# 7. Login op https://localhost:8443 (admin + gedecodeerd wachtwoord)
# 8. Pas je Application manifest toe
kubectl apply -f application.yaml

Acht commando's. Minder dan tien minuten. Een volledig functionele GitOps pipeline die op je laptop draait. Argo CD ondersteunt Helm charts, Kustomize, Jsonnet en gewone YAML manifests — dus wat je huidige deployment formaat ook is, het sluit aan zonder iets te herschrijven. Voor mijn infrawhisper project gebruikte ik Helm omdat de chart al gestructureerd was voor geparametriseerde deployments. Maar als je een directory met kale YAML manifests hebt, wijs dan gewoon het source.path van de Application naar die directory en verwijder de helm sectie. Argo CD regelt de rest.

Veelgestelde vragen

Werkt Argo CD met Docker Desktop Kubernetes?

Ja. Argo CD draait op Docker Desktop's ingebouwde Kubernetes met één vereiste workaround: verwijder de standaard NetworkPolicies in de argocd namespace, aangezien Docker Desktop's CNI deze niet correct afhandelt. Daarna werken alle functies — auto-sync, zelfherstel, driftdetectie en het web dashboard — identiek aan cloud-gehoste clusters.

Hoeveel RAM gebruikt Argo CD op een lokaal cluster?

Reken op 500MB-700MB extra RAM voor de Argo CD control plane componenten (server, repo-server, application-controller, redis, dex). Op een machine met 16GB+ RAM is dit verwaarloosbaar. Op 8GB machines met andere zware workloads moet je mogelijk resource limits aanpassen in de Argo CD manifests.

Kan Argo CD deployen vanuit een privé Git repository?

Ja, maar je moet eerst repository credentials configureren in Argo CD's instellingen. Opties zijn SSH keys, personal access tokens of GitHub Apps. Configureer dit via de Argo CD UI (Settings → Repositories) of via de argocd CLI voordat je je Application manifest aanmaakt.

Wat gebeurt er als ik handmatig iets wijzig in het cluster?

Met selfHeal: true in het sync beleid van je Application detecteert Argo CD de drift en draait het cluster automatisch terug om overeen te komen met Git. Het dashboard toont de applicatie kort als "OutOfSync" of "Degraded," en corrigeert het vervolgens binnen de volgende reconciliatiecyclus (typisch onder de 30 seconden). Het drift-event wordt gelogd in de sync geschiedenis voor auditing.

Is de lokale Argo CD installatie hetzelfde als productie?

Vrijwel identiek. Het Application manifest, sync beleid en Helm chart configuratie zijn direct overdraagbaar naar een productiecluster. De enige wijzigingen zijn de destination.server URL (gericht op je productiecluster in plaats van kubernetes.default.svc) en omgevingsspecifieke values bestanden. Dit is een van de sterkste argumenten om lokaal te beginnen — je bouwt productiepatronen vanaf dag één.

Laten we samenwerken

Op zoek naar iemand om AI-systemen te bouwen, workflows te automatiseren of je technische infrastructuur te schalen? Ik help je graag.

• Fiverr (maatwerk builds & integraties): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (enterprise oplossingen): ramlit.com
• ColorPark (design & branding): colorpark.io
• xCyberSecurity (beveiligingsdiensten): xcybersecurity.io