Flux 2.8 und Helm v4: Der GitOps-Upgrade-Guide
🇬🇧 Read in English~7 min read
DevOpsKubernetesfluxhelmgitopskuberneteskstatusssacosignkustomize
Back openDesk Edu for a sovereign, open-source education — every vote counts.
Vote nowSave products you love by clicking the heart icon.
Produktionsmuster für Edge Computing mit k3s — Multi-Cluster-Management, Offline-First-Deployments, GitOps und Observability in großem Maßstab.
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:
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.
| Feature | Auswirkung |
|---|---|
| Helm v4 Unterstützung | Server-Side Apply + kstatus Health-Checks für HelmReleases |
| CEL Health-Checks (HelmRelease) | Benutzerdefinierte Readiness-Evaluierung für CRDs |
.status.inventory | Inventar der verwalteten Ressourcen im HelmRelease-Status |
CancelHealthCheckOnNewRevision | Reduzierte mittlere Wiederherstellungszeit (MTTR) |
| Cosign v3 Unterstützung | Verifizierung von OCI-Artefakten und Container-Images |
| ArtifactGenerator | Extrahieren und Modifizieren von Helm-Charts aus Tarballs |
| Benutzerdefinierte SSA Apply-Stages | Reihenfolge der Ressourcen-Anwendung im kustomize-controller |
| PR-Kommentare über Notifications | Flux kann direkt Kommentare in Pull Requests hinterlassen |
UseHelm3Defaults Feature-Gate | Wiederherstellung des Helm v3-Verhaltens systemweit |
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.
combined geändertDies 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:
| Strategie | Verhalten | Anwendungsfall |
|---|---|---|
combined (Standard) | Hooks + Templates in einem Stream | Kein Post-Renderer oder einer, der Duplikate toleriert |
separate | Hooks und Templates werden in unabhängigen Aufrufen post-rendered | Post-Renderer, die anhand der Identität deduplizieren (Kustomize) |
nohooks | Hooks bleiben unberührt, nur Templates werden post-rendered | Helm 3 Verhalten — Kustomize-Patches gegen reine Template-Ressourcen |
apiVersion: v2 (die große Mehrheit der heutigen Charts) lassen sich weiterhin installieren und aktualisieren.Flux wird nun mit Helm v4 ausgeliefert, wobei sich zwei Dinge standardmäßig ändern:
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.
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 — ObservabilityHelmReleases 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.
Zwei kleinere Features runden das Release für Pipeline-orientierte Teams ab:
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.
CancelHealthCheckOnNewRevisionFlux 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.
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.
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.separate (oder nohooks für exaktes Helm 3-Verhalten), anstatt gegen den combined Standard anzukämpfen.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+.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.nohooks – dies entspricht exakt Helm 3.UseHelm3Defaults auf den betroffenen Controllern.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.