mathias2784/it-know-how
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
aec523a38c494d70d346b3450db3317304709252
it-know-how/web und cloud gedoens/Argo CD.md
T
Mathias Schneider 8d40597732 init at work
2026-03-27 12:58:01 +01:00

11 KiB
Executable File
Raw Blame History

Hier ist eine umfassende Einführung in Argo CD – verständlich, aber fachlich fundiert.

1. Was ist Argo CD?

Argo CD ist ein GitOps-Tool für Kubernetes. Es sorgt dafür, dass der Zustand eines Kubernetes-Clusters immer mit dem übereinstimmt, was in einem Git-Repository als „Wahrheit“ definiert ist.

Kerneigenschaften:

  • Git-zentriert: Git als Single Source of Truth (Manifest-Dateien, Helm-Charts, Kustomize, etc.)
  • Deklarativ: Der gewünschte Zustand (desired state) ist beschrieben, nicht programmiert
  • Kontinuierliche Synchronisierung: Änderungen in Git werden automatisch oder manuell im Cluster ausgerollt
  • Visuell: Web UI mit Übersicht über Applikationen, Health-Status, Diffs, History
  • Mehrcluster-fähig: Kann mehrere Kubernetes-Cluster verwalten

2. GitOps – der Kontext von Argo CD

Argo CD implementiert das GitOps-Konzept:

  • Infrastruktur & Deployments im Git (Manifest-Dateien, Helm Values, Kustomize Overlays, etc.)
  • Pull-basiert: Argo CD „zieht“ den Zustand regelmäßig aus Git und gleicht ihn mit dem Cluster ab.
  • Versioniert & auditiert: Jede Änderung ist ein Git-Commit, inkl. History, Review, Rollback-Möglichkeit
  • Automatisierte Drift-Erkennung: Unterschiede zwischen Git und Cluster werden erkannt und gemeldet

Vorteile von GitOps mit Argo CD:

  • Reproduzierbare Deployments
  • Besseres Change-Management (Git-Workflows, PRs)
  • Weniger manuelle „kubectl apply“-Befehle
  • Klare Trennung von Build (CI) und Deployment (CD)

3. Architektur von Argo CD

3.1 Hauptkomponenten

  • argocd-server

    • Stellt die Web UI und das gRPC/REST-API bereit
    • Authentifizierung (lokale User, SSO via OIDC, etc.)
    • Kommunikation mit CLI (argocd CLI) und UI

  • argocd-repo-server

    • Greift auf Git-Repositories zu
    • Rendert Manifeste (z.B. Helm, Kustomize, Jsonnet)
    • Führt Template-Engines und „Config Management Plugins“ aus

  • argocd-application-controller

    • Herzstück des Sync-Mechanismus
    • Vergleicht desired state (Git) mit live state (Cluster)
    • Führt Syncs, Health-Checks und Rollbacks aus

  • argocd-redis (optional, in vielen Installationen vorhanden)

    • Cache für Repositories und Application-Informationen

Diese Komponenten laufen typischerweise im Namespace argocd im Cluster.

3.2 Target Cluster

Argo CD kann:

  • Den Cluster, in dem es selbst läuft, verwalten
  • Externe Cluster (z.B. Staging, Prod) als zusätzliche „Cluster Secrets“ anbinden

4. Zentrale Konzepte

4.1 Application

Die zentrale Ressource in Argo CD ist eine CRD namens Application (kind: Application).

Eine Application beschreibt:

  • Quelle (source): Woher kommen die Manifeste?
    • Git-Repository / Helm-Repo / Kustomize-Ordner
    • Pfad im Repo
    • ggf. Helm-Chart und Values
  • Ziel (destination):
    • Zu verwaltender Kubernetes-Cluster
    • Ziel-Namespace
  • Sync-Strategie & -Optionen:
    • Automatische Synchronisierung (auto sync) oder manuell
    • Verhalten bei Fehlern, Prune, Self-Heal etc.

Ein minimaler Application-Beispiel (vereinfachtes YAML):

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/mein-org/mein-repo.git
    targetRevision: main
    path: kubernetes/my-app
  destination:
    server: https://kubernetes.default.svc
    namespace: my-app
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

4.2 Sync-Status & Health-Status

