Grafana Kubernetes Helm-Chart v4: List-zu-Map-Migration

Wenn du Grafana, Loki und Tempo in Kubernetes via Helm betreibst, ist das hier dein Update der Woche: Grafana Labs hat das Kubernetes-Monitoring-Helm-Chart in Version 4 freigegeben – und macht damit die größte strukturelle Umstellung seit Einführung des Charts.

SCHOCK: Listen sind out — Maps sind in

Bisher waren viele Komponenten in der values.yaml als YAML-Listen modelliert. Das mag elegant aussehen, ist aber im Alltag bissig: Patches verschieben Reihenfolgen, Kustomize-Overrides werden brüchig, GitOps-Diffs explodieren bei jedem kleinen Wechsel. Mit v4 setzt Grafana auf benannte Maps.

SO sieht’s aus

Vorher:

components:
  - name: loki
    enabled: true
  - name: tempo
    enabled: true

Nachher:

components:
  loki:
    enabled: true
  tempo:
    enabled: true

Auf den ersten Blick banal. In Kombination mit Helm-Subchart-Patches, Argo-CD-Diffs und Kustomize-Overlays ist es Tag und Nacht.

HAMMER: Pod-Log-Labels jetzt opt-in

Eine zweite große Änderung: Pod-Log-Labels, die bisher automatisch auf alle Logs gestempelt wurden, sind jetzt opt-in. Das spart Index-Speicher in Loki und macht Queries schneller. Wer aber einen Workflow gebaut hat, der explizit einzelne Labels erwartet, muss diese in der neuen Map jetzt aktiv aktivieren.

EXTRA-TIPP: Migrations-Tool nutzen

Grafana liefert ein Migrations-Tool mit, das deine alte values.yaml frisst und eine v4-kompatible Version ausspuckt. Workflow:

Tool aus dem Grafana-GitHub ziehen.
Auf eine Kopie deiner values.yaml loslassen.
Output-Diff prüfen.
Ins Staging-Cluster deployen.
Dashboards, Alerts und Service-Discovery gegenchecken.
Erst danach produktiv updaten.

WARUM das jetzt wichtig ist

Grafana hat im April 2026 angekündigt, dass v3 nur noch kritische Security-Patches bekommt. Neue Features – darunter Mimir-Compactor-Tuning, Alloy-Profiles und Kubernetes-1.34-Support – landen nur in v4. Wer aktiv weiterentwickeln will, muss migrieren.

FAZIT: Migration einplanen, dann profitieren

Das Helm-Chart v4 ist eine technisch saubere, langfristig gute Entscheidung – aber kein Drop-in-Update. Plant pro Cluster ein bis zwei Stunden Aufwand ein, testet im Staging und genießt danach klare values.yaml-Diffs und schnellere Loki-Queries. Pflicht für jedes Platform-Team, das mehr als zwei Cluster betreibt.

Häufige Fragen

Was ist die wichtigste Änderung in v4?

Der Wechsel von Listen zu Maps. Bisher waren viele Komponenten als YAML-Listen modelliert – das machte Patches, Overrides und CI-Diffs unangenehm. v4 modelliert dieselben Konzepte als Maps mit benannten Schlüsseln. Wer Helm-Values mit Kustomize oder GitOps-Patches managt, profitiert sofort: keine versehentlichen Reihenfolge-Konflikte mehr.

Bricht das Update meine bestehenden Setups?

Ja, ohne Migration läuft es nicht. Grafana liefert ein Tool, das deine v3-values.yaml akzeptiert und eine v4-kompatible Version produziert. Pflicht: zuerst im Staging-Cluster testen, dann produktiv. Eine direkte In-Place-Umstellung ohne Migrations-Schritt scheitert mit Schema-Errors.

Lohnt sich der Aufwand?

Für Teams mit ein bis zwei Clustern: lieber abwarten, bis v4 ein paar Patch-Releases hinter sich hat. Für Teams mit fünf-plus Clustern und GitOps-Workflow: ja – die neue Map-Struktur spart langfristig Zeit, vor allem bei Pod-Log-Labels und individuellen Komponenten-Konfigurationen, die jetzt opt-in sind.

Wie führe ich die Migration konkret durch?

1) Migrations-Tool aus dem Grafana-GitHub ziehen, 2) auf eine Kopie deiner values.yaml laufen lassen, 3) Output-Diff prüfen, 4) ins Staging-Cluster deployen, 5) Dashboards und Alerts gegenchecken, 6) erst danach produktiv updaten. Plant 1–2 Stunden pro Cluster ein.

Quellen: Grafana Labs Blog, InfoQ Kubernetes Monitoring Helm v4 Coverage.

GRAFANA-HAMMER! K8s-Helm-Chart v4 räumt JETZT alte Listen-Hölle weg