Ich habe Argo CD auf lokalem Kubernetes eingerichtet — So habe ich es gemacht

Ich habe Argo CD auf lokalem Kubernetes eingerichtet — So habe ich es gemacht

Der Pod lief seit elf Tagen. Stabil. Gesund. Leise seine Arbeit in meinem lokalen Kubernetes Cluster erledigend. Ich habe ihn absichtlich gelöscht. Sechs Sekunden später erschien ein brandneuer Pod an seiner Stelle. Gleiche Spezifikation, gleiche Konfiguration, null Ausfallzeit. Ich habe kubectl apply nicht angerührt. Ich habe keine Pipeline ausgelöst. Ich habe überhaupt nichts getan. Argo CD überwachte mein Git Repo, sah, dass der gewünschte Zustand sagte "dieser Pod sollte existieren," und erweckte ihn zum Leben, bevor ich den Browser-Tab wechseln konnte. Dieser Moment — einen gelöschten Pod auf einem lokalen Docker Desktop Cluster auf meinem MacBook wieder auferstehen zu sehen — war der Moment, in dem GitOps aufhörte, ein abstraktes Konzept zu sein, über das ich in CNCF-Blogposts gelesen hatte, und zu etwas wurde, das ich spüren konnte. Etwas Greifbares. Dein Git Repo wird zur einzigen Quelle der Wahrheit, und Kubernetes passt sich an, um damit übereinzustimmen. Nicht irgendwann. Nicht nachdem eine Pipeline läuft. Sofort. Ich hatte seit Monaten vor, Argo CD einzurichten. Schob es immer auf "nächstes Wochenende." Die Annahme war, dass es kompliziert sein würde — Tooling in Produktionsqualität ist es normalerweise. Ich dachte, ich bräuchte einen Cloud Cluster, eine CI/CD Pipeline, die bereits steht, vielleicht einen ganzen freien Nachmittag, um mit Helm Charts und RBAC Konfigurationen zu kämpfen. Die tatsächliche Einrichtung dauerte weniger als zehn Minuten. Und das Projekt, mit dem ich es getestet habe — infrawhisper, eine Daten- und KI-Plattform, die ich mit Komponenten wie einem API Server, einer KI-Engine, einem Stream Processor und einem Echtzeit-Dashboard baue — gab mir einen perfekten Stresstest, ob Argo CD ein wirklich komplexes lokales Deployment bewältigen kann. Hier ist alles, was ich getan habe, alles, was ich gelernt habe, und die eine Docker Desktop Falle, die beinahe das ganze Vorhaben zum Scheitern gebracht hätte.

Warum ich endlich aufgehört habe, kubectl apply von Hand auszuführen

Ich habe ein Geständnis. Beschämend lange sah mein Deployment-Workflow für lokales Kubernetes so aus:

1. Code ändern
2. Docker Image bauen
3. kubectl apply -f deployment.yaml ausführen
4. Feststellen, dass ich vergessen habe, den Image Tag zu aktualisieren
5. Die YAML bearbeiten, erneut anwenden
6. Mich fragen, warum die alten Pods noch laufen
7. Das Deployment löschen, frisch anwenden
8. Am nächsten Tag mit der gleichen Frustration wiederholen Wenn du jemals mit Kubernetes gearbeitet hast, kennst du diesen Schmerz. Es ist nicht so, dass kubectl apply kaputt ist — es funktioniert einwandfrei. Das Problem ist, dass es dich, den Menschen, in den kritischen Pfad jedes einzelnen Deployments stellt. Du wirst zur Pipeline. Und Menschen sind furchtbare Pipelines. Das tiefere Problem ist Drift. Du wendest ein Manifest an. Ein Teamkollege (oder die 2-Uhr-nachts-Version von dir selbst) macht eine schnelle manuelle Änderung mit kubectl edit. Jetzt hat der Zustand deines Clusters sich stillschweigend von dem entfernt, was in deinem Git Repo steht. Niemand bemerkt es, bis etwas kaputtgeht. Und wenn es kaputtgeht, viel Glück beim Herausfinden, ob der "korrekte" Zustand in Git, im Cluster oder in jemandes Terminal-Verlauf lebt. GitOps löst dieses Problem, indem es eine Regel nicht verhandelbar macht: Git ist Wahrheit. Der Cluster stimmt mit Git überein. Immer. Wenn sie abweichen, ändert sich der Cluster — nicht Git. Laut einer CNCF End User Survey von Mitte 2025 verlassen sich fast 60% der Kubernetes Cluster mittlerweile auf Argo CD für die Anwendungsbereitstellung. Diese Zahl steigt jedes Quartal. Und 97% der Befragten, die Argo CD nutzen, betreiben es in der Produktion — gegenüber 93% im Jahr 2023. Dies ist kein experimentelles Tool mehr. Es ist die Standard-Methode, mit der ernsthafte Teams auf Kubernetes deployen. Aber die meisten Anleitungen, die ich fand, gingen davon aus, dass man EKS oder GKE betreibt. Einen Produktionscluster mit ordentlichem Networking, Load Balancern und Ingress Controllern, die bereits konfiguriert sind. Ich wollte wissen: Funktioniert das auf Docker Desktop? Auf einem lokalen Cluster, wo man experimentiert, Dinge kaputtmacht und lernt? Die Antwort ist ja — mit einem wichtigen Workaround, den ich dir in Schritt zwei zeige.

