Ein pragmatisches Argo-CD-Setup — GitOps, das den Kontakt mit der Realität übersteht

Argo CD ist eines dieser Projekte, die enorm beliebt und enorm falsch deployt werden. Jedes Team, mit dem ich arbeite, hat irgendeine Version von Argo CD laufen. Vielleicht ein Drittel davon hat es so eingerichtet, dass es ihnen tatsächlich Arbeit erspart, statt eine schlechtere Version von kubectl apply mit extra YAML zu sein.

Der Unterschied liegt meist an drei Stellen: Repo-Struktur, Sync-Wave-Orchestrierung und wie Sie Secrets handhaben.

Das App-of-Apps-Repo-Layout

gitops-repo/
├── bootstrap/                  # root app-of-apps
├── platform/                   # cluster-weite Infra (ingress, cert-manager, …)
├── tenants/
│   ├── team-payments/{dev,staging,prod}/
│   └── team-search/{dev,staging,prod}/
└── projects/                   # AppProject RBAC-Grenzen

Eine einzige Root-Application bootstrappt den Cluster. platform/ gehört dem Platform-Team. Jeder Tenant hat sein eigenes Verzeichnis pro Umgebung, sodass die Promotion ein PR ist, der Manifeste von einem Verzeichnis ins nächste kopiert.

Der vollständige Beitrag behandelt:

• Sync Waves — die Nummerierungskonvention, die wir auf jedem Cluster verwenden
• Warum wir External Secrets Operator + ein Vault nutzen, nicht sealed-secrets (Rotation)
• Auto-Sync für dev/staging, manueller Sync für prod (und warum)
• ApplicationSet für Flotten-von-Umgebungen-Patterns
• Notifications: die Slack-Alerts, die wirklich zählen
• Argo CD sichern und die Lehren aus dem Mal, als wir es nicht getan haben

Wir liefern dieses Layout auf jedem gemanagten Kubernetes-Cluster aus.