Für jede Application zeigt Argo CD zwei wesentliche Zustände:

  • Sync-Status:
    • Synced: Cluster-Zustand entspricht Git-Zustand
    • OutOfSync: Unterschiede zwischen Git und Cluster
  • Health-Status:
    • Healthy: Anwendung läuft wie erwartet (z.B. alle Pods bereit)
    • Degraded: Fehlerzustände (CrashLoop, fehlende Ressourcen etc.)
    • Progressing: Deployment läuft noch, noch nicht stabil

Health-Checks sind ressourcentyp-spezifisch (Deployments, StatefulSets, CRDs etc.).

4.3 Drift-Erkennung

Argo CD vergleicht:

  • Desired state: Manifeste, die aus Git gerendert wurden
  • Live state: Tatsächliche Ressourcen im Cluster

Wenn jemand manuell kubectl apply oder kubectl edit verwendet, entsteht „Drift“. Argo CD:

  • Markiert den Status als OutOfSync
  • Kann bei selfHeal: true diese Änderungen automatisch wieder rückgängig machen (zurück auf Git-Zustand)

5. Unterstützte Werkzeuge & Formate

Argo CD unterstützt u.a.:

  • Plain YAML-Manifeste
  • Helm (Charts, Values)
  • Kustomize
  • Jsonnet
  • Ksonnet (legacy)

Außerdem:

  • Config Management Plugins (CMP): Eigene Tools/Pipelines zum Manifest-Rendering integrierbar
  • Multiple Sources: Neuere Versionen unterstützen mehrere Quellen pro Application (z.B. App-Manifeste + separate Helm-Values)

6. Installation & erste Schritte

6.1 Installation

Typische Wege:

  • kubectl apply eines offiziellen Install-Manifests:
    • z.B. https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
  • Helm-Chart (empfohlen für produktivere Setups)
  • Operator-Lösungen in manchen Distributionen

Nach der Installation:

  • Argo CD läuft im Namespace argocd
  • UI via argocd-server (LoadBalancer, Ingress oder Port-Forward)
  • Erstlogin meist über das Passwort aus dem argocd-initial-admin-secret

6.2 CLI

Das CLI-Tool argocd erlaubt:

  • Login: argocd login <server>
  • Erstellung von Applications: argocd app create ...
  • Manuelles Syncen: argocd app sync my-app
  • Status anzeigen, Diffs, Rollbacks etc.

7. Deployment-Strategien & Sync-Policies

7.1 Manuelles vs. automatisches Syncen

  • Manuell:
    • Änderungen in Git werden erkannt, aber nur als OutOfSync markiert
    • Deploy erfolgt erst nach argocd app sync (CLI/UI)
  • Automatisch (auto sync):
    • Argo CD führt bei Änderungen in Git automatisch ein Sync aus
    • Option prune entfernt Ressourcen, die in Git gelöscht wurden
    • Option selfHeal korrigiert Drift im Cluster

7.2 Sync-Optionen

  • Sync-Wellen (Sync Waves):
    • Steuerung der Reihenfolge via argocd.argoproj.io/sync-wave Annotation
  • Sync-Hooks:
    • Vor-/Nachschaltbare Hooks (PreSync, PostSync, SyncFail etc.)
    • Realisiert mit bestimmten Kubernetes-Resourcen und Annotationen

8. Projekte (AppProjects) & Multi-Tenancy

Die CRD AppProject erlaubt die logische Gruppierung und Begrenzung von Applications.

Funktionen von AppProjects:

  • Einschränkung von:
    • Erlaubten Git-Repositories
    • Erlaubten Ziel-Cluster / Namespaces
    • Erlaubten Ressourcentypen
  • Gemeinsame Policies & RBAC für eine Gruppe von Apps
  • Sinnvoll für Multi-Tenancy:
    • z.B. ein Project pro Team, Produkt oder Mandant

9. Sicherheit & RBAC

9.1 Authentifizierung

  • Lokale Benutzer in Argo CD (Admin, weitere User)
  • Single Sign-On via:
    • OIDC (z.B. Keycloak, Dex, Azure AD, Okta)
    • SAML (über OIDC-Integrationen)
  • Tokens für Automatisierung (CI-Systeme, Bots)

9.2 Autorisierung (RBAC)

Argo CD hat ein eigenes RBAC-System:

  • Rollen (z.B. role:readonly, role:admin, benutzerdefinierte Rollen)
  • Zuordnung von Rollen zu Subjekten (User, Gruppen)
  • Rechte auf:
    • Anwendungen (lesen, syncen, löschen)
    • Projekte
    • Cluster, Repos
  • Granulare Steuerung:
    • z.B. „Team A darf nur Apps in Project X syncen“