Was Argo CD tatsächlich macht (Das mentale Modell, das zählt)

Bevor ich die Installation durchgehe, möchte ich dir das mentale Modell geben, das bei mir alles zum Klicken gebracht hat. Denn die Befehle sind einfach. Zu verstehen, warum sie funktionieren, unterscheidet jemanden, der Argo CD installiert, von jemandem, der es tatsächlich gut nutzt. Argo CD ist ein Kubernetes Controller. Es läuft in deinem Cluster als eine Reihe von Pods — ein Server, ein Repo Server, ein Application Controller und einige unterstützende Dienste. Einmal installiert, richtest du es auf ein Git Repository und sagst: "Dieses Verzeichnis enthält den gewünschten Zustand meiner Anwendung. Überwache es." Von diesem Moment an arbeitet Argo CD in einer kontinuierlichen Abgleichschleife:

1. Beobachten — Das Git Repo auf Änderungen pollen (oder Webhook-Benachrichtigungen empfangen)
2. Vergleichen — Den gewünschten Zustand in Git gegen den Live-Zustand im Cluster abgleichen
3. Handeln — Bei Abweichungen entweder warnen (manueller Sync) oder die Änderungen automatisch anwenden (Auto-Sync) Der dritte Schritt ist, wo die Magie liegt. Mit aktiviertem Auto-Sync wird der Workflow:

Push nach Git → Argo CD erkennt Änderung → Deployt automatisch → Heilt sich selbst bei Drift

Keine CI/CD Pipeline, die einen Deploy-Schritt auslöst. Kein Mensch, der Befehle ausführt. Du pushst Code, und der Cluster konvergiert, um übereinzustimmen. Die Feedback-Schleife ist so eng, dass sie meine gesamte Denkweise über Deployments verändert hat. Das hat es für mich konkret gemacht: Ich pushte ein Helm Chart Update zu meinem infrawhisper Repo um 23:15 Uhr. Um 23:15 Uhr und etwa acht Sekunden hatte Argo CD die Änderung bereits synchronisiert und die neuen Pods rollten aus. Ich habe nicht einmal meinen Code-Editor verlassen. Die Commit-Nachricht erschien im Argo CD Dashboard — feat(deploy): add Argo CD application manifest for GitOps deployment — und der Sync-Status zeigte "Sync OK." Dieses Maß an Unmittelbarkeit lässt manuelle Deploys anfühlen wie Deployment-Anweisungen per Brieftaube zu versenden. Noch etwas zum mentalen Modell. Argo CD deployt nicht nur. Es überwacht aktiv auf Drift. Wenn jemand (oder etwas) den Cluster-Zustand außerhalb von Git ändert — ein manuelles kubectl edit, ein unauthorisiertes Skript, eine versehentliche Löschung — erkennt Argo CD den Unterschied und korrigiert ihn. Der Cluster heilt sich selbst. Ich werde später in diesem Beitrag mit einem Live-Test beweisen, dass das funktioniert. Aber zuerst bringen wir es zum Laufen.

Die vollständige Einrichtung: Argo CD auf Docker Desktop Kubernetes

Voraussetzungen — Was du brauchst, bevor du anfängst

Du brauchst genau zwei Dinge:

• Docker Desktop mit aktiviertem Kubernetes (Einstellungen → Kubernetes → Enable Kubernetes → Apply & Restart). Ich verwende Docker Desktop auf macOS, aber die Schritte sind identisch auf Windows und Linux.
• kubectl konfiguriert und auf deinen Docker Desktop Cluster gerichtet. Überprüfe mit:

kubectl config current-context
# Sollte ausgeben: docker-desktop

Wenn du einen anderen Kontext siehst, wechsle mit kubectl config use-context docker-desktop. Du willst Argo CD nicht versehentlich auf einem Produktionscluster installieren. Frag mich, woher ich weiß, dass es sich lohnt, das zu überprüfen. Das war's. Kein Helm für die Basisinstallation nötig. Kein Cloud-Provider-Konto. Kein Load Balancer. Docker Desktops integriertes Kubernetes reicht aus.

