Die Lücke zwischen Demo und Produktion
ArgoCD-Demos sehen immer elegant aus: Git-Push, automatischer Sync, fertig. In der Praxis ist der Weg vom Proof of Concept zum produktionsreifen Setup allerdings länger als erwartet. Nicht weil ArgoCD schlecht wäre -- das Tool ist ausgereift und zuverlässig. Aber die reale Welt ist komplizierter als eine Demo mit einer Anwendung auf einem Cluster.
Dieser Artikel beschreibt die Herausforderungen, die uns in Kundenprojekten immer wieder begegnen, und wie man ihnen begegnet.
Secrets Management
Das grösste Kopfzerbrechen bereitet fast immer das Secrets Management. GitOps bedeutet, dass der gewünschte Zustand in Git liegt -- aber Passwörter, API-Keys und Zertifikate gehören definitiv nicht in ein Git-Repository. ArgoCD selbst bietet keine eingebaute Lösung für dieses Problem.
Die gängigen Ansätze:
- Sealed Secrets: Secrets werden verschlüsselt ins Repository committed. Nur der Cluster-Controller kann sie entschlüsseln. Einfach, aber die verschlüsselten Werte sind Cluster-spezifisch
- External Secrets Operator: Secrets werden zur Laufzeit aus einem externen Store (AWS Secrets Manager, HashiCorp Vault, Azure Key Vault) geladen. Flexibler, aber eine zusätzliche Komponente im Cluster
- Vault Agent Sidecar: HashiCorp Vault injiziert Secrets direkt in Pods. Mächtig, aber komplex
Keine dieser Lösungen ist perfekt. Teams müssen früh entscheiden, welcher Ansatz zu ihrer Infrastruktur passt, und diese Entscheidung konsequent umsetzen. Ein Mix verschiedener Ansätze führt zu Chaos.
Multi-Tenancy und Zugriffskontrolle
Sobald mehrere Teams denselben ArgoCD-Server nutzen, wird Zugriffskontrolle relevant. Team A soll seine eigenen Anwendungen verwalten können, aber keine Änderungen an den Anwendungen von Team B vornehmen. ArgoCD bietet dafür Projects mit RBAC -- aber die Konfiguration ist nicht trivial:
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
name: team-a
spec:
sourceRepos:
- 'https://gitlab.company.com/team-a/*'
destinations:
- namespace: 'team-a-*'
server: 'https://kubernetes.default.svc'
clusterResourceWhitelist:
- group: ''
kind: Namespace
roles:
- name: developer
policies:
- p, proj:team-a:developer, applications, *, team-a/*, allow
groups:
- team-a-devs
Die Herausforderung liegt im Detail: Welche Cluster-Ressourcen darf ein Team erstellen? Darf es Namespaces anlegen? Ingress-Ressourcen ändern? CRDs installieren? Jede Entscheidung muss bewusst getroffen und in der Project-Konfiguration abgebildet werden.
Repository-Struktur bei Skalierung
Mit zunehmender Anzahl von Anwendungen und Umgebungen wird die Repository-Struktur zur zentralen Architekturentscheidung. Häufige Probleme:
- Zu viele Repositories: Jede Anwendung hat ihr eigenes Manifest-Repository. Bei 50 Anwendungen sind das 50 Repositories, die gepflegt werden müssen
- Zu große Repositories: Alle Manifeste in einem Monorepo. ArgoCD muss bei jedem Commit das gesamte Repository prüfen, was bei großen Repos zu Performance-Problemen führt
- Unklare Ownership: Wer ist verantwortlich für die Basis-Infrastruktur-Manifeste, wer für die Anwendungs-Manifeste?
Ein bewährtes Muster: Ein Repository pro Team oder Domäne, mit ApplicationSets, die automatisch neue Anwendungen erkennen. Basis-Infrastruktur (Ingress Controller, Monitoring, Cert-Manager) liegt in einem separaten "Platform"-Repository, das nur das Platform-Team ändert.
Drift Detection und Self-Healing
ArgoCD erkennt Abweichungen zwischen Git und Cluster -- das ist eine seiner Kernfunktionen. Aber in der Praxis gibt es legitime Gründe für Abweichungen:
- Horizontal Pod Autoscaler: Ändert die Replica-Anzahl, ArgoCD sieht einen Drift
- Mutating Webhooks: Verändern Ressourcen nach dem Apply, ArgoCD sieht einen Drift
- Operator-verwaltete Ressourcen: CRDs, deren Status-Felder sich ändern
Die Lösung sind gezielte Ignore-Regeln in der Application-Konfiguration. Aber zu viele Ignore-Regeln untergraben den Sinn von GitOps. Es braucht ein Gleichgewicht zwischen "alles in Git" und "manche Dinge werden vom Cluster verwaltet".
Performance bei vielen Applications
ArgoCD pollt regelmäßig alle konfigurierten Git-Repositories. Bei Hunderten von Applications und kurzen Polling-Intervallen erzeugt das Last auf dem ArgoCD-Server und auf dem Git-Server. Maßnahmen:
- Webhooks statt Polling: Git-Server benachrichtigen ArgoCD bei Änderungen, statt dass ArgoCD regelmäßig nachfragt
- Application Controller Sharding: Die Last wird auf mehrere Controller-Instanzen verteilt
- Repository-Caching: ArgoCD cached Repository-Inhalte, um redundante Clones zu vermeiden
Fazit
ArgoCD ist ein hervorragendes Tool für GitOps-basierte Kubernetes-Deployments. Aber der Weg zur produktionsreifen Installation erfordert Entscheidungen zu Secrets Management, Zugriffskontrolle und Repository-Struktur, die früh getroffen werden sollten. Teams, die diese Themen von Anfang an berücksichtigen, sparen sich spätere Umbauten.
Unser Training Continuous Delivery mit ArgoCD behandelt genau diese Praxisthemen -- nicht nur die Grundinstallation, sondern den Betrieb in echten Enterprise-Umgebungen.
