init at work

2026-03-27 12:58:01 +01:00
parent 352c352056
commit 8d40597732
60 changed files with 16498 additions and 0 deletions
@@ -0,0 +1,358 @@
+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
+
+