Schritt 1 — Argo CD in deinen Cluster installieren

Zwei Befehle. Der erste erstellt einen dedizierten Namespace. Der zweite lädt die offiziellen Argo CD Manifeste herunter und installiert alles.

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

Dies installiert Argo CD v3.3.4 (das stabile Release vom März 2026), einschließlich PreDelete Hooks, OIDC Hintergrund-Token-Aktualisierung, erweiterter RBAC Controls und KEDA Integration. Das Manifest deployt mehrere Komponenten in den argocd Namespace:

• argocd-server — Der API Server und die Web-UI
• argocd-repo-server — Klont und verarbeitet deine Git Repos
• argocd-application-controller — Die Abgleich-Engine, die auf Drift überwacht
• argocd-redis — Caching-Schicht
• argocd-dex-server — SSO Authentifizierung (optional für lokale Setups) Warte etwa 60-90 Sekunden, bis alle Pods den Running-Status erreichen. Du kannst ihnen beim Starten zusehen:

kubectl get pods -n argocd -w

Wenn du fünf oder sechs Pods siehst, die alle 1/1 Running anzeigen, bist du bereit für den nächsten Schritt. Und der nächste Schritt ist derjenige, der mich gute zwanzig Minuten aufgehalten hat.

Schritt 2 — NetworkPolicies entfernen (Die Docker Desktop Falle)

Dies ist der Schritt, den keine "Quick Start"-Anleitung erwähnte. Ich installierte Argo CD, versuchte die UI aufzurufen, und bekam nichts. Connection refused. Timeout. Die Pods liefen, der Service existierte, aber Port-Forwarding... funktionierte einfach nicht. Nach zwanzig Minuten Überprüfung von Service Selectors und Pod Logs fand ich das Problem: Argo CD wird mit NetworkPolicy Ressourcen ausgeliefert, die den Traffic zwischen seinen Komponenten einschränken. Auf einem echten Cluster mit einem CNI Plugin, das NetworkPolicies unterstützt (Calico, Cilium, etc.), funktionieren diese perfekt. Auf Docker Desktops integriertem Kubernetes-Networking? Sie zerstören stillschweigend alles. Docker Desktops Standard-CNI erzwingt keine NetworkPolicies, aber die Policies werden trotzdem erstellt und können die Service Discovery auf subtile Weise stören. Die Lösung ist einfach:

kubectl delete networkpolicies --all -n argocd

Das war's. Ein Befehl. Zwanzig Minuten meines Lebens, die ich nicht zurückbekomme. Ich schreibe das auf, damit du nicht die gleichen zwanzig Minuten verlierst.

Danach funktioniert Port-Forwarding sofort. Wenn du einen echten Cluster mit Calico oder Cilium betreibst, überspringe diesen Schritt — du willst diese Policies behalten.

Schritt 3 — Zugang zum Argo CD Dashboard

Jetzt machst du den Argo CD Server für deine lokale Maschine zugänglich:

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

Öffne deinen Browser und navigiere zu https://localhost:8443. Du bekommst eine Zertifikatswarnung — das ist bei einem selbstsignierten Zertifikat auf localhost zu erwarten. Klicke dich durch. Du solltest den Argo CD Anmeldebildschirm sehen. Sauber. Minimalistisch. Diese dunkle UI, die signalisiert: "Das ist ein ernsthaftes Tool."

Schritt 4 — Deine Anmeldedaten abrufen

Der Standard-Benutzername ist admin. Das initiale Passwort wird automatisch generiert und als Kubernetes Secret gespeichert. Extrahiere es mit:

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

Kopiere diese Ausgabe — das ist dein temporäres Passwort. Melde dich mit admin und dem dekodierten Passwort an. Profi-Tipp: Ändere dieses Passwort sofort nach der ersten Anmeldung, besonders wenn jemand anderes Zugang zu deinem Netzwerk hat. In einer lokalen Entwicklungsumgebung ist es weniger kritisch, aber gute Gewohnheiten aufzubauen ist wichtig. Du kannst es über die Argo CD CLI oder in der UI unter User Info → Update Password ändern. An diesem Punkt hast du eine voll funktionsfähige Argo CD Installation, die auf deinem lokalen Kubernetes Cluster läuft. Das Dashboard ist leer — noch keine Anwendungen. Das ändert sich jetzt.

Schritt 5 — Dein Application Manifest erstellen

