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):

```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