10. Typische Patterns: App-of-Apps & Monorepo/Multirepo

10.1 App-of-Apps Pattern

Ein häufiges Muster ist die „Application of Applications“:

  • Eine „Root-Application“, deren Manifeste nur aus anderen Application-Ressourcen bestehen
  • Diese Root-App definiert alle anderen Applikationen/Umgebungen
  • Vorteile:
    • Zentrales Entry-Point
    • Environments (dev/stage/prod) als Under-Apps
    • Bessere Struktur bei vielen Services

10.2 Repository-Strukturen

  • Monorepo:
    • Alle Manifeste aller Services und Environments in einem Git-Repo
  • Multirepo:
    • Pro Service oder Team ein eigenes Repo
    • Infrastruktur/Plattform in separaten Repos
  • Argo CD unterstützt beide Modelle – Entscheidung ist organisatorisch/architektonisch.

11. Integration in CI/CD-Pipelines

Argo CD übernimmt in einem klassischen Setup die CD-Rolle:

  • CI-Pipeline (z.B. GitLab CI, GitHub Actions, Jenkins):
    • Buildet Container-Images
    • Pusht Images in ein Registry
    • Aktualisiert Versionsnummern/Tags in den Git-Manifesten (Deployment-Repo)
  • Argo CD:
    • Erkennt Änderungen im Git-Repo
    • Deployt diese in den Cluster

Dadurch entsteht eine klare Trennung:

  • CI = Builds, Tests, Image-Erzeugung
  • CD = Versionswechsel im Git + Argo CD Sync

12. Monitoring & Observability

  • Argo CD bietet:
    • Events & Logs (Application-Controller, Repo-Server etc.)
    • Metriken (Prometheus-Exporter) für:
      • Anzahl Apps, Sync-Status, Health
      • Dauer von Syncs
      • Fehler, Retries
  • Integration mit:
    • Prometheus/Grafana (Dashboards für Argo CD)
    • Alerting auf Drift, Degradation, Sync-Fehler

13. Best Practices

Einige bewährte Vorgehensweisen:

  1. Git als einzige Wahrheit
    • Keine manuellen Änderungen via kubectl in produktiven Namespaces
  2. Automatisches Syncen mit Self-Heal (mindestens in lower Environments)
  3. Trennung von Image-Build-Repo und Deployment-Repo
  4. AppProjects pro Team/Domain zur Strukturierung und Begrenzung
  5. RBAC sauber definieren:
    • Admin-Rechte nur für wenige
    • Team-spezifische Rollen
  6. Health-Konfigurationen pflegen:
    • Custom Health Checks für eigene CRDs, falls nötig
  7. Klare Namenskonventionen für Applications, Projekte und Repos
  8. App-of-Apps für große Landschaften:
    • z.B. cluster-bootstrap Application, die alle anderen Apps initialisiert

14. Typische Fallstricke

  • Drift durch manuelle Änderungen:
    • Ursache für OutOfSync und schwer zu reproduzierende Zustände
  • Fehlerhafte oder komplexe Helm-/Kustomize-Setups:
    • Render-Probleme im Repo-Server bei sehr komplexen Konfigurationen
  • Unzureichende Rechte im Ziel-Cluster:
    • Argo CD-Service-Account braucht passende RBAC-Rechte
  • Netzwerk-/Firewall-Probleme:
    • Argo CD muss das Git-Repo erreichen können (Proxy, SSL, SSH-Keys)
  • Stateful-Migrationen:
    • Vorsicht bei Datenbank-Migrationen im Sync-Prozess (Hook-Jobs, Migrationsphasen)

15. Argo CD vs. andere GitOps-Tools (z.B. Flux)

Kurzvergleich zu Flux (ein anderes populäres GitOps-Tool):

  • Argo CD:
    • Sehr starke, moderne UI
    • Klare Application-Entität
    • Häufig intuitiv für Teams, die visuelle Steuerung wünschen
  • Flux:
    • Sehr „Kubernetes-native“, keine eigene zentrale UI (oft mit zusätzlicher UIs wie Weave GitOps)
    • Stärker über CRDs und CLI gesteuert, weniger „zentrales“ Dashboard

Beide implementieren GitOps; die Wahl hängt oft von:

  • UI-Bedarf
  • Präferenzen des Teams
  • Vorhandenen Ökosystem-Komponenten
Reference in New Issue View Git Blame Copy Permalink