Hier verbindet sich Argo CD mit deinem Git Repository und beginnt, deine Deployments zu verwalten. Du brauchst ein Application Manifest — eine Kubernetes Custom Resource, die Argo CD sagt, was es überwachen und wo es deployen soll. Hier ist das Manifest, das ich für mein infrawhisper Projekt verwendet habe:

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

Lass mich erklären, was jeder Abschnitt macht, denn das Verständnis dieser Felder spart dir später Stunden beim Debuggen: source — Wo Argo CD nach deinen Manifesten suchen soll:

• repoURL: Dein Git Repository (öffentliche Repos funktionieren sofort; private Repos benötigen konfigurierte Zugangsdaten in den Argo CD Einstellungen)
• targetRevision: Welcher Branch verfolgt werden soll. Ich verwende main, aber du kannst dies auf jeden Branch, Tag oder Commit SHA richten
• path: Das Verzeichnis innerhalb des Repos, das deine Kubernetes Manifeste oder dein Helm Chart enthält
• helm.valueFiles: Wenn du Helm verwendest (ich tat es), gibt dies an, welche Values-Datei angewendet werden soll destination — Wohin Argo CD deployen soll:
• server: Die Kubernetes API Server URL. https://kubernetes.default.svc bedeutet "deploye in denselben Cluster, in dem Argo CD läuft." Für lokale Setups ist das immer, was du willst.
• namespace: Der Ziel-Namespace für die Ressourcen deiner Anwendung syncPolicy — Wie sich Argo CD verhalten soll:
• automated: Aktiviert Auto-Sync. Ohne dies müsstest du jedes Mal manuell "Sync" in der UI klicken
• prune: true: Wenn du eine Ressource aus Git entfernst, entfernt Argo CD sie aus dem Cluster. Ohne dies hinterlassen gelöschte Manifeste verwaiste Ressourcen
• selfHeal: true: Das ist der wichtigste Punkt. Wenn jemand oder etwas den Cluster-Zustand außerhalb von Git ändert, macht Argo CD es rückgängig. Dein Cluster stimmt immer mit Git überein.
• CreateNamespace=true: Argo CD erstellt den Ziel-Namespace, wenn er nicht existiert Speichere dies als application.yaml in deinem Projektverzeichnis. Passe repoURL, path und namespace an dein tatsächliches Setup an.

Schritt 6 — Deployen und die Magie beobachten

Wende das Manifest an:

kubectl apply -f application.yaml

Wechsle jetzt zu deinem Argo CD Dashboard unter https://localhost:8443. Innerhalb von Sekunden sollte deine Anwendung erscheinen. Argo CD beginnt sofort mit der Synchronisierung — dein Repo klonen, das Helm Chart rendern (oder einfache Manifeste), und die Ressourcen auf deinen Cluster anwenden. Für mein infrawhisper Projekt leuchtete das Dashboard mit der gesamten Anwendungstopologie auf: api-server mit 3 Pods, Dashboard mit 2 Pods, ai-engine mit 2 Pods, stream-processor mit 2 Pods, collector mit 2 Pods, plus infrawhisper-agent und Ingress Controller. Alles sichtbar in einer Netzwerkansicht. Der Commit-Hash 776a48f von meinem letzten Push war direkt in der UI zu sehen, mit der Commit-Nachricht, die ich Minuten zuvor geschrieben hatte.

Die Docker Desktop Containerliste erzählte die gleiche Geschichte aus einer anderen Perspektive — 38 laufende Container, mit den argocd Komponenten neben meinen Anwendungs-Pods: ai-engine, api-server, clickhouse, collector, dashboard, kafka, postgres, redis, stream-processor. Eine vollständige Datenplattform, die lokal läuft, vollständig über Git verwaltet.

Das ist die Einrichtung. Sechs Schritte, unter zehn Minuten. Aber die Einrichtung ist nur das Fundament. Die eigentliche Frage ist: Funktioniert es tatsächlich so, wie die Dokumentation es verspricht? Ich habe drei Tests durchgeführt, um das herauszufinden.

Der Selbstheilungstest: Einen Pod absichtlich löschen

Hier ist der Test, den ich durchgeführt habe, um zu beweisen, dass Selbstheilung auf einem lokalen Cluster funktioniert. Meine infrawhisper Dashboard-Komponente lief mit 2 Replica Pods. Ein bestimmter Pod — dashboard-75fd8b8ddb-55x9h — lief seit 11 Tagen stabil und gesund. Stabil, Traffic bedienend, seine Arbeit erledigend. Ich habe ihn gelöscht.

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

Dann beobachtete ich. Nicht das Argo CD Dashboard — ich beobachtete das Terminal. Innerhalb von sechs Sekunden:

• VORHER: dashboard-75fd8b8ddb-55x9h — Running, Alter: 11 Tage
• GELÖSCHT: Pod beendet
• NACHHER: dashboard-75fd8b8ddb-lt5bn — Running, Alter: 6 Sekunden Ein brandneuer Pod, anderer Name, gleiche Spezifikation. Kubernetes' ReplicaSet Controller übernahm den sofortigen Ersatz (das ist Standard-Kubernetes-Verhalten). Aber hier ist der entscheidende Punkt: Argo CDs Abgleichschleife bestätigte, dass der Cluster-Zustand immer noch mit dem gewünschten Zustand in Git übereinstimmte. Hätte die Pod-Löschung dazu geführt, dass das gesamte Deployment von Gits Definition abgewichen wäre — etwa wenn jemand die Replicas manuell herunterskaliert hätte — hätte Argo CD auch das erkannt und korrigiert. Das ist keine hypothetische Resilienz. Sie ist messbar. Ich habe es auf meinem Laptop geschehen sehen, auf einem lokalen Cluster, mit Tools, die du in zehn Minuten installieren kannst. Die tiefere Erkenntnis brauchte einen Tag, um einzusinken. Mit aktivierter Selbstheilung sind deine Deployment-Manifeste in Git nicht einfach nur Konfigurationsdateien. Sie sind ein Vertrag. Ein Versprechen darüber, wie der Cluster zu jeder Zeit aussehen sollte. Brich den Vertrag manuell, und das System setzt ihn automatisch durch. Dieser Paradigmenwechsel — von "ich deploye Dinge" zu "ich deklariere Dinge und das System pflegt sie" — ist der Kern von GitOps. Und es fühlt sich völlig anders an, wenn du es einmal selbst erlebst.

Drift-Erkennung: Der stille Wächter

Der Selbstheilungstest deckt versehentliche Löschungen ab. Aber was ist mit absichtlichen manuellen Änderungen? Die Art, die passiert, wenn jemand um 3 Uhr morgens kubectl edit deployment ausführt, um etwas "schnell zu fixen" in der Produktion? Ich habe das getestet, indem ich mein api-server Deployment manuell von 3 Replicas auf 1 skaliert habe:

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

Für etwa fünfzehn Sekunden hatte der Cluster 1 api-server Pod statt der 3, die in meinem Git Repo definiert waren. Dann erkannte Argo CDs Abgleichschleife die Abweichung, verglich den Live-Zustand mit Git und skalierte zurück auf 3. Kein Alarm. Kein manuelles Eingreifen. Das Argo CD Dashboard zeigte den App-Zustand kurz als "Degraded" an (was korrekt ist — weniger Replicas als gewünscht zu betreiben ist degradiert) und wechselte dann zurück zu "Healthy", sobald die Abgleichung abgeschlossen war. Dieses Verhalten macht GitOps transformativ für Teams. Es verhindert nicht nur Probleme — es korrigiert sie aktiv. Und es erstellt einen Audit-Trail. Jede Sync-Operation erscheint in Argo CDs Verlauf. Du kannst genau sehen, wann Drift aufgetreten ist und wann er korrigiert wurde. Versuch das mal mit kubectl apply hinzubekommen.

Auto-Sync: Push nach Git, dem Deployment zusehen

Der dritte Test war der einfachste und befriedigendste. Ich änderte einen Wert in der values.yaml meines Helm Charts — erhöhte die Dashboard Replica-Anzahl von 2 auf 3 — committete und pushte nach main. Ich hatte das Argo CD Dashboard im Browser offen und mein Terminal mit kubectl get pods -n my-app -w nebeneinander. Innerhalb von etwa fünfzehn Sekunden nach dem Push erkannte Argo CD den neuen Commit, holte das aktualisierte Chart, renderte die Manifeste und wendete die Änderung an. Ein dritter Dashboard-Pod begann hochzufahren, während ich zusah. Der Sync-Status im Dashboard aktualisierte sich, um den neuen Commit-Hash anzuzeigen. Die Commit-Nachricht, die ich gerade geschrieben hatte, stand direkt in der UI. Keine Pipeline. Keine Webhook-Konfiguration. Kein Deploy-Skript. Ich pushte Code und der Cluster änderte sich. Das ist das Versprechen von GitOps, und auf einem lokalen Docker Desktop Cluster mit Argo CD v3.3.4 wurde es genau wie angekündigt eingelöst.

Was Argo CD richtig macht — Und wo es ehrlich ist

Nachdem ich dieses Setup mehrere Tage auf meinem infrawhisper Projekt betrieben habe, hier ist meine ehrliche Einschätzung. Was wirklich beeindruckend ist:

• Das Dashboard allein ist die Installation wert. Die gesamte Anwendungstopologie zu sehen — jedes Deployment, jeden Service, jeden Pod und jeden Ingress — in einer visuellen Karte ist etwas, das kubectl dir nie geben kann. Für mein infrawhisper Projekt mit seinen über zwölf Komponenten ging das in etwa drei Stunden von "nett zu haben" zu "wie habe ich jemals ohne das gearbeitet."
• Die Sync-Geschwindigkeit ist real. Ich erwartete Minuten. Ich bekam Sekunden. Die Verzögerung zwischen Push nach Git und der Änderung live im Cluster war auf meinem lokalen Setup konstant unter 20 Sekunden.
• Rollback ist ein Klick. Argo CD speichert einen Verlauf jeder Synchronisierung. Wenn ein Deployment schiefgeht, klickst du auf "Rollback" und wählst einen vorherigen Commit. Der Cluster kehrt zurück. Versuch das mal mit kubectl apply und einem Gebet.
• Helm Chart Rendering wird für dich erledigt. Ich musste lokal weder helm template noch helm install ausführen. Argo CDs repo-server rendert das Chart und wendet die Ausgabe an. Das bedeutet, dein Git Repo braucht nur den Chart-Quellcode — Argo CD übernimmt den Rest. Was ich mir gewünscht hätte, dass mir jemand gesagt hätte:
• Der Ressourcen-Overhead ist nicht trivial. Auf Docker Desktop fügten die Argo CD Komponenten etwa 500MB-700MB RAM-Verbrauch und mehrere CPU-Kerne an Hintergrundaktivität hinzu. Auf einer modernen Maschine ist das kein Problem. Auf einem älteren Laptop spürst du es. Mein Docker Desktop lief bereits mit 38 Containern für den infrawhisper Stack — Argo CDs Pods obendrauf brachten den Gesamtspeicherverbrauch über 8GB.
• Private Repos erfordern zusätzliche Konfiguration. Wenn dein Git Repository privat ist (die meisten sind es), musst du Repository-Zugangsdaten in Argo CDs Einstellungen konfigurieren. Das umfasst entweder einen SSH Key, einen Personal Access Token oder eine GitHub App. Die offizielle Dokumentation behandelt das gut, aber es ist ein zusätzlicher Schritt, den die "Zwei-Befehl-Installation"-Anleitungen praktischerweise auslassen.
• Der Workflow für das initiale Admin-Passwort ist umständlich. Base64-Dekodierung eines Kubernetes Secrets, um sein erstes Passwort zu erhalten, funktioniert, aber es ist keine großartige Entwicklererfahrung. Ich würde mir einen interaktiven Setup-Assistenten für lokale Installationen wünschen.
• NetworkPolicies auf Docker Desktop sind echte Zeitfresser. Ich habe das bereits in den Setup-Schritten behandelt, aber es lohnt sich zu wiederholen: Wenn du auf Docker Desktop läufst und Dinge sich nicht verbinden, lösche zuerst die NetworkPolicies. Dieses einzelne Problem verursacht wahrscheinlich mehr abgebrochene lokale Argo CD Setups als jeder tatsächliche Bug. Wenn du lieber jemanden hättest, der diese Art von Infrastruktur von Grund auf aufbaut — Kubernetes Cluster, GitOps Pipelines, den gesamten Platform-Engineering-Stack — übernehme ich DevOps- und Cloud-Engineering-Projekte. Du kannst sehen, was ich gebaut habe unter fiverr.com/s/EgxYmWD.

Wo das in einen echten Workflow passt

Argo CD lokal zu betreiben ist nicht nur eine Lernübung. Es ist die erste Stufe eines Workflows, der direkt in die Produktion skaliert. Hier ist die Progression, die ich für mein infrawhisper Projekt plane: Stufe 1 (wo ich jetzt bin): Lokaler Docker Desktop Cluster mit Argo CD, das Helm Deployments verwaltet. Perfekt für Entwicklung, Testen des Sync-Verhaltens und Validierung von Manifesten, bevor sie einen echten Cluster berühren. Stufe 2: Dieselben Manifeste — unverändert — auf einen Staging-Cluster auf AWS EKS oder einen selbstverwalteten Cluster verschieben. Argo CDs Application Manifest bleibt identisch. Nur der destination.server ändert sich. Stufe 3: Produktions-Deployment mit Argo CD, das mehrere Umgebungen über ApplicationSets verwaltet. Dasselbe Git Repo, verschiedene Values-Dateien pro Umgebung, Argo CD übernimmt das Rollout für jede. Die zentrale Erkenntnis: Das Application Manifest, das ich in Schritt 5 dieser Anleitung geschrieben habe, ändert sich zwischen den Stufen nicht. Das Helm Chart ändert sich nicht. Die Sync-Policy ändert sich nicht. Ich baue den Produktions-Workflow jetzt, auf meinem Laptop, mit denselben Tools, die ich verwenden werde, wenn infrawhisper live geht. Das ist kein Nebeneffekt von lokalem Argo CD — es ist der Hauptvorteil. Platform Engineers repräsentieren laut der CNCF Survey mittlerweile 37% der Argo CD Nutzer, und genau deshalb. Die Muster, die du lokal etablierst, tragen direkt bis in die Produktion. Es gibt keinen "schreib die Deployment Pipeline um"-Schritt, wenn du bereit bist zu deployen.

