TL;DR

Flux ist ein leichtgewichtiger GitOps-Controller der CNCF, der Kubernetes-Cluster automatisch mit Git-Repositories synchronisiert
Die Architektur besteht aus spezialisierten Controllern: Source, Kustomize, Helm, Notification und Image Automation
Installation erfolgt ueber flux bootstrap und konfiguriert sich komplett per Custom Resources (GitRepository, Kustomization, HelmRelease)
Image Automation scannt Container-Registries und aktualisiert Git automatisch bei neuen Image-Versionen
Im Vergleich zu ArgoCD ist Flux schlanker, CLI-first und besser fuer Multi-Cluster-Setups mit vielen Clustern geeignet

Kubernetes Flux GitOps: Alternative zu ArgoCD

Flux ist neben ArgoCD das zweite grosse GitOps-Tool im Kubernetes-Oekosystem. Waehrend ArgoCD mit seiner Web-UI punktet, setzt Flux auf einen schlanken, API-first-Ansatz mit spezialisierten Controllern. Fuer Teams, die GitOps ohne grossen Overhead betreiben wollen, ist Flux eine starke Alternative.

Dieser Guide zeigt die komplette Einrichtung von Flux: von der Installation ueber Helm-Charts bis zur automatischen Image-Aktualisierung.

Flux Architektur

Flux besteht aus mehreren spezialisierten Controllern, die jeweils eine Aufgabe uebernehmen:

┌────────────────────────────────────────────────────────┐
│                    Flux Controllers                     │
├──────────────┬──────────────┬──────────────┬───────────┤
│   Source      │  Kustomize   │    Helm      │ Notifi-   │
│  Controller   │  Controller  │  Controller  │ cation    │
│               │              │              │ Controller│
│  Git Repos    │  Kustomize   │  HelmRelease │ Slack     │
│  Helm Repos   │  Overlays    │  Helm Charts │ Teams     │
│  OCI Repos    │  Patches     │  Values      │ Webhooks  │
│  S3 Buckets   │              │              │           │
├──────────────┴──────────────┴──────────────┴───────────┤
│              Image Automation Controllers               │
│  Image Reflector (scannt Registries)                   │
│  Image Automation (aktualisiert Git)                   │
└────────────────────────────────────────────────────────┘

Source Controller: Holt Artefakte aus Git, Helm Repos, OCI Registries oder S3.

Kustomize Controller: Wendet Kustomize-Overlays an und deployed auf den Cluster.

Helm Controller: Verwaltet Helm Releases deklarativ per Custom Resource.

Notification Controller: Sendet Benachrichtigungen bei Events (Sync, Fehler).

Image Automation: Scannt Container-Registries und aktualisiert Image-Tags in Git.

Teil 1: Flux installieren

Voraussetzungen

# Flux CLI installieren
# macOS
brew install fluxcd/tap/flux

# Linux
curl -s https://fluxcd.io/install.sh | sudo bash

# Version pruefen
flux --version

# Cluster-Kompatibilitaet testen
flux check --pre

Erwartete Ausgabe:

> checking prerequisites
> Kubernetes 1.28.0 >=1.25.0-0
> prerequisites checks passed

Bootstrap mit GitHub

Der flux bootstrap Befehl installiert Flux und erstellt gleichzeitig das GitOps-Repository:

# GitHub Personal Access Token setzen
export GITHUB_TOKEN=ghp_xxxxxxxxxxxxxxxxxxxx

# Flux bootstrap ausfuehren
flux bootstrap github \
  --owner=myorg \
  --repository=fleet-infra \
  --branch=main \
  --path=clusters/production \
  --personal=false \
  --token-auth

Das erstellt folgende Struktur im Repository:

fleet-infra/
└── clusters/
    └── production/
        └── flux-system/
            ├── gotk-components.yaml    # Flux Controller Manifeste
            ├── gotk-sync.yaml          # Self-Management
            └── kustomization.yaml

Bootstrap mit GitLab

export GITLAB_TOKEN=glpat-xxxxxxxxxxxxxxxxxxxx

flux bootstrap gitlab \
  --owner=myorg \
  --repository=fleet-infra \
  --branch=main \
  --path=clusters/production \
  --token-auth

Installation pruefen

# Alle Flux-Komponenten anzeigen
flux check

