ArgoCD auf AKS: GitOps für Azure Kubernetes in der Praxis

Pexon Consulting | 13 Min. Lesezeit | 01.04.2026

TL;DR

ArgoCD auf AKS bringt GitOps in Azure Kubernetes – jedes Deployment wird per Git-Commit ausgelöst und automatisch mit dem Cluster synchronisiert. Pexon Consulting (80 Mitarbeiter, Microsoft Partner) setzt ArgoCD AKS bei Kunden in Fertigung und Energie produktiv ein. Das Ergebnis: 70% weniger manuelle Deployment-Eingriffe und Rollbacks in unter 30 Sekunden.

Warum GitOps auf AKS – und warum jetzt

97% der ArgoCD-Nutzer setzen es in Produktion ein, 60% seit mehr als zwei Jahren. Das ist kein Hype-Tool – das ist Standard.

Trotzdem sehen wir bei deutschen Mittelständlern eine Lücke. Kubernetes läuft auf AKS, die CI-Pipeline baut Container-Images, aber das Deployment passiert immer noch per kubectl apply aus der Azure DevOps Pipeline. Oder schlimmer: per Hand.

Das Problem ist nicht, dass es nicht funktioniert. Es funktioniert – bis jemand um 17 Uhr am Freitag eine falsche Image-Version deployed und am Montag niemand mehr weiß, warum der Cluster in einem anderen Zustand ist als das Git-Repository. Konfigurationsdrift. Bei einem Cluster kein Drama. Bei fünf Clustern über drei Umgebungen ist es ein Albtraum.

GitOps löst das, indem es eine einfache Regel durchsetzt – definiert durch die OpenGitOps-Spezifikation der CNCF: Git ist die einzige Wahrheit. ArgoCD überwacht Ihr Git-Repository und gleicht den Cluster-Zustand permanent ab. Weicht der Cluster ab – weil jemand manuell etwas geändert hat – korrigiert ArgoCD das automatisch. Kein Drift, kein „War das Absicht oder ein Fehler?“, kein Detektiv spielen am Montag.

ArgoCD AKS: Installation in 15 Minuten

Die Basisinstallation ist trivial. Das Interessante kommt danach – Azure AD, Workload Identity, Private Cluster. Aber fangen wir vorne an.

# AKS-Cluster erstellen (falls noch nicht vorhanden)
az aks create 
  --resource-group rg-gitops-prod 
  --name aks-gitops-prod 
  --node-count 3 
  --node-vm-size Standard_D4s_v5 
  --enable-managed-identity 
  --enable-oidc-issuer 
  --enable-workload-identity 
  --network-plugin azure 
  --generate-ssh-keys

# kubectl-Kontext setzen
az aks get-credentials --resource-group rg-gitops-prod --name aks-gitops-prod

# ArgoCD via Helm installieren
helm repo add argo https://argoproj.github.io/argo-helm
helm repo update

helm install argocd argo/argo-cd 
  --namespace argocd 
  --create-namespace 
  --set server.service.type=ClusterIP 
  --set configs.params."server.insecure"=true 
  --set server.ingress.enabled=true 
  --set server.ingress.ingressClassName=nginx

# Admin-Passwort auslesen
kubectl -n argocd get secret argocd-initial-admin-secret 
  -o jsonpath="{.data.password}" | base64 -d

Damit läuft ArgoCD. Für den Produktionseinsatz brauchen Sie allerdings noch Azure AD SSO, Workload Identity für den Repository-Zugriff und ein ordentliches Ingress-Setup mit TLS.

Azure AD + Workload Identity: Kein statisches Token im Cluster

Statische Credentials in Kubernetes Secrets – das ist der Klassiker, der bei jedem Security-Audit auffällt. ArgoCD auf AKS geht besser: Azure Workload Identity.

Das Prinzip: ArgoCD bekommt eine Managed Identity zugewiesen. Diese Identity hat Zugriff auf Azure Container Registry (zum Image-Pull) und auf Azure DevOps Repos (zum Manifest-Sync). Keine Passwörter, keine Token-Rotation, keine Secrets im Cluster.

