Flux despliega charts de Helm a través de su propio helm-controller. Declaras un source que contiene el chart y un HelmRelease que dice qué chart, qué versión y qué valores. El controlador entonces ejecuta por ti la instalación y la actualización de Helm, según un calendario, con todo el ciclo de vida del release gestionado de forma declarativa. Esta guía usa el chart público podinfo como ejemplo.

Declara el source del chart

Un HelmRepository le dice a source-controller dónde viven los 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

Por sí solo esto solo lista qué charts están disponibles. Todavía no se instala nada. El source puede vivir en el namespace de la aplicación o en flux-system, y cualquiera de los dos está bien.

Declara el 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"

Las partes importantes:

• chart.spec nombra el chart, una versión o rango semver (6.x sigue las nuevas versiones menores y de parche) y el source del que viene.
• interval es con qué frecuencia Flux comprueba el release en busca de cambios y desviaciones.
• values es el equivalente a un values.yaml, escrito en línea. Para configuraciones más grandes, carga valores desde ConfigMaps o Secrets con valuesFrom.
• remediation controla qué ocurre cuando una instalación o actualización falla. Tras los reintentos permitidos, un fallo de actualización desencadena por defecto un rollback al último release bueno.

Añade un namespace.yaml normal para podinfo en la misma carpeta y luego registra la carpeta con una Kustomization de Flux exactamente como en la guía de la primera aplicación:

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

Haz commit y push. Una vez que la Kustomization podinfo se reconcilie, comprueba el release:

flux get helmreleases -A
kubectl get all -n podinfo

Verás el release, la versión del chart que se instaló y los Pods que creó Helm. El release de Helm también sigue siendo visible para la CLI normal de Helm (helm list -n podinfo), pero trata a Git como el lugar donde lo cambias.

Valores por entorno

Superpón configuración específica de cada entorno sobre los valores compartidos manteniendo un release base y parcheándolo por entorno con Kustomize, o usando valuesFrom:

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

Los valores de valuesFrom se fusionan primero, y los values en línea los sobrescriben. Cuando cambia un ConfigMap o Secret referenciado, el helm-controller recoge el cambio y actualiza el release, lo que es distinto de un ConfigMap normal que lee un Deployment. Para la configuración incrustada en el propio ConfigMap del chart, añade una anotación de checksum a la plantilla del Pod del chart para que los Pods se reinicien cuando cambie la configuración:

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

Charts desde un registro OCI

Los charts de Helm viven cada vez más en registros OCI. Usa un HelmRepository de tipo 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

El HelmRelease sigue igual excepto por su sourceRef, que apunta a podinfo-oci. Para registros privados, añade secretRef con las credenciales del registro. También puedes hacer referencia a un chart a través de un source OCIRepository, lo que permite que varios releases compartan una versión de chart y se reconcilien ante cambios en el digest del artefacto.

Detección de desviaciones y actualizaciones

De fábrica, el helm-controller vuelve a aplicar un release cuando cambian su especificación o su chart. Para detectar y corregir también las ediciones manuales de los recursos que creó un release, activa la detección de desviaciones:

spec:
  driftDetection:
    mode: enabled

Sin ella, un kubectl edit manual de un Deployment gestionado por un chart puede persistir hasta la siguiente actualización. Combínalo con interval para que Flux compare regularmente la realidad con el release.

Revierte y soluciona problemas

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

describe muestra la acción de Helm que falló y su error. Si una actualización falla, el controlador revierte automáticamente según tus ajustes de remediation, y el HelmRelease informa del fallo para que puedas arreglar Git. La solución duradera es siempre un commit, por ejemplo revertir una subida de versión del chart, seguido de una reconciliación.