# Flux Controller Status
kubectl get pods -n flux-system

# Flux Custom Resources
kubectl get gitrepositories -A
kubectl get kustomizations -A

Teil 2: GitRepository und Kustomization

Anwendungs-Repository verbinden

Erstellen Sie eine GitRepository-Resource, um ein Repository als Quelle zu registrieren:

apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  name: myapp
  namespace: flux-system
spec:
  interval: 5m
  url: https://github.com/myorg/myapp-deploy
  ref:
    branch: main
  secretRef:
    name: github-credentials

Kustomization fuer Deployment

Die Kustomization-Resource definiert, was aus dem Repository deployed wird:

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: myapp-production
  namespace: flux-system
spec:
  interval: 10m
  targetNamespace: production
  sourceRef:
    kind: GitRepository
    name: myapp
  path: ./overlays/production
  prune: true
  wait: true
  timeout: 5m
  healthChecks:
    - apiVersion: apps/v1
      kind: Deployment
      name: myapp
      namespace: production
  patches:
    - patch: |
        apiVersion: apps/v1
        kind: Deployment
        metadata:
          name: myapp
        spec:
          replicas: 3
      target:
        kind: Deployment
        name: myapp

Repository-Struktur fuer Flux

myapp-deploy/
├── base/
│   ├── deployment.yaml
│   ├── service.yaml
│   ├── configmap.yaml
│   └── kustomization.yaml
└── overlays/
    ├── staging/
    │   ├── kustomization.yaml
    │   └── replicas-patch.yaml
    └── production/
        ├── kustomization.yaml
        ├── replicas-patch.yaml
        └── hpa.yaml

Mehrere Anwendungen verwalten

In Ihrem Fleet-Repository definieren Sie alle Anwendungen:

fleet-infra/
└── clusters/
    └── production/
        ├── flux-system/          # Flux selbst
        ├── apps/
        │   ├── myapp.yaml        # GitRepository + Kustomization
        │   ├── api-gateway.yaml
        │   └── monitoring.yaml
        └── infrastructure/
            ├── cert-manager.yaml
            ├── ingress-nginx.yaml
            └── external-secrets.yaml

clusters/production/apps/myapp.yaml:

apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  name: myapp
  namespace: flux-system
spec:
  interval: 5m
  url: https://github.com/myorg/myapp-deploy
  ref:
    branch: main
---
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: myapp
  namespace: flux-system
spec:
  interval: 10m
  targetNamespace: production
  sourceRef:
    kind: GitRepository
    name: myapp
  path: ./overlays/production
  prune: true
  dependsOn:
    - name: cert-manager
    - name: ingress-nginx

Die dependsOn-Eigenschaft stellt sicher, dass Infrastruktur-Komponenten zuerst deployed werden.

Teil 3: Helm Charts mit Flux

HelmRepository definieren

apiVersion: source.toolkit.fluxcd.io/v1
kind: HelmRepository
metadata:
  name: bitnami
  namespace: flux-system
spec:
  interval: 1h
  url: https://charts.bitnami.com/bitnami

HelmRelease erstellen

apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
  name: redis
  namespace: flux-system
spec:
  interval: 30m
  targetNamespace: redis
  install:
    createNamespace: true
  chart:
    spec:
      chart: redis
      version: "18.x"
      sourceRef:
        kind: HelmRepository
        name: bitnami
        namespace: flux-system
  values:
    architecture: replication
    replica:
      replicaCount: 3
    auth:
      enabled: true
      existingSecret: redis-credentials
    metrics:
      enabled: true
      serviceMonitor:
        enabled: true
  valuesFrom:
    - kind: ConfigMap
      name: redis-shared-values
      optional: true

Helm Chart aus Git Repository

apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  name: myapp-chart
  namespace: flux-system
spec:
  interval: 5m
  url: https://github.com/myorg/myapp
  ref:
    branch: main
---
apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
  name: myapp
  namespace: flux-system
spec:
  interval: 15m
  targetNamespace: production
  chart:
    spec:
      chart: ./charts/myapp
      sourceRef:
        kind: GitRepository
        name: myapp-chart
  values:
    replicaCount: 3
    image:
      tag: v2.1.0

OCI Registry als Helm-Quelle

apiVersion: source.toolkit.fluxcd.io/v1beta2
kind: OCIRepository
metadata:
  name: podinfo
  namespace: flux-system
spec:
  interval: 5m
  url: oci://ghcr.io/stefanprodan/manifests/podinfo
  ref:
    tag: latest

Teil 4: Image Automation

Image Automation ist eine Staerke von Flux. Es scannt Container-Registries auf neue Tags und aktualisiert automatisch die Image-Referenzen in Git.

Image Reflector einrichten

apiVersion: image.toolkit.fluxcd.io/v1beta2
kind: ImageRepository
metadata:
  name: myapp
  namespace: flux-system
spec:
  image: ghcr.io/myorg/myapp
  interval: 5m
  secretRef:
    name: ghcr-credentials
---
apiVersion: image.toolkit.fluxcd.io/v1beta2
kind: ImagePolicy
metadata:
  name: myapp
  namespace: flux-system
spec:
  imageRepositoryRef:
    name: myapp
  policy:
    semver:
      range: ">=1.0.0"

Image Update Automation

apiVersion: image.toolkit.fluxcd.io/v1beta2
kind: ImageUpdateAutomation
metadata:
  name: myapp-auto-update
  namespace: flux-system
spec:
  interval: 30m
  sourceRef:
    kind: GitRepository
    name: myapp
  git:
    checkout:
      ref:
        branch: main
    commit:
      author:
        name: flux-bot
        email: flux@example.de
      messageTemplate: |
        chore: update image {{ .AutomationObject }}

        Automation: {{ .AutomationObject }}
        Files: {{ range $filename, $_ := .Changed.FileChanges }}{{ $filename }} {{ end }}
    push:
      branch: main
  update:
    path: ./overlays/production
    strategy: Setters

Marker in den Manifesten setzen

In Ihren Deployment-Manifesten markieren Sie die Image-Referenz:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  template:
    spec:
      containers:
        - name: myapp
          image: ghcr.io/myorg/myapp:v1.2.3 # {"$imagepolicy": "flux-system:myapp"}

Flux erkennt den Marker-Kommentar und aktualisiert den Tag automatisch, wenn eine neue Version verfuegbar ist.

Teil 5: Flux vs ArgoCD im Vergleich

Kriterium	Flux	ArgoCD
Architektur	Mehrere spezialisierte Controller	Monolithischer Controller
UI	Keine native UI (Weave GitOps optional)	Eingebaute Web-UI
Sync-Modell	Pull (Git zu Cluster)	Pull (Git zu Cluster)
CLI	Sehr umfangreich	Umfangreich
Helm Support	Nativer HelmRelease CR	Via Application CR
Image Automation	Eingebaut (scannt + aktualisiert Git)	Separater Image Updater
Multi-Cluster	Per Bootstrap pro Cluster	Zentrale Verwaltung
Multi-Tenancy	Per Namespace-Isolation	Per Project/RBAC
Notifications	Eingebauter Controller	Plugin/ConfigMap
Lernkurve	Mittel (CLI-fokussiert)	Niedrig (UI-gestuetzt)
Ressourcen	Ca. 200MB RAM	Ca. 500MB+ RAM
CNCF Status	Graduated	Graduated

Wann Flux waehlen?

Team bevorzugt CLI und deklarative Konfiguration
Viele Cluster (50+) muessen verwaltet werden
Image Automation ist ein wichtiger Workflow
Ressourcen-Effizienz ist wichtig
Kein Bedarf an zentraler Web-UI

Wann ArgoCD waehlen?

Team braucht visuelle Uebersicht (Web-UI)
Zentrales Multi-Cluster-Management gewuenscht
Application-Sets fuer dynamische Environments
Staerkere RBAC-Anforderungen pro Projekt

Teil 6: Monitoring und Notifications

Prometheus Metriken

Flux exportiert Metriken fuer alle Controller. Aktivieren Sie ServiceMonitors:

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: flux-system
  namespace: flux-system
spec:
  selector:
    matchLabels:
      app.kubernetes.io/part-of: flux
  endpoints:
    - port: http-prom

Wichtige Metriken:

# Reconciliation-Dauer
gotk_reconcile_duration_seconds_bucket

# Reconciliation-Status (Erfolg/Fehler)
gotk_reconcile_condition{type="Ready", status="True"}
gotk_reconcile_condition{type="Ready", status="False"}

# Suspend-Status
gotk_suspend_status