Die fünf Dinge, die Argo CD dir gibt, die kubectl apply niemals bieten wird

Nachdem ich mit diesem Setup gelebt habe, kann ich genau beschreiben, was sich geändert hat. Nicht in abstrakten Begriffen — in konkreten, täglichen Workflow-Begriffen: 1. Auto-Sync eliminiert den Deploy-Schritt vollständig. Push nach Git. Geh weg. Der Cluster aktualisiert sich. Das klingt geringfügig, bis du realisierst, wie oft am Tag du kubectl apply ausführst. Bei mir waren es 15-20 Mal während aktiver Entwicklung. Jedes Mal ein Kontextwechsel, ein Terminal-Fenster, eine Chance, das falsche Manifest auf den falschen Namespace anzuwenden. Alles weg. 2. Selbstheilung fängt Fehler auf, die du nie bemerken würdest. Versehentliche Pod-Löschungen. Unauthorisierte Skripte. Falsch konfigurierte Autoscaler. Argo CD erkennt Drift und korrigiert ihn. Auf meinem infrawhisper Stack mit 10+ Microservices ist das kein Luxus — es ist der Unterschied zwischen einer stabilen lokalen Umgebung und einer, die langsam verrottet. 3. Drift-Erkennung schafft Verantwortlichkeit. Jede manuelle Änderung wird rückgängig gemacht und protokolliert. Das ist Sicherheit und betriebliche Hygiene in einem. Du kannst sehen, wer (oder was) den Cluster geändert hat, wann, und wie Argo CD es korrigiert hat. 4. Das visuelle Dashboard ersetzt ein Dutzend kubectl-Befehle. Pod-Status, Replica-Anzahlen, Health Checks, Sync-Verlauf, Anwendungstopologie — alles in einem Browser-Tab. Ich führte früher kubectl get pods, kubectl get svc, kubectl describe deployment und kubectl logs in schneller Folge aus, nur um den Zustand meines Clusters zu verstehen. Jetzt werfe ich einen Blick auf das Argo CD Dashboard. 5. Rollback wird ein einzelner Klick. Nicht "finde den letzten funktionierenden Commit, checke das Manifest aus, wende es an, überprüfe ob es funktioniert hat." Ein Klick. Commit auswählen. Fertig. Für ein Projekt wie infrawhisper mit voneinander abhängigen Services rechtfertigt das allein die Einrichtung.

Was ich beim nächsten Mal anders machen würde

Wenn ich das alles von Grund auf neu einrichten würde, würden sich drei Dinge ändern: Ich würde die Argo CD CLI von Anfang an installieren. Die Web-UI ist großartig für die Visualisierung, aber die CLI (argocd) ist schneller für das Verwalten von Anwendungen, Synchronisieren und Status-Überprüfung vom Terminal aus. Ich habe sie anfangs nicht installiert, weil ich das Setup minimal halten wollte, und bereute es innerhalb eines Tages. Installiere sie mit:

brew install argocd

Ich würde ApplicationSets von Tag eins an verwenden. Mein infrawhisper Projekt hat ein einzelnes Application Manifest, aber wenn ich weitere Umgebungen hinzufüge (Staging, Produktion), brauche ich eine Application pro Umgebung. ApplicationSets ermöglichen es dir, Application Ressourcen zu templaten — eine Definition, die mehrere Applications basierend auf Parametern generiert. Früh mit diesem Muster zu beginnen spart eine Migration später. Ich würde Repository-Zugangsdaten sofort konfigurieren. Ich habe mit einem öffentlichen Repo-Fork zum Testen begonnen und bin dann zu meinem tatsächlichen privaten Repo gewechselt. Der Schritt zur Konfiguration der Zugangsdaten hat meinen Flow unterbrochen. Richte es zuerst ein, auch wenn dein Repo derzeit öffentlich ist. Dein zukünftiges Ich wird es dir danken.

