En la mayoría de las configuraciones GitOps, tu pipeline de CI construye una imagen y luego hace commit de la nueva etiqueta en el repositorio de configuración. Flux ofrece una alternativa: dos controladores opcionales vigilan tu registro de contenedores, eligen la etiqueta más reciente que cumpla una regla y hacen el commit del cambio en Git por sí mismos. El clúster sigue cambiando solo por un commit de Git, así que conservas el rastro de auditoría. Esta guía usa la imagen pública podinfo.

Cómo encajan las piezas

Tres recursos trabajan juntos:

• ImageRepository escanea un registro en busca de las etiquetas de una imagen.
• ImagePolicy elige una etiqueta de esa lista, por ejemplo la versión semántica más alta dentro de un rango.
• ImageUpdateAutomation edita el YAML de tu repositorio de Git donde un marcador lo indica, y luego hace commit y push.

Los tres usan la API image.toolkit.fluxcd.io/v1. La versión antigua v1beta2 se eliminó de los CRD en Flux 2.9, así que migra cualquier manifiesto antiguo antes de actualizar.

Instala los controladores adicionales

Los controladores de imágenes no forman parte de una instalación predeterminada. Haz bootstrap de nuevo, añadiéndolos, y permite que Flux haga push al repositorio:

flux bootstrap github \
  --owner=<your-github-user> \
  --repository=fleet-infra \
  --branch=main \
  --path=clusters/dev \
  --personal \
  --components-extra=image-reflector-controller,image-automation-controller \
  --read-write-key

Bootstrap es seguro de repetir. Hace commit de los nuevos manifiestos de los controladores y los instala. --read-write-key hace que la deploy key tenga permiso de escritura para que la automatización pueda hacer push. Verifica con kubectl get pods -n flux-system.

Escanea el registro

apps/podinfo/image-repository.yaml, en la misma carpeta que tu deployment:

apiVersion: image.toolkit.fluxcd.io/v1
kind: ImageRepository
metadata:
  name: podinfo
  namespace: flux-system
spec:
  image: ghcr.io/stefanprodan/podinfo
  interval: 5m

Para un registro privado, añade secretRef apuntando a un secret de registro Docker, creado con kubectl create secret docker-registry o flux create secret oci.

Elige una etiqueta con una política

apiVersion: image.toolkit.fluxcd.io/v1
kind: ImagePolicy
metadata:
  name: podinfo
  namespace: flux-system
spec:
  imageRepositoryRef:
    name: podinfo
  policy:
    semver:
      range: 6.x

semver con range: 6.x selecciona la versión 6.x más alta. Otros tipos de política son numerical (el número más alto) y alphabetical, que se adaptan a etiquetas como números de build o fechas. Para reglas basadas en nombres de etiquetas, añade filterTags con una expresión regular a la política.

Marca la línea a actualizar

Flux actualiza exactamente las líneas que marcas con un comentario. En apps/podinfo/deployment.yaml:

    spec:
      containers:
        - name: podinfo
          image: ghcr.io/stefanprodan/podinfo:6.5.0 # {"$imagepolicy": "flux-system:podinfo"}

El marcador es namespace:nombre-de-la-política. Por defecto reemplaza toda la referencia de la imagen. Para actualizar solo la etiqueta, usa {"$imagepolicy": "flux-system:podinfo:tag"}, y para valores de Helm o entradas images de Kustomize el mismo marcador funciona en la línea que contiene la etiqueta. Todo lo que no tenga marcador se deja intacto.

Dile a Flux cómo hacer commit

apiVersion: image.toolkit.fluxcd.io/v1
kind: ImageUpdateAutomation
metadata:
  name: flux-system
  namespace: flux-system
spec:
  interval: 30m
  sourceRef:
    kind: GitRepository
    name: flux-system
  git:
    checkout:
      ref:
        branch: main
    commit:
      author:
        name: fluxcdbot
        email: fluxcdbot@users.noreply.github.com
      messageTemplate: |
        Automated image update

        {{range .Changed.Changes}}
        - {{.OldValue}} -> {{.NewValue}}
        {{end}}
    push:
      branch: main
  update:
    path: ./apps
    strategy: Setters

Las partes importantes:

• sourceRef es el repositorio de Git en el que hacer commit. Debe tener permiso de escritura, de ahí --read-write-key.
• checkout.ref.branch es la rama desde la que empieza, y push.branch es donde va el commit.
• update.path limita qué carpetas se escanean en busca de marcadores.
• messageTemplate controla el mensaje del commit para que el historial sea legible.

Hacer push directamente a main lo vuelve totalmente automático. Mientras construyes confianza, haz push a una rama separada (por ejemplo push.branch: flux-image-updates) y luego fusiona un pull request cuando estés conforme. El cambio llega al clúster solo después del merge.

Míralo funcionar

Haz commit y push de estos archivos y luego comprueba cada etapa:

flux get image repository
flux get image policy
flux get image update

El repositorio muestra cuántas etiquetas se escanearon, la política muestra la etiqueta que seleccionó y la automatización de actualización muestra el último commit que hizo. Si la etiqueta seleccionada es más reciente que la de tu YAML, aparece un commit en Git, y Flux lo aplica como cualquier otro cambio. Para depurar, usa kubectl describe en cada objeto: un marcador incorrecto, un rango de política que no coincide con nada o una deploy key de solo lectura son los culpables habituales.

Qué enfoque elegir

Usa commits dirigidos por CI si un solo pipeline ya es dueño de la promoción y quieres un único lugar que decida qué se despliega. Usa Flux image automation cuando quieras que el repositorio de configuración del clúster siga a un registro por sí solo, por ejemplo para mantener un entorno de desarrollo en el último parche. Ambos pueden coexistir.