Sync-Verhalten steuern: Auto-Sync, Prune, Self-Heal und Rollback
Entscheide, wann Argo CD Änderungen anwendet, was es löscht und wie du ein fehlerhaftes Deployment rückgängig machst.
Die Standardeinstellungen von Argo CD sind konservativ: Es erkennt Unterschiede, ändert aber von sich aus nichts an deinem Cluster. Jedes Verhalten, das es vollautomatisch macht, ist ein ausdrückliches Opt-in, sodass du pro Umgebung einen anderen Automatisierungsgrad wählen kannst. Diese Anleitung geht jeden Schalter anhand der Anwendung webapp-dev aus der vorherigen Anleitung durch.
Manueller vs. automatischer Sync
Eine Application ohne syncPolicy.automated-Block ist manuell. Argo CD vergleicht Git mit dem Cluster und markiert die Anwendung als OutOfSync, wenn sie sich unterscheiden, aber es wird nichts angewendet, bis jemand in der Oberfläche auf Sync klickt oder argocd app sync ausführt.
Viele Teams nutzen den automatischen Sync für Dev- und Test-Umgebungen und halten die Produktion manuell, sodass eine Person jeden Produktions-Rollout freigibt, bis das Team der Pipeline vertraut.
Automatischen Sync aktivieren
Füge der syncPolicy der Anwendung einen automated-Block hinzu:
spec:
syncPolicy:
automated: {}
Damit wird jeder neue Commit, der den Soll-Zustand ändert, ohne Klick angewendet. Zwei Details zum Timing:
- Argo CD erkennt neue Commits durch Abfragen (Polling) des Repositorys, standardmäßig alle drei Minuten. Das ist unabhängig von der Sync-Policy. Die Policy entscheidet nur, ob ein erkannter Unterschied angewendet wird.
- Um sofort zu reagieren, konfiguriere einen Webhook von deinem Git-Host zum
/api/webhook-Endpunkt von Argo CD, oder klicke beim Testen in der Oberfläche auf Refresh.
Pruning hinzufügen
Standardmäßig erstellt und aktualisiert der automatische Sync Ressourcen, löscht aber nichts. Wenn du ein Manifest in Git umbenennst oder entfernst, bleibt das alte Objekt im Cluster, und die Anwendung zeigt wegen des Überbleibsels OutOfSync. Aktiviere das Löschen per Opt-in:
spec:
syncPolicy:
automated:
prune: true
Zum Ausprobieren benenne das Deployment in dev/deployment.yaml von webapp in webapp-v2 um und committe. Argo CD erstellt das neue Deployment und entfernt das alte. Bei einem manuellen Sync kannst du einmalig mit argocd app sync webapp-dev --prune bereinigen oder im Sync-Dialog Prune anhaken. Pruning löscht echte Objekte, aktiviere es daher bewusst und sei vorsichtig bei Ressourcen, die Zustand halten.
Self-Heal hinzufügen
Der automatische Sync reagiert auf Änderungen in Git. Self-Heal reagiert zusätzlich auf Änderungen im Cluster:
spec:
syncPolicy:
automated:
prune: true
selfHeal: true
Teste es mit einer manuellen Änderung, von der Git nichts weiß:
kubectl scale deployment webapp-v2 -n webapp --replicas=5
kubectl get pods -n webapp -w
Zusätzliche Pods starten, dann setzt Argo CD das Deployment auf die zwei in Git deklarierten Replikas zurück. Genau das ist der Punkt: Git bleibt die einzige Quelle der Wahrheit. Wenn dein Team noch nicht bereit ist, dass manuelle Änderungen automatisch zurückgesetzt werden, lass selfHeal ausgeschaltet. Argo CD zeigt die Anwendung dann weiterhin als OutOfSync an, sodass die Abweichung sichtbar bleibt. Füge Benachrichtigungen hinzu, wenn du informiert werden möchtest.
Sicher zurückrollen
Um zu einem früheren ausgerollten Zustand zurückzukehren, öffne in der Ansicht der Anwendung History and Rollback, wähle eine frühere Revision und rolle zurück. Die CLI-Entsprechungen sind:
argocd app history webapp-dev
argocd app rollback webapp-dev <ID>
Rollback erfordert, dass der automatische Sync ausgeschaltet ist. Andernfalls würde Argo CD die Anwendung sofort wieder auf den neuesten Commit synchronisieren und den Rollback zunichtemachen. Deaktiviere ihn zuerst mit argocd app set webapp-dev --sync-policy none. Nach einem Rollback ist die Anwendung OutOfSync, weil Git dem Laufenden voraus ist. Betrachte Rollback als Notfallhebel, nicht als die Lösung. Die dauerhafte Lösung ist, den fehlerhaften Commit mit git revert zurückzunehmen, zu pushen und dann den automatischen Sync wieder zu aktivieren, damit Git und Cluster wieder übereinstimmen.
Beliebte Anleitungen
-
Push vs. Pull: Wie Argo CD auf Kubernetes ausliefert Warum pull-basierte, Git-gesteuerte Auslieferung verändert, wie du Cluster deployst, absicherst und wiederherstellst. -
Multi-Cluster mit Argo CD konfigurieren Deployments über mehrere Cluster hinweg verwalten. -
Deine erste Anwendung mit einem deklarativen Manifest deployen Richte Argo CD mit einer Application-Ressource auf ein Git-Repository aus und sieh dem Sync zu.