← zurück

📷 "Little abacus in the server room" by Gael Varoquaux is licensed under CC BY 2.0. To view a copy of this license, visit https://creativecommons.org/licenses/by/2.0/.

GitOps-Automatisierung 2026: ArgoCD Image Updater und Rollouts im Zusammenspiel

08. August 2026 · 4 min · Martin Jochum #GitOps#ArgoCD#Argo Rollouts#Image Updater#Kubernetes#DevOps#Progressive Delivery

GitOps mit ArgoCD hat sich in den letzten Jahren von einem reinen Synchronisationswerkzeug zu einer umfassenden Automatisierungsplattform entwickelt. Während der Vergleich zwischen ArgoCD und Flux im Juni 2026 zeigt, dass ArgoCD mit rund 23.100 GitHub-Sternen und der Version 3.4.3 die populärere Wahl ist (Tech Insider, 2026), liegt der eigentliche Mehrwert für viele Teams in zwei spezialisierten Erweiterungen: ArgoCD Image Updater für automatische Container-Image-Updates und Argo Rollouts für progressive Delivery. Dieser Artikel zeigt, wie beide Tools im Zusammenspiel eine vollständig automatisierte GitOps-Pipeline ermöglichen.

ArgoCD Image Updater: Vom CI-Build zur Git-Commit

Der ArgoCD Image Updater (aktuelle Version 1.2.1) ist ein separater Controller, der Container-Registries überwacht und bei neuen Images automatisch die Image-Tags im Git-Repository aktualisiert. Das schließt die Lücke zwischen CI-Pipeline und GitOps: Ein gebautes Container-Image landet in der Registry, der Image Updater erkennt die neue Version und committed den aktualisierten Tag zurück ins Git-Repository, und ArgoCD synchronisiert die Änderung in den Cluster.

Die Einrichtung erfolgt per Helm-Chart oder kubectl und ist in wenigen Minuten erledigt:

helm repo add argo https://argoproj.github.io/argo-helm
helm install argocd-image-updater argo/argocd-image-updater -n argocd

Aktiviert wird der Image Updater pro ArgoCD-Application über Annotationen:

annotations:
  argocd-image-updater.argoproj.io/image-list: myapp=ghcr.io/myorg/myapp
  argocd-image-updater.argoproj.io/myapp.update-strategy: semver
  argocd-image-updater.argoproj.io/write-back-method: git
  argocd-image-updater.argoproj.io/git-branch: main

Update-Strategien im Überblick: Der Image Updater unterstützt vier Strategien. semver wählt den höchsten kompatiblen semantischen Versionstag, newest-build nutzt das jüngste Build-Datum, alphabetical sortiert alphabetisch, und digest verfolgt einen bestimmten Tag und aktualisiert bei Digest-Änderungen – etwa für latest-Tags. Für Helm-basierte Deployments lassen sich die zu aktualisierenden Values-Pfade (helm.image-name, helm.image-tag) exakt angeben; bei Kustomize wird das kustomization.yaml-Image-Objekt aktualisiert (OneUptime, Januar 2026).

Die write-back-method: git sorgt dafür, dass jede Änderung als sauberer Commit mit vollständigem Audit-Trail im Git-Repository landet – zentrales GitOps-Prinzip. Für Teams, die zusätzliche Qualitätssicherung wünschen, empfiehlt sich eine Branch-Strategie: Der Image Updater committed auf einen separaten Branch, und ein automatisierter Pull-Request-Durchlauf ermöglicht Reviews und automatisierte Tests, bevor gemerged wird.

Argo Rollouts: Progressive Delivery mit automatisierter Rollback-Entscheidung

Während der Image Updater für aktuelle Images sorgt, übernimmt Argo Rollouts die sichere Auslieferung. Argo Rollouts (ca. 3.500 GitHub-Sterne) erweitert ArgoCD um erweiterte Deployment-Strategien, die weit über den Kubernetes-Standard-Rolling-Update hinausgehen (OneUptime, Februar 2026).

Der Kern ist die Ablösung des nativen Kubernetes-Deployment-Ressourcentyps durch einen Rollout mit detaillierter Canary- oder Blue-Green-Strategie:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: myapp
spec:
  replicas: 5
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myapp:1.0.0
  strategy:
    canary:
      steps:
      - setWeight: 10
      - pause: { duration: 5m }
      - setWeight: 30
      - pause: { duration: 5m }
      - setWeight: 60
      - pause: { duration: 5m }
      - setWeight: 100

Die eigentliche Stärke entfaltet Argo Rollouts jedoch durch Analysis Templates. Diese definieren Metrik-Abfragen – typischerweise gegen Prometheus – und lassen das System automatisch über Promote oder Rollback entscheiden (OneUptime, Februar 2026):

apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: success-rate-check
spec:
  metrics:
  - name: success-rate
    interval: 2m
    successCondition: result[0] >= 0.95
    failureLimit: 3
    provider:
      prometheus:
        address: http://prometheus.monitoring.svc:9090
        query: |
          sum(rate(http_requests_total{status=~"2.*"}[5m]))
          / sum(rate(http_requests_total[5m]))

Sinkt die Erfolgsrate unter 95 % oder überschreitet die p99-Latenz einen definierten Schwellwert, bricht Argo Rollouts das Canary automatisch ab und skaliert die neue Version zurück – ohne menschliches Eingreifen.

Zusammenspiel in der Praxis: Vom Push zum produktiven Rollout

Die Kombination beider Tools ergibt eine vollständig automatisierte Pipeline ohne menschliche Handgriffe:

  1. CI/CD-Pipeline baut ein neues Image und pushed es in die Registry (z. B. ghcr.io/myorg/myapp:v1.2.3)
  2. ArgoCD Image Updater erkennt den neuen Tag, prüft die Semver-Regeln und committed die Änderung ins Git-Repository
  3. ArgoCD synchronisiert den aktualisierten Rollout in den Cluster
  4. Argo Rollouts startet die Canary-Strategie – 10 % Traffic, Metrik-Überwachung, schrittweise Erhöhung
  5. Bei Metrik-Verletzung: automatischer Rollback – andernfalls vollständiger Promote

Dieser Workflow entspricht dem in der DevOps-Community empfohlenen “Intermediate”-Setup für Teams mit 10–50 Services: Renovate für Dependency-Updates, ArgoCD Image Updater für Image-Promotion und Argo Rollouts für automatisierte Canary-Deployments (DEV Community, 2026). Ein PodDisruptionBudget und korrekt konfigurierte Readiness-Probes bleiben als Sicherheitsnetz unverzichtbar.

Fazit

ArgoCD Image Updater und Argo Rollouts machen ArgoCD 2026 zu mehr als einem reinen GitOps-Sync-Tool. Der Image Updater automatisiert den lästigen manuellen Tag-Update-Prozess, während Rollouts progressive Delivery mit automatischen, metrikbasierten Rollback-Entscheidungen ermöglicht. Zusammen bilden sie eine Pipeline, die vom CI-Push bis zum produktiven Rollout komplett automatisiert abläuft – und dabei das zentrale GitOps-Prinzip wahrt: Git bleibt die einzige Quelle der Wahrheit. Für Teams, die ArgoCD bereits im Einsatz haben, sind beide Erweiterungen ein logischer nächster Schritt auf dem Weg zu einer vollautomatischen Deployment-Plattform.

Quellen