359 lines
11 KiB
Markdown
Executable File
359 lines
11 KiB
Markdown
Executable File
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
|
||
|
||
|