Flux déploie les charts Helm grâce à son propre helm-controller. Vous déclarez une source qui contient le chart et une HelmRelease qui indique quel chart, quelle version et quelles valeurs. Le contrôleur exécute ensuite pour vous l’installation et la mise à niveau Helm, selon un calendrier, avec tout le cycle de vie de la release géré de façon déclarative. Ce guide utilise le chart public podinfo comme exemple.

Déclarer la source du chart

Un HelmRepository indique à source-controller où se trouvent les charts. 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

À lui seul, il se contente de lister les charts disponibles. Rien n’est encore installé. La source peut se trouver dans le namespace de l’application ou dans flux-system, les deux conviennent.

Déclarer la release

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"

Les éléments qui comptent :

• chart.spec nomme le chart, une version ou une plage semver (6.x suit les nouvelles versions mineures et correctives), et la source dont il provient.
• interval est la fréquence à laquelle Flux vérifie les changements et la dérive de la release.
• values est l’équivalent d’un values.yaml, écrit en ligne. Pour une configuration plus volumineuse, chargez les valeurs depuis des ConfigMaps ou des Secrets avec valuesFrom.
• remediation contrôle ce qui se passe quand une installation ou une mise à niveau échoue. Après les tentatives autorisées, un échec de mise à niveau déclenche par défaut un rollback vers la dernière bonne release.

Ajoutez un simple namespace.yaml pour podinfo dans le même dossier, puis enregistrez le dossier avec une Kustomization Flux exactement comme dans le guide de la première application :

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

Committez et poussez. Une fois la Kustomization podinfo réconciliée, vérifiez la release :

flux get helmreleases -A
kubectl get all -n podinfo

Vous verrez la release, la version du chart installée et les Pods créés par Helm. La release Helm elle-même reste aussi visible par la CLI Helm habituelle (helm list -n podinfo), mais considérez Git comme l’endroit où vous la modifiez.

Valeurs par environnement

Superposez une configuration propre à chaque environnement à des valeurs par défaut partagées, en gardant une release de base et en la patchant par environnement avec Kustomize, ou en utilisant valuesFrom :

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

Les valeurs de valuesFrom sont fusionnées en premier, et les values en ligne les remplacent. Quand une ConfigMap ou un Secret référencé change, le helm-controller prend en compte le changement et met à niveau la release, ce qui diffère d’une simple ConfigMap qu’un Deployment lit. Pour une configuration intégrée à la propre ConfigMap du chart, ajoutez une annotation de checksum au template de Pod du chart pour que les Pods redémarrent quand la configuration change :

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

Charts depuis un registre OCI

Les charts Helm vivent de plus en plus dans des registres OCI. Utilisez un HelmRepository de type 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

La HelmRelease reste la même, sauf son sourceRef, qui pointe vers podinfo-oci. Pour des registres privés, ajoutez secretRef avec les identifiants du registre. Vous pouvez aussi référencer un chart via une source OCIRepository, ce qui permet à plusieurs releases de partager une même version de chart et de se réconcilier quand le digest de l’artefact change.

Détection de dérive et mises à niveau

Par défaut, le helm-controller réapplique une release lorsque sa spec ou son chart change. Pour aussi détecter et corriger les modifications manuelles des ressources créées par une release, activez la détection de dérive :

spec:
  driftDetection:
    mode: enabled

Sans elle, un kubectl edit manuel d’un Deployment géré par un chart peut persister jusqu’à la prochaine mise à niveau. Associez-la à interval pour que Flux compare régulièrement la réalité à la release.

Rollback et dépannage

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

describe montre l’action Helm qui a échoué et son erreur. Si une mise à niveau échoue, le contrôleur effectue un rollback automatique selon vos paramètres de remediation, et la HelmRelease signale l’échec pour que vous puissiez corriger Git. La correction durable est toujours un commit, par exemple annuler une montée de version du chart, suivi d’une réconciliation.