# argocd-values.yaml - Produktions-Setup mit Azure AD SSO
server:
  config:
    # Azure AD OIDC Login
    oidc.config: |
      name: Azure AD
      issuer: https://login.microsoftonline.com/{TENANT_ID}/v2.0
      clientID: {APP_CLIENT_ID}
      clientSecret: $oidc.azure.clientSecret
      requestedScopes:
        - openid
        - profile
        - email
    # RBAC: Azure AD Gruppen → ArgoCD Rollen
    policy.csv: |
      p, role:dev-team, applications, get, */*, allow
      p, role:dev-team, applications, sync, */*, allow
      p, role:platform-team, applications, *, */*, allow
      g, {AZURE_AD_DEV_GROUP_ID}, role:dev-team
      g, {AZURE_AD_PLATFORM_GROUP_ID}, role:platform-team

repoServer:
  serviceAccount:
    annotations:
      azure.workload.identity/client-id: {MANAGED_IDENTITY_CLIENT_ID}
  podLabels:
    azure.workload.identity/use: "true"

Wir empfehlen dringend, Azure AD SSO von Anfang an einzurichten – nicht als „Phase 2“. Sobald mehr als drei Leute Zugriff auf ArgoCD haben, brauchen Sie nachvollziehbare Logins und gruppenbasierte Berechtigungen. Das nachträglich umzubauen ist deutlich aufwändiger als es gleich richtig zu machen.

Workload Identity ist dabei kein ArgoCD-Thema, sondern eine Eigenschaft des Clusters: Ohne sauber gesetzte Managed Identity, RBAC und Azure Policy fällt das Setup beim ersten Audit auf. Teams, die diesen Unterbau nicht selbst bauen wollen, können die AKS-Implementierung als Azure Kubernetes Beratung beauftragen.

Repository-Struktur: App of Apps Pattern

Wie strukturieren Sie die Git-Repositories? Das ist die Frage, die in der Praxis mehr Diskussionen verursacht als die eigentliche ArgoCD-Installation.

Unsere Empfehlung: Das App of Apps Pattern. Ein Root-Repository definiert alle Applikationen, jede Applikation hat ihr eigenes Manifest-Verzeichnis.

Jede Umgebung (dev, staging, prod) hat eigene Kustomize-Patches, die über die Basis-Manifeste gelegt werden. Replicas, Resource Limits, Environment Variables – alles was sich zwischen Umgebungen unterscheidet, wird als Patch definiert.

# apps/backend-service.yaml - ArgoCD Application
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: backend-service
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://dev.azure.com/org/project/_git/gitops-repo
    targetRevision: main
    path: environments/prod/backend-service
  destination:
    server: https://kubernetes.default.svc
    namespace: backend
  syncPolicy:
    automated:
      prune: true        # Lösche Ressourcen die nicht mehr im Git sind
      selfHeal: true      # Korrigiere manuelle Änderungen am Cluster
    syncOptions:
      - CreateNamespace=true
    retry:
      limit: 3
      backoff:
        duration: 5s
        factor: 2

Finger weg von Helm Charts direkt in ArgoCD – zumindest für eigene Applikationen. Kustomize ist vorhersagbarer, leichter zu reviewen in Pull Requests und erzeugt weniger Überraschungen bei Upgrades. Helm ist prima für Third-Party-Tools (Prometheus, Ingress Controller), aber für Ihre eigenen Services ist Kustomize der bessere Weg.

ArgoCD vs. Azure DevOps Pipelines: Wann welches Tool

„Wir haben doch schon Azure DevOps Pipelines – warum brauchen wir noch ArgoCD?“

Die kurze Antwort: Azure DevOps baut und testet. ArgoCD deployed und überwacht. Beides zusammen ist besser als eines allein.

Azure DevOps Pipelines sind Push-basiert: Ein Pipeline-Run pushed Änderungen in den Cluster. Wenn der Run fehlschlägt, weiß niemand, in welchem Zustand der Cluster ist. ArgoCD ist Pull-basiert: Es überwacht das Git-Repository und zieht Änderungen aktiv in den Cluster. Wenn etwas schiefgeht, bleibt der vorherige Zustand erhalten.

Der typische Workflow bei unseren Kunden:

1. Entwickler pushed Code → Azure DevOps Pipeline baut Container-Image → pushed nach Azure Container Registry
2. Pipeline aktualisiert Image-Tag im GitOps-Repository (per kustomize edit set image)
3. ArgoCD erkennt die Änderung → synced den Cluster → verifiziert den Health-Status

So trennen Sie Build (CI) sauber von Deployment (CD). Das ist kein akademisches Konzept – in der CNCF-Umfrage 2025 nutzen 24% der Organisationen Azure Pipelines für CI und 45% Argo für CD. Die beiden ergänzen sich.

Multi-Cluster: Drei AKS-Cluster mit einem ArgoCD

Ab dem zweiten AKS-Cluster wird ArgoCD richtig wertvoll. Ein zentrales ArgoCD verwaltet dev, staging und prod – oder mehrere Produktionscluster in verschiedenen Azure-Regionen.

# Zweiten Cluster registrieren
# (ArgoCD läuft auf dem Management-Cluster)
argocd cluster add aks-staging 
  --name staging 
  --kubeconfig ~/.kube/config-staging

# Dritten Cluster registrieren
argocd cluster add aks-prod-westeurope 
  --name prod-we 
  --kubeconfig ~/.kube/config-prod-we

Drei Cluster, ein Dashboard, eine Quelle der Wahrheit. Wenn Sie in der ArgoCD-Oberfläche sehen, dass alle drei Cluster „Synced“ und „Healthy“ sind, können Sie beruhigt ins Wochenende gehen. Wir setzen das bei Kunden mit 3-8 Clustern ein – darüber hinaus wird Argo ApplicationSets interessant, aber das ist Stoff für einen eigenen Artikel.

Rollbacks: 30 Sekunden statt 30 Minuten

Warum scheitern 80% der KI-Projekte? Falsche Frage. Warum dauern Rollbacks bei den meisten Teams 30 Minuten statt 30 Sekunden?

Weil sie den richtigen Stand zusammensuchen müssen. In welcher Pipeline-Version war das letzte funktionierende Image? Welche Config-Änderungen kamen gleichzeitig? Wer hat was manuell am Cluster geändert?

Mit GitOps ist der Rollback ein git revert:

# Letztes Deployment rückgängig machen
git revert HEAD
git push origin main
# ArgoCD synced automatisch den vorherigen Zustand

Das funktioniert, weil der komplette Cluster-Zustand in Git liegt. Kein „Ich glaube, das war Version 2.3.1“ – sondern ein dokumentierter, reproduzierbarer Zustand. In unseren Projekten hat sich dadurch die mittlere Recovery-Zeit (MTTR) von 25-40 Minuten auf unter 2 Minuten verkürzt.

Häufig gestellte Fragen

Was kostet ArgoCD AKS im laufenden Betrieb?

ArgoCD selbst ist Open Source und kostenlos. Die AKS-Kosten hängen von der Clustergröße ab – ein typischer 3-Node-Cluster mit Standard_D4s_v5 kostet rund 450 EUR/Monat. ArgoCD braucht auf dem Cluster etwa 500 MB RAM und 0,5 CPU Cores, also vernachlässigbar. Die eigentlichen Kosten liegen im Setup und in der Einarbeitung des Teams – rechnen Sie mit 2-4 Wochen für ein produktionsreifes Setup inklusive Azure AD, Workload Identity und Multi-Cluster.

ArgoCD oder Flux – was empfehlt ihr für AKS?

ArgoCD. Es hat 60% Marktanteil, die bessere Oberfläche und die größere Community. Flux hat Vorteile bei sehr großen Installationen (1.000+ Applikationen), aber für die meisten Mittelstandskunden mit 10-100 Services ist ArgoCD die bessere Wahl. Nach der Weaveworks-Insolvenz 2024 ist die Zukunft von Flux zwar durch CNCF gesichert, aber ArgoCD hat eindeutig das Momentum.

Können wir Azure DevOps Pipelines weiter nutzen?

Unbedingt. Azure DevOps bleibt für CI (Build, Test, Container-Image). ArgoCD übernimmt nur den CD-Teil (Deployment, Sync, Health-Check). Die Pipeline aktualisiert den Image-Tag im GitOps-Repository, ArgoCD synced den Cluster. Das ist das empfohlene Pattern – nicht entweder/oder, sondern beides zusammen.

Wie sicher ist ArgoCD auf einem produktiven AKS-Cluster?

Mit Azure AD SSO, Workload Identity (keine statischen Credentials), RBAC über Azure AD Gruppen und Network Policies ist ArgoCD produktionssicher. Wir empfehlen zusätzlich: ArgoCD-UI nur über internen Ingress erreichbar (kein Public IP), regelmäßige Updates (ArgoCD 3.3 erschien Anfang 2026) und Audit-Logging über Azure Monitor. Diese Cluster-Arbeit fällt nach der Einrichtung dauerhaft an, weshalb Sie den Azure-Kubernetes-Betrieb übernehmen lassen können.

Wie lange dauert die Einführung von ArgoCD AKS bei einem bestehenden Cluster?

Kommt drauf an, wo Sie starten. Wenn AKS bereits läuft und Kubernetes-Manifeste in Git liegen: 1-2 Wochen bis zum produktiven Setup. Wenn Sie gleichzeitig von Helm auf Kustomize migrieren und Azure AD einrichten: 3-4 Wochen. Wir haben das für Platform-Engineering-Projekte standardisiert – inklusive Schulung für das DevOps-Team.

Nächster Schritt

Wenn Sie ArgoCD AKS evaluieren oder Ihren bestehenden Deployment-Prozess auf GitOps umstellen wollen: Wir machen das in einem strukturierten Kubernetes Workshop, der Ihr Team in 2-3 Tagen vom Push-basierten Deployment zu einem produktionsreifen GitOps-Setup bringt.

Verwandte Themen