Los geht's: Die Zehn-Minuten-Checkliste

Hier ist die komprimierte Version. Wenn du alles oben gelesen hast und einfach die Schritte auf einem Bildschirm willst:

# 1. Überprüfe deinen Kubernetes Kontext
kubectl config current-context  # Sollte sein: docker-desktop
# 2. Installiere Argo CD
kubectl create namespace argocd
kubectl apply -n argocd -f \
  https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
# 3. Warte auf Pods (etwa 60-90 Sekunden)
kubectl get pods -n argocd -w
# 4. Entferne NetworkPolicies (nur Docker Desktop!)
kubectl delete networkpolicies --all -n argocd
# 5. Port-Forward die UI
kubectl port-forward svc/argocd-server -n argocd 8443:443
# 6. Hole Admin-Passwort
kubectl -n argocd get secret argocd-initial-admin-secret \
  -o jsonpath="{.data.password}" | base64 -d
# 7. Anmelden unter https://localhost:8443 (admin + dekodiertes Passwort)
# 8. Wende dein Application Manifest an
kubectl apply -f application.yaml

Acht Befehle. Unter zehn Minuten. Eine voll funktionsfähige GitOps Pipeline, die auf deinem Laptop läuft. Argo CD unterstützt Helm Charts, Kustomize, Jsonnet und einfache YAML Manifeste — egal welches Deployment-Format du derzeit verwendest, es fügt sich ohne Umschreiben ein. Für mein infrawhisper Projekt verwendete ich Helm, weil das Chart bereits für parametrisierte Deployments strukturiert war. Aber wenn du ein Verzeichnis mit reinen YAML Manifesten hast, richte einfach den source.path der Application auf dieses Verzeichnis und entferne den helm-Abschnitt. Argo CD erledigt den Rest.

Häufig gestellte Fragen

Funktioniert Argo CD mit Docker Desktop Kubernetes?

Ja. Argo CD läuft auf Docker Desktops integriertem Kubernetes mit einem erforderlichen Workaround: Lösche die Standard-NetworkPolicies im argocd Namespace, da Docker Desktops CNI diese nicht korrekt verarbeitet. Danach funktionieren alle Funktionen — Auto-Sync, Selbstheilung, Drift-Erkennung und das Web-Dashboard — identisch zu cloud-gehosteten Clustern.

Wie viel RAM verbraucht Argo CD auf einem lokalen Cluster?

Rechne mit 500MB-700MB zusätzlichem RAM für die Argo CD Control Plane Komponenten (Server, repo-server, application-controller, redis, dex). Auf einer Maschine mit 16GB+ RAM ist das vernachlässigbar. Auf 8GB-Maschinen mit anderen schweren Workloads musst du möglicherweise Resource Limits in den Argo CD Manifesten anpassen.

Kann Argo CD aus einem privaten Git Repository deployen?

Ja, aber du musst zuerst Repository-Zugangsdaten in Argo CDs Einstellungen konfigurieren. Optionen umfassen SSH Keys, Personal Access Tokens oder GitHub Apps. Konfiguriere dies über die Argo CD UI (Settings → Repositories) oder über die argocd CLI, bevor du dein Application Manifest erstellst.

Was passiert, wenn ich manuell etwas im Cluster ändere?

Mit selfHeal: true in der Sync-Policy deiner Application erkennt Argo CD die Abweichung und setzt den Cluster automatisch zurück, um mit Git übereinzustimmen. Das Dashboard zeigt die Anwendung kurz als "OutOfSync" oder "Degraded" an und korrigiert sie dann innerhalb des nächsten Abgleichzyklus (typischerweise unter 30 Sekunden). Das Drift-Ereignis wird im Sync-Verlauf für Auditing protokolliert.

Ist das lokale Argo CD Setup dasselbe wie in der Produktion?

Nahezu identisch. Das Application Manifest, die Sync-Policies und die Helm Chart Konfiguration lassen sich direkt auf einen Produktionscluster übertragen. Die einzigen Änderungen sind die destination.server URL (die auf deinen Produktionscluster statt auf kubernetes.default.svc zeigt) und umgebungsspezifische Values-Dateien. Das ist eines der stärksten Argumente, lokal zu beginnen — du baust Produktionsmuster von Tag eins an auf.

Lass uns zusammenarbeiten

Du möchtest KI-Systeme aufbauen, Workflows automatisieren oder deine technische Infrastruktur skalieren? Ich helfe gerne.

• Fiverr (individuelle Builds & Integrationen): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (Enterprise-Lösungen): ramlit.com
• ColorPark (Design & Branding): colorpark.io
• xCyberSecurity (Sicherheitsdienste): xcybersecurity.io