Grafana Dashboard

# Flux Community Dashboard importieren
# Grafana Dashboard ID: 16714
# Oder direkt von Flux:
kubectl get configmap -n flux-system flux-grafana-dashboards -o yaml

Notification Controller konfigurieren

Slack-Benachrichtigungen bei Sync-Fehlern:

apiVersion: notification.toolkit.fluxcd.io/v1beta3
kind: Provider
metadata:
  name: slack
  namespace: flux-system
spec:
  type: slack
  channel: kubernetes-alerts
  secretRef:
    name: slack-webhook-url
---
apiVersion: notification.toolkit.fluxcd.io/v1beta3
kind: Alert
metadata:
  name: sync-alerts
  namespace: flux-system
spec:
  providerRef:
    name: slack
  eventSeverity: error
  eventSources:
    - kind: Kustomization
      name: '*'
    - kind: HelmRelease
      name: '*'
  summary: "Flux Sync-Fehler im Production-Cluster"

Microsoft Teams:

apiVersion: notification.toolkit.fluxcd.io/v1beta3
kind: Provider
metadata:
  name: teams
  namespace: flux-system
spec:
  type: msteams
  secretRef:
    name: teams-webhook-url

Teil 7: Multi-Cluster mit Flux

Flux verwaltet Multi-Cluster-Setups, indem jeder Cluster sein eigenes Bootstrap bekommt und ein gemeinsames Repository nutzt.

Repository-Struktur

fleet-infra/
├── clusters/
│   ├── production/
│   │   ├── flux-system/
│   │   └── apps/
│   ├── staging/
│   │   ├── flux-system/
│   │   └── apps/
│   └── development/
│       ├── flux-system/
│       └── apps/
├── infrastructure/
│   ├── base/
│   │   ├── cert-manager/
│   │   ├── ingress-nginx/
│   │   └── monitoring/
│   └── overlays/
│       ├── production/
│       └── staging/
└── apps/
    ├── base/
    │   └── myapp/
    └── overlays/
        ├── production/
        └── staging/

Cluster bootstrappen

# Production Cluster
flux bootstrap github \
  --owner=myorg \
  --repository=fleet-infra \
  --branch=main \
  --path=clusters/production

# Staging Cluster
flux bootstrap github \
  --owner=myorg \
  --repository=fleet-infra \
  --branch=main \
  --path=clusters/staging

Gemeinsame Infrastruktur referenzieren

clusters/production/infrastructure.yaml:

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: infrastructure
  namespace: flux-system
spec:
  interval: 1h
  retryInterval: 1m
  sourceRef:
    kind: GitRepository
    name: flux-system
  path: ./infrastructure/overlays/production
  prune: true
  wait: true

Troubleshooting

Haeufige Probleme und Loesungen

# Flux-Status aller Ressourcen pruefen
flux get all

# Spezifische Kustomization pruefen
flux get kustomizations myapp -o yaml

# Events anzeigen
flux events --for Kustomization/myapp

# Reconciliation manuell ausloesen
flux reconcile kustomization myapp --with-source

# Helm Release debuggen
flux get helmreleases -A
flux logs --kind=HelmRelease --name=redis

# Source-Probleme diagnostizieren
flux get sources git
flux get sources helm

Flux pausieren und fortsetzen

# Deployment pausieren (z.B. waehrend Wartung)
flux suspend kustomization myapp

# Wieder aktivieren
flux resume kustomization myapp

# Alle HelmReleases pausieren
flux suspend helmrelease --all -n flux-system

Zusammenfassung

Aufgabe	Befehl / Resource
Installation	`flux bootstrap github`
Git-Quelle	`GitRepository` CR
Kustomize Deploy	`Kustomization` CR
Helm Deploy	`HelmRelease` + `HelmRepository` CR
Image Update	`ImageRepository` + `ImagePolicy` + `ImageUpdateAutomation`
Status pruefen	`flux get all`
Manueller Sync	`flux reconcile kustomization myapp`
Benachrichtigungen	`Provider` + `Alert` CR

Flux ist eine hervorragende Wahl fuer Teams, die GitOps ohne grossen Overhead betreiben wollen. Die CLI-first-Philosophie und die modulare Architektur machen es besonders gut fuer automatisierte Workflows und grosse Multi-Cluster-Umgebungen geeignet.