GitOps mit Flux auf AKS: Ein praktischer Implementierungsleitfaden

GitOps klingt einfach: den gewünschten Cluster-Zustand in Git speichern und einen Controller die Realität abgleichen lassen. In der Praxis erfordert ein produktionstaugliches GitOps-Setup auf AKS Entscheidungen über Repository-Struktur, Secret-Management, Multi-Cluster-Promotion und Progressive Delivery, die in den „Getting Started"-Tutorials nie vorkommen.

Dieser Leitfaden beschreibt eine praxiserprobte Flux-v2-Implementierung auf AKS, basierend auf Mustern, die wir bei Enterprise-Kunden einsetzen.

Warum Flux (und warum nicht ArgoCD)

Sowohl Flux als auch ArgoCD sind CNCF-graduierte GitOps-Controller. Wir setzen Flux für AKS-Deployments aus mehreren praktischen Gründen ein:

• Nativer Helm- und Kustomize-Support ohne zusätzliche UI- oder Serverkomponenten.
• Multi-Tenancy über Namespaces — Flux' Controller-per-Namespace-Modell lässt sich sauber auf Team-Grenzen abbilden.
• Azure-Integration — Flux wird als First-Party-AKS-Extension (microsoft.flux) unterstützt, was bedeutet, dass Microsoft Upgrades und Support übernimmt.
• Pull-basierte Architektur — keine Notwendigkeit, Cluster-APIs für Ihr CI-System zu exponieren.

ArgoCD punktet, wenn eine reichhaltige UI für die Cluster-Visualisierung benötigt wird. Wenn das Priorität hat, ist ArgoCD eine gute Wahl. Für headless, API-getriebenes GitOps ist Flux schlanker.

Repository-Struktur

Die wirkungsvollste Einzelentscheidung in einem GitOps-Setup ist die Struktur Ihrer Git-Repositories. Wir empfehlen ein Zwei-Repository-Muster:

App-Repository (pro Service)

Enthält den Applikations-Quellcode und ein deploy/-Verzeichnis mit Roh-Manifesten oder Helm-Chart-Values.

my-service/
  src/
  Dockerfile
  deploy/
    base/
      deployment.yaml
      service.yaml
      kustomization.yaml
    overlays/
      dev/
        kustomization.yaml
        patches.yaml
      staging/
        kustomization.yaml
      prod/
        kustomization.yaml

Fleet-Repository (eines pro Plattform)

Enthält die Cluster-Konfiguration — welche Applikationen wo mit welcher Konfiguration deployed sind.

fleet/
  clusters/
    dev-westeurope/
      flux-system/
      infrastructure/
      apps/
    prod-westeurope/
      flux-system/
      infrastructure/
      apps/
  infrastructure/
    sources/
    cert-manager/
    ingress-nginx/
    external-secrets/
  apps/
    my-service/
      base/
        kustomization.yaml
        helmrelease.yaml
      overlays/
        dev/
        prod/

Warum zwei Repos? Trennung der Zuständigkeiten. Applikationsentwickler besitzen das App-Repo und seine Deploy-Manifeste. Das Plattformteam besitzt das Fleet-Repo und kontrolliert, was auf welchem Cluster läuft. Das verhindert, dass ein einzelner Commit versehentlich die Produktion beeinflusst.

Flux auf AKS bootstrappen

Mit der AKS-Flux-Extension ist das Bootstrapping unkompliziert:

az k8s-configuration flux create \
  --resource-group rg-aks-prod \
  --cluster-name aks-prod-westeurope \
  --name flux-system \
  --namespace flux-system \
  --scope cluster \
  --url https://dev.azure.com/org/project/_git/fleet \
  --branch main \
  --kustomization name=cluster path=./clusters/prod-westeurope

Für mehr Kontrolle bootstrappen Sie direkt mit der Flux-CLI:

flux bootstrap git \
  --url=ssh://git@dev.azure.com/v3/org/project/fleet \
  --branch=main \
  --path=./clusters/prod-westeurope \
  --private-key-file=./identity

In beiden Fällen installiert Flux seine Controller und beginnt, den Cluster-Zustand gegen das Git-Repository abzugleichen.

Kustomize-Overlays für Umgebungs-Promotion

Kustomize-Overlays bilden das Rückgrat umgebungsspezifischer Konfiguration. Die Base-Schicht definiert die gemeinsame Deployment-Spezifikation, Overlays patchen pro Umgebung.

Ein typisches Overlay für die Produktion könnte enthalten:

# overlays/prod/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - ../../base
patches:
  - path: patches.yaml

# overlays/prod/patches.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-service
spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: my-service
          resources:
            requests:
              cpu: 500m
              memory: 512Mi
            limits:
              cpu: "1"
              memory: 1Gi

Kernprinzip: Promoten Sie niemals durch Branch-Merges (z. B. Dev-Branch in Prod-Branch). Promoten Sie, indem Sie die Overlay-Werte (Image-Tag, Replica-Count) im Fleet-Repo per PR aktualisieren. Das hält Ihre Git-History linear und auditierbar.

Helm Releases mit Flux

Für Drittanbieter-Software und komplexe Applikationen verwaltet Flux' HelmRelease-CRD Helm-Chart-Deployments deklarativ:

apiVersion: helm.toolkit.fluxcd.io/v2beta2
kind: HelmRelease
metadata:
  name: ingress-nginx
  namespace: ingress-system
spec:
  interval: 30m
  chart:
    spec:
      chart: ingress-nginx
      version: "4.9.x"
      sourceRef:
        kind: HelmRepository
        name: ingress-nginx
  values:
    controller:
      replicaCount: 2
      service:
        annotations:
          service.beta.kubernetes.io/azure-load-balancer-internal: "true"

• Pinnen Sie Chart-Versionen mit pessimistischen Constraints (4.9.x), um Patches zuzulassen, aber Breaking Changes zu verhindern.
• Setzen Sie das interval, um zu steuern, wie häufig Flux auf Chart-Updates prüft.
• Verwenden Sie valuesFrom, um Values aus ConfigMaps oder Secrets für umgebungsspezifische Overrides zu ziehen.

Secret-Management mit SOPS

Secrets in Git zu speichern ist eine Voraussetzung für GitOps, aber ein Sicherheitsproblem, wenn es naiv umgesetzt wird. Mozilla SOPS mit Azure Key Vault löst das elegant.

Einrichtung

1. Erstellen Sie einen Azure Key Vault mit einem RSA-Key für SOPS-Verschlüsselung.
2. Erteilen Sie dem Flux-Service-Account (via Workload Identity) decrypt-Berechtigungen auf den Key.
3. Konfigurieren Sie eine .sops.yaml in Ihrem Fleet-Repo:

creation_rules:
  - path_regex: .*\.enc\.yaml$
    azure_keyvault: https://kv-flux-prod.vault.azure.net/keys/sops-key/abc123

4. Verschlüsseln Sie Secrets vor dem Commit:

sops --encrypt --in-place secrets.enc.yaml

Flux entschlüsselt SOPS-verschlüsselte Dateien automatisch während der Reconciliation über den eingebauten SOPS-Support des Kustomize-Controllers.

Wichtig: Verwenden Sie separate SOPS-Keys pro Umgebung. Ein Dev-Cluster sollte nicht in der Lage sein, Produktions-Secrets zu entschlüsseln, selbst wenn jemand versehentlich die verschlüsselte Datei kopiert.

Multi-Cluster-Management

Für Multi-Cluster-Setups (Dev, Staging, Production oder mehrere Regionen) übernimmt die Verzeichnisstruktur des Fleet-Repos die Hauptarbeit.

Jeder Cluster erhält ein eigenes Verzeichnis unter clusters/, das definiert:

• Infrastrukturkomponenten, die allen Clustern gemeinsam sind (cert-manager, ingress) — referenziert aus einem geteilten infrastructure/-Verzeichnis.
• Applikations-Deployments spezifisch für die Umgebung dieses Clusters — referenziert aus umgebungsspezifischen Overlays.

# clusters/prod-westeurope/apps/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - ../../../apps/my-service/overlays/prod
  - ../../../apps/api-gateway/overlays/prod

Promotions-Ablauf: Ein PR, der den Image-Tag in apps/my-service/overlays/dev aktualisiert, triggert das Deployment nach Dev. Nach Validierung aktualisiert ein zweiter PR overlays/staging, dann overlays/prod. Jeder Schritt ist ein reviewter, auditierbarer Git-Commit.

Progressive Delivery mit Flagger

Für Produktions-Deployments kombinieren Sie Flux mit Flagger, um Canary-Releases oder Blue-Green-Deployments zu ermöglichen.

Flagger überwacht ein Deployment, erstellt einen Canary, verschiebt schrittweise Traffic und promoted oder rollt automatisch zurück — basierend auf Metriken:

apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
  name: my-service
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-service
  progressDeadlineSeconds: 600
  service:
    port: 80
  analysis:
    interval: 1m
    threshold: 5
    maxWeight: 50
    stepWeight: 10
    metrics:
      - name: request-success-rate
        thresholdRange:
          min: 99
        interval: 1m

Diese Konfiguration verschiebt Traffic in 10-%-Schritten von 0 % auf 50 % zum Canary und rollt automatisch zurück, wenn die Erfolgsrate unter 99 % fällt.

Operative Praktiken

Reconciliation überwachen

• Nutzen Sie flux get kustomizations und flux get helmreleases, um den Reconciliation-Status zu prüfen.
• Exportieren Sie Flux-Metriken nach Prometheus und erstellen Sie Grafana-Dashboards für Reconciliation-Latenz, Fehler und Drift-Events.
• Richten Sie Alerts für anhaltende Reconciliation-Fehler ein — diese deuten auf ein fehlerhaftes Manifest in Git oder ein clusterseitiges Problem hin.

Umgang mit Drift

Flux reconciliert kontinuierlich, was bedeutet, dass manuelle kubectl-Änderungen zurückgesetzt werden. Das ist ein Feature, kein Bug — aber kommunizieren Sie es klar an Ihre Teams.

• Nutzen Sie Flux' Field-Manager-Annotationen, um bestimmte Felder von der Reconciliation auszunehmen, wenn manuelle Overrides tatsächlich nötig sind (z. B. HPA-verwaltete Replicas).
• Auditieren Sie zurückgesetzte Änderungen in Flux-Logs, um Teams oder Prozesse zu identifizieren, die noch manuelle Änderungen vornehmen.

Disaster Recovery

• Ihr Fleet-Repo ist Ihr Disaster-Recovery-Plan. Um einen Cluster neu aufzubauen, bootstrappen Sie Flux gegen denselben Repo-Pfad.
• Testen Sie das regelmäßig. Erstellen Sie einen frischen AKS-Cluster, bootstrappen Sie Flux, und verifizieren Sie, dass alle Workloads hochkommen. Wenn nicht, hat Ihr Fleet-Repo implizite Abhängigkeiten, die Sie explizit machen müssen.

Zentrale Erkenntnisse

GitOps mit Flux auf AKS ist nicht nur ein Deployment-Mechanismus — es ist ein Betriebsmodell, das Auditierbarkeit, Reproduzierbarkeit und deklarative Infrastruktur durchsetzt. Die Investition liegt in der Repository-Struktur und den Promotions-Workflows, nicht im Tooling selbst.

Sie planen eine GitOps-Implementierung auf AKS? Kontaktieren Sie unser Team — wir entwerfen und implementieren GitOps-Plattformen für Enterprise-Kubernetes-Umgebungen.