GitOps als Grundprinzip
ArgoCD basiert auf einem einfachen, aber wirkungsvollen Prinzip: Der gewünschte Zustand Ihrer Kubernetes-Cluster ist in Git beschrieben. ArgoCD vergleicht diesen Soll-Zustand kontinuierlich mit dem Ist-Zustand im Cluster und korrigiert Abweichungen automatisch. Das ist GitOps -- und es verändert grundlegend, wie Teams über Deployments nachdenken.
Statt Deployments über Skripte oder manuelle kubectl-Befehle auszuführen, ändern Teams ein YAML-File in einem Git-Repository und erstellen einen Merge Request. ArgoCD erledigt den Rest. Jedes Deployment ist dadurch nachvollziehbar, reviewbar und bei Bedarf durch einen Git Revert rückgängig zu machen.
ArgoCD in der Praxis aufsetzen
Die Installation von ArgoCD auf einem bestehenden Kubernetes-Cluster ist unkompliziert:
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
Danach definieren Sie eine Application-Ressource, die ArgoCD mitteilt, welches Git-Repository welchem Cluster und Namespace zugeordnet ist:
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: my-app
namespace: argocd
spec:
project: default
source:
repoURL: https://gitlab.example.com/team/k8s-manifests.git
targetRevision: main
path: environments/production
destination:
server: https://kubernetes.default.svc
namespace: production
syncPolicy:
automated:
prune: true
selfHeal: true
Mit automated.selfHeal: true korrigiert ArgoCD jede manuelle Änderung am Cluster automatisch -- der Git-Stand ist immer die Wahrheit.
Skalierung über mehrere Cluster
Die eigentliche Stärke von ArgoCD zeigt sich, wenn mehrere Cluster und Umgebungen im Spiel sind. In typischen Enterprise-Setups verwalten Teams Development-, Staging- und Produktionsumgebungen, oft verteilt auf mehrere Regionen oder Cloud-Provider.
ApplicationSets für Multi-Cluster
ApplicationSets sind das Werkzeug der Wahl, wenn Sie dieselbe Anwendung auf mehreren Clustern deployen:
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
name: my-app-set
spec:
generators:
- clusters:
selector:
matchLabels:
environment: production
template:
metadata:
name: 'my-app-{{name}}'
spec:
source:
repoURL: https://gitlab.example.com/team/k8s-manifests.git
path: environments/production
destination:
server: '{{server}}'
namespace: production
Neue Cluster, die das Label environment: production tragen, erhalten automatisch das Deployment. Das skaliert, ohne dass Sie für jeden Cluster manuell eine Application anlegen müssen.
Repository-Strukturen für große Teams
Bei vielen Anwendungen und Umgebungen wird die Repository-Struktur entscheidend. Zwei Ansätze haben sich etabliert:
- Monorepo: Alle Manifeste in einem Repository, organisiert nach Anwendung und Umgebung. Einfach zu verwalten, aber unübersichtlich bei vielen Teams
- App-per-Repo: Jede Anwendung hat ihr eigenes Manifest-Repository. Sauberere Zugriffsrechte, aber mehr Repositories zu verwalten
In der Praxis fahren viele Teams einen Mittelweg: Ein Repository pro Team oder Domäne, mit klarer Verzeichnisstruktur für Anwendungen und Umgebungen.
Automatisierung der Promotion
Ein häufiges Muster: Nach erfolgreichem Deployment in der Staging-Umgebung soll die Anwendung automatisch in die Produktion beföordert werden. Das lässt sich über die CI/CD-Pipeline der Manifest-Repositories abbilden:
- Ein Image-Build in der Anwendungs-Pipeline erzeugt ein neues Container-Image
- Die Pipeline aktualisiert das Image-Tag im Staging-Manifest-Repository
- ArgoCD deployed nach Staging
- Automatisierte Tests laufen gegen Staging
- Bei Erfolg wird das Image-Tag im Produktions-Manifest aktualisiert
- ArgoCD deployed nach Produktion
Dieser Prozess ist vollständig automatisierbar, wobei die meisten Teams bewusst einen manuellen Approval-Schritt vor dem Produktions-Deployment einbauen.
Monitoring und Observability
ArgoCD liefert über die Web-UI und die API detaillierte Informationen zum Sync-Status aller Anwendungen. Für den produktiven Betrieb sollten Sie zusätzlich:
- Prometheus-Metriken exportieren und in Grafana visualisieren
- Notifications konfigurieren (Slack, Teams, E-Mail) für fehlgeschlagene Syncs
- Health Checks definieren, die über den reinen Kubernetes-Status hinausgehen
Fazit
ArgoCD macht Kubernetes-Deployments vorhersagbar und skalierbar. Der GitOps-Ansatz bringt Ordnung in Multi-Cluster-Umgebungen und macht Deployments nachvollziehbar. Der Einstieg ist einfach, die Komplexität kommt mit der Skalierung -- aber genau dafür bringt ArgoCD die richtigen Werkzeuge mit.
Unser Training Continuous Delivery mit ArgoCD vermittelt die praktische Einrichtung und den Betrieb von ArgoCD in Enterprise-Umgebungen.
