Flux 2.8 und Helm v4: Der GitOps-Upgrade-Guide

The Nix Adoption Ladder: Six Levels of Reproducible Infrastructure

Nix is not all-or-nothing. From a pinned devShell to immutable A/B-OTA appliances — six levels of adopting the Nix spirit, with real experience from K3s clusters, air-gapped registries, and Nix-built mail server containers.

Warum dieses Release wichtig ist

Flux v2.8.0 erreichte am 24. Februar 2026 den GA-Status — das bedeutendste Feature-Release seit Flux v2.0. Es bringt die Unterstützung für Helm v4 mit, wodurch Server-Side Apply und kstatus-basierte Health-Checks für Helm-Releases eingeführt werden. Helm v4.0.0 selbst erreichte bereits im November 2025 den GA-Status; eine Hauptversion mit Breaking Changes für das CLI, das Plugin-System und Post-Renderer.

Zwei konvergierende Änderungen sind entscheidend, wenn Sie GitOps in der Produktion betreiben:

1. Flux verwaltet Helm-Releases nun mit Helm v4 — und sowohl Server-Side Apply als auch kstatus Health-Checking sind die neuen Standardeinstellungen.
2. Helm v4 hat die Funktionsweise von Post-Renderern geändert — die Standard-Post-Render-Strategie ist nun combined, was reale Workloads beeinträchtigt (Details siehe unten).

Dieser Leitfaden führt Sie durch die Änderungen, die Fehlerquellen und den Weg zur Migration ohne Drama.

Was ist neu in Flux 2.8

Helm v4 Breaking Changes (die schmerzhaften Änderungen)

Post-Renderer sind nun Plugins

Helm v4 implementiert Post-Renderer als Plugins. Sie können kein ausführbares Programm mehr direkt an helm render --post-renderer übergeben — es muss ein Plugin-Name angegeben werden. Jeder bestehende Post-Renderer-Workflow benötigt nun einen Plugin-Wrapper.

Die Standard-Post-Render-Strategie wurde auf combined geändert

Dies ist die Breaking Change, die Ihnen am wahrscheinlichsten Probleme bereiten wird. In Helm 4 werden Hooks nun in den YAML-Stream integriert, der an die Post-Renderer übergeben wird. Ein Post-Renderer wie Kustomize — der keine mehreren Objekte mit demselben vollqualifizierten Namen zulässt — schlägt fehl, wenn ein Chart beispielsweise eine RBAC-Ressource erneut definiert, die bereits von einem pre-install Hook verwendet wird und auch in den regulären Templates erscheint.

Helm 4 definiert drei Strategien:

Was weiterhin funktioniert

• Charts mit apiVersion: v2 (die große Mehrheit der heutigen Charts) lassen sich weiterhin installieren und aktualisieren.
• Die SDK-API ist nun stabil und bietet Raum für die kommende Charts v3 API-Version.
• OCI-basierte Chart-Workflows funktionieren weiterhin — mit verbessertem Registry-Handling und Digest-Unterstützung.

Der Upgrade-Flow

Server-Side Apply und kstatus — die neuen Standards

Flux wird nun mit Helm v4 ausgeliefert, wobei sich zwei Dinge standardmäßig ändern:

• Das Health-Checking wechselt zu kstatus für alle HelmReleases — dieselbe Bibliothek, die auch vom kustomize-controller verwendet wird. Anstatt sich auf die veraltete Readiness-Logik von Helm zu verlassen, versteht Flux den tatsächlichen Rollout-Status von Deployments, StatefulSets, Jobs und Custom Resources, die Standard-Status-Konventionen folgen.
• Server-Side Apply ist der Standard für neue Releases. Da Helm die Apply-Methode im Release-Speicher persistiert, verwenden bestehende HelmReleases weiterhin Client-Side Apply, bis sie explizit auf die neue Methode umgestellt werden.

Für Teams, die das Verhalten von Helm v3 systemweit bevorzugen, stellt das UseHelm3Defaults Feature-Gate die vorherigen Standards wieder her — ein einziger Schalter statt eines mühsamen Prozesses pro Release.

CEL Health-Checks

Das größte Quality-of-Life-Feature für Helm-verwaltete CRDs: Flux 2.8 unterstützt CEL-basierte Health-Check-Ausdrücke in HelmReleases, was Ihnen die gleiche Flexibilität bietet, die bereits in der Kustomization-API verfügbar ist.

apiVersion: helm.toolkit.fluxcd.io/v1
kind: HelmRelease
metadata:
  name: keycloak
  namespace: auth
spec:
  interval: 5m
  chart:
    spec:
      chart: keycloak
      version: "26.x"
      sourceRef:
        kind: HelmRepository
        name: codecentric
  healthChecks:
    - apiVersion: k8s.keycloak.org/v2alpha1
      kind: Keycloak
      name: keycloak
      namespace: auth
      timeout: 5m
      expression: |
        status.conditions.filter(c, c.type == 'Ready' && c.status == 'True').size() > 0

Der Ausdruck wird gegen den Status des Objekts ausgewertet. Das Release wird erst dann als "ready" markiert, wenn die Custom Resource Ready=True meldet — etwas, das die veraltete Readiness-Logik von Helm niemals verstehen konnte.

.status.inventory — Observability

HelmReleases verfolgen nun das Inventar der verwalteten Ressourcen in .status.inventory, was Operatoren volle Sichtbarkeit für Debugging und Audits gibt. In Kombination mit den CEL Health-Checks können Sie allein über die API beantworten: "Was verwaltet dieses Release tatsächlich und ist es gesund?", ohne in Secrets oder die Release-Historie eintauchen zu müssen.

ArtifactGenerator und benutzerdefinierte Apply-Stages

Zwei kleinere Features runden das Release für Pipeline-orientierte Teams ab:

• ArtifactGenerator kann Helm-Charts aus Tarballs extrahieren und modifizieren — ideal für das Vendoring von Charts, das Patchen und die erneute Veröffentlichung als OCI-Artefakte, ohne das Upstream-Repository forken zu müssen.
• Benutzerdefinierte SSA Apply-Stages ermöglichen es dem kustomize-controller, die Reihenfolge der Ressourcen-Anwendung festzulegen. So können Sie CRDs und Controller vor den Workloads anwenden, die von ihnen abhängen, und das alles innerhalb einer einzigen Kustomization.

Flux kann nun auch direkt Kommentare in Pull Requests über Notifications hinterlassen, und GitHub App Installations-IDs werden automatisch vom Repository-Besitzer erkannt — kleine ergonomische Verbesserungen, die API-Token aus Ihrem Notification-Setup entfernen.

Reduzierte MTTR: CancelHealthCheckOnNewRevision

Flux 2.8 führt das CancelHealthCheckOnNewRevision Feature-Gate sowohl für Kustomizations als auch für HelmReleases ein. Wenn mitten in einem Health-Check eine neue Revision eintrifft, bricht Flux den veralteten Check ab, anstatt ihn bis zum Ende laufen zu lassen. Bei einem fehlgeschlagenen Rollout, gefolgt von einem Fix-Commit, muss der Fix nicht mehr auf den Timeout der alten Revision warten – die Wiederherstellungszeit sinkt drastisch.

Cosign v3 Verifizierung

Flux 2.8 fügt die Unterstützung für Cosign v3 zur Verifizierung von OCI-Artefakten und Container-Images in OCIRepositories hinzu. Beachten Sie die Versionsfixierung: Flux fixiert cosign auf v2.6.1. Stellen Sie daher sicher, dass Ihre Signing-Tools Signaturen erzeugen, die von v2.6.1 validiert werden können.

Migrations-Checkliste

1. Kubernetes-Kompatibilität prüfen. Flux unterstützt nur die letzten drei Minor-Versionen von Kubernetes. Für Flux v2.8 bedeutet das v1.33+ (Minimum 1.32.0), v1.34 und v1.35. Wenn Ihr Cluster älter ist, aktualisieren Sie diesen zuerst.
2. Charts lokal mit Helm v4 testen, bevor Sie den Cluster anfassen: helm template --validate für jedes Chart, das Sie verwalten. Die meisten Charts funktionieren unverändert; Probleme treten meist im Zusammenhang mit Post-Renderern oder Hooks auf.
3. Post-Render-Strategie festlegen. Wenn Sie einen Kustomize Post-Renderer mit Hooks verwenden, wählen Sie separate (oder nohooks für exaktes Helm 3-Verhalten), anstatt gegen den combined Standard anzukämpfen.
4. Flux aktualisieren: flux upgrade --install — die veralteten APIs aus 2024 erreichen in v2.8 ihr End-of-Life und werden aus den CRDs entfernt. Folgen Sie daher dem offiziellen Upgrade-Verfahren für v2.7+.
5. Bestehende HelmReleases beobachten. Bei dem Upgrade wechselt der Health-Check für alle Releases zu kstatus; prüfen Sie, ob ein Release vom Legacy-Readiness-Verhalten von Helm abhängig war.
6. UseHelm3Defaults nur bei absoluter Notwendigkeit setzen. Das Gate existiert zwar, aber die Standardwerte (SSA + kstatus) sind besser – testen Sie dies auf einem Staging-Cluster, bevor Sie sich dagegen entscheiden.

Rollback

• Probleme mit dem Post-Renderer: Wechseln Sie die Strategie zurück auf nohooks – dies entspricht exakt Helm 3.
• Verhaltensbedingte Regressionen: Aktivieren Sie UseHelm3Defaults auf den betroffenen Controllern.
• Worst Case: Downgrade von Flux auf v2.7.x – der Release-Speicher bleibt kompatibel, da Helm die Apply-Methode persistiert.

Worauf nach dem Upgrade zu achten ist

kstatus beeinflusst bestehende Releases. Der Wechsel des Health-Checks gilt beim Upgrade für alle HelmReleases, nicht nur für neue. Wenn ein Release vom Legacy-Readiness-Verhalten von Helm abhängig war – z. B. ein Job, der Erfolg über eine Annotation statt über Standard-Statusbedingungen meldet – wird es nun möglicherweise dauerhaft Progressing anzeigen. Suchen Sie vor dem Upgrade in Ihren Workloads nach nicht-standardmäßigen Statusmustern und fügen Sie für diese Releases im selben Schritt CEL Health-Checks hinzu.

Hooks + Kustomize ist die häufigste Fehlerquelle. Die combined Post-Render-Strategie führt genau eine Fehlerklasse hervor: „multiple objects with the same fully-qualified name“. Wenn Ihre Post-Render-Logs dies nach dem Upgrade zeigen, ist die Lösung separate und nicht der Kampf gegen den Hook-Stream.

Verifizieren, bevor Sie vertrauen. Die Cosign-Fixierung von Flux (v2.6.1) bedeutet, dass Signaturen, die von neueren cosign-Clients erstellt wurden, möglicherweise nicht verifiziert werden können. Signieren Sie in Ihrer Release-Pipeline mit einer kompatiblen Version neu, bevor Sie die OCIRepository Verifizierung aktivieren.

Weiterführende Literatur

• Kubernetes GitOps with ArgoCD — die ArgoCD-Alternative zum Vergleich
• GitOps Secrets Management in Production — Secrets während der Migration funktionsfähig halten
• Container Orchestration — die Orchestrierungs-Grundlagen hinter GitOps
• Kubernetes Gateway API Migration — ein weiterer Migrationsleitfaden aus derselben Serie