Flux deployt Helm-Charts über seinen eigenen helm-controller. Du deklarierst eine Source, die das Chart enthält, und ein HelmRelease, das angibt, welches Chart, welche Version und welche Values. Der Controller führt dann Helm-Installation und -Upgrade für dich nach Zeitplan aus, wobei der gesamte Release-Lebenszyklus deklarativ behandelt wird. Diese Anleitung nutzt das öffentliche Chart podinfo als Beispiel.

Die Chart-Source deklarieren

Ein HelmRepository sagt dem source-controller, wo Charts liegen. apps/podinfo/helmrepository.yaml:

apiVersion: source.toolkit.fluxcd.io/v1
kind: HelmRepository
metadata:
  name: podinfo
  namespace: podinfo
spec:
  interval: 1h
  url: https://stefanprodan.github.io/podinfo

Für sich genommen listet das nur auf, welche Charts verfügbar sind. Es wird noch nichts installiert. Die Source kann im Namespace der Anwendung oder in flux-system liegen, beides ist in Ordnung.

Das Release deklarieren

apps/podinfo/helmrelease.yaml:

apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
  name: podinfo
  namespace: podinfo
spec:
  interval: 10m
  chart:
    spec:
      chart: podinfo
      version: "6.x"
      sourceRef:
        kind: HelmRepository
        name: podinfo
      interval: 1h
  install:
    remediation:
      retries: 3
  upgrade:
    remediation:
      retries: 3
  values:
    replicaCount: 2
    ui:
      color: "#34577c"

Die wichtigen Teile:

• chart.spec benennt das Chart, eine Version oder einen Semver-Bereich (6.x folgt neuen Minor- und Patch-Releases) und die Source, aus der es kommt.
• interval gibt an, wie oft Flux das Release auf Änderungen und Drift prüft.
• values entspricht einer values.yaml, inline geschrieben. Für umfangreichere Konfiguration lade Values mit valuesFrom aus ConfigMaps oder Secrets.
• remediation steuert, was passiert, wenn eine Installation oder ein Upgrade fehlschlägt. Nach den erlaubten Wiederholungen löst ein Upgrade-Fehler standardmäßig ein Rollback auf das letzte gute Release aus.

Füge im selben Ordner eine einfache namespace.yaml für podinfo hinzu und registriere den Ordner mit einer Flux-Kustomization genau wie in der Anleitung zur ersten Anwendung:

flux create kustomization podinfo \
  --source=GitRepository/flux-system \
  --path=./apps/podinfo --prune=true --interval=10m \
  --export > clusters/dev/podinfo.yaml

Committe und pushe. Sobald die Kustomization podinfo abgeglichen ist, prüfe das Release:

flux get helmreleases -A
kubectl get all -n podinfo

Du siehst das Release, die installierte Chart-Version und die von Helm erstellten Pods. Das Helm-Release selbst ist auch für die normale Helm-CLI sichtbar (helm list -n podinfo), aber betrachte Git als den Ort, an dem du es änderst.

Values pro Umgebung

Lege umgebungsspezifische Konfiguration über gemeinsame Standardwerte, indem du ein Basis-Release hältst und es pro Umgebung mit Kustomize patchst oder valuesFrom nutzt:

spec:
  valuesFrom:
    - kind: ConfigMap
      name: podinfo-values
      valuesKey: values.yaml

Values aus valuesFrom werden zuerst zusammengeführt, und Inline-values überschreiben sie. Ändert sich eine referenzierte ConfigMap oder ein Secret, greift der helm-controller die Änderung auf und upgradet das Release, was sich von einer einfachen ConfigMap unterscheidet, die ein Deployment liest. Für Konfiguration, die in die eigene ConfigMap des Charts eingebacken ist, füge dem Pod-Template des Charts eine Prüfsummen-Annotation hinzu, damit Pods bei Konfigurationsänderungen neu starten:

  template:
    metadata:
      annotations:
        checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum }}

Charts aus einer OCI-Registry

Helm-Charts liegen zunehmend in OCI-Registries. Nutze ein HelmRepository vom Typ oci:

apiVersion: source.toolkit.fluxcd.io/v1
kind: HelmRepository
metadata:
  name: podinfo-oci
  namespace: podinfo
spec:
  type: oci
  interval: 1h
  url: oci://ghcr.io/stefanprodan/charts

Das HelmRelease bleibt bis auf seine sourceRef gleich, die auf podinfo-oci zeigt. Für private Registries füge secretRef mit Registry-Zugangsdaten hinzu. Du kannst ein Chart auch über eine OCIRepository-Source referenzieren, was mehreren Releases erlaubt, eine Chart-Version zu teilen und bei Änderungen am Digest des Artefakts abzugleichen.

Drift-Erkennung und Upgrades

Von Haus aus wendet der helm-controller ein Release erneut an, wenn sich seine Spec oder sein Chart ändert. Um auch manuelle Änderungen an den von einem Release erstellten Ressourcen zu erkennen und zu korrigieren, aktiviere die Drift-Erkennung:

spec:
  driftDetection:
    mode: enabled

Ohne sie kann ein manuelles kubectl edit eines vom Chart verwalteten Deployments bis zum nächsten Upgrade bestehen bleiben. Kombiniere sie mit interval, damit Flux die Realität regelmäßig gegen das Release vergleicht.

Zurückrollen und Fehler beheben

flux get helmreleases -A
kubectl describe helmrelease podinfo -n podinfo
flux reconcile helmrelease podinfo -n podinfo

describe zeigt die fehlgeschlagene Helm-Aktion und ihren Fehler. Schlägt ein Upgrade fehl, rollt der Controller anhand deiner Remediation-Einstellungen automatisch zurück, und das HelmRelease meldet den Fehler, damit du Git korrigieren kannst. Die dauerhafte Lösung ist immer ein Commit, zum Beispiel das Zurücknehmen einer Chart-Versionserhöhung, gefolgt von einem Abgleich.