La mayoría de los equipos empieza a desplegar en Kubernetes de la misma manera: el sistema de CI construye una imagen y luego ejecuta kubectl apply o helm upgrade contra el clúster. Funciona, hasta que crece el número de aplicaciones y clústeres. Esta guía explica qué cambia cuando un agente dentro del clúster, como Flux, extrae (pull) el estado deseado de Git en su lugar, y qué compensaciones conlleva.

El modelo push y dónde se tensa

En un pipeline push, el trabajo de CI es lo único que toca el clúster:

1. Un commit desencadena las pruebas y la construcción de la imagen.
2. El trabajo actualiza un manifiesto con la nueva etiqueta de imagen.
3. El trabajo ejecuta kubectl apply (o helm upgrade) contra el clúster.

Tres problemas aparecen al escalar:

• Las credenciales viven fuera del clúster. Cada pipeline necesita un kubeconfig o credenciales de la nube, y eso se multiplica con cada aplicación y cada clúster.
• Ocurre una sola vez. Cuando el trabajo termina, nada vigila el clúster. El kubectl edit de alguien de hace dos semanas es invisible hasta que causa un incidente.
• No hay una respuesta fácil a “¿qué está desplegado?” Tienes que inspeccionar el propio clúster, porque la última ejecución del pipeline no es un registro fiable.

Invierte la dirección: pull

Con un modelo pull, un agente se ejecuta dentro del clúster, observa un repositorio de Git, compara lo que está declarado allí con lo que se está ejecutando y aplica la diferencia. Flux es ese agente. Está formado por varios controladores pequeños, cada uno con un solo trabajo:

Controlador	Qué hace
source-controller	Obtiene repositorios de Git, repositorios de Helm, artefactos OCI y buckets, y los pone a disposición de los demás
kustomize-controller	Construye y aplica manifiestos de Kubernetes (YAML plano u overlays de Kustomize) desde un source
helm-controller	Instala, actualiza, prueba y revierte releases de Helm
notification-controller	Envía alertas (Slack, Teams y otros) y recibe webhooks
controladores image-reflector / image-automation	Opcionales. Escanean registros de contenedores y hacen commit de nuevas etiquetas de imagen en Git

Developer ─▶ App repo ─▶ CI (test, build) ─▶ Image registry
                            │
                            └─ commits new image tag ─▶ Config repo
                                                            ▲
                                          Flux (in cluster) ┘ pulls, compares, applies
                                                │
                                                ▼
                                            Kubernetes

Las credenciales del clúster nunca salen de él, porque lo único que aplica cambios es el agente que se ejecuta dentro. Los ingenieros y los sistemas de CI solo necesitan acceso de escritura a Git.

Los cuatro principios de GitOps

El grupo de trabajo OpenGitOps define GitOps con cuatro principios. Flux implementa los cuatro:

1. Declarativo. El sistema se describe en YAML, no en scripts.
2. Versionado e inmutable. Git es la única fuente de verdad. Cada cambio es un commit que puede auditarse y revertirse.
3. Obtenido automáticamente (pull). Los cambios aprobados los obtiene el clúster, no se le empujan.
4. Reconciliado continuamente. Los agentes comparan el estado deseado y el real y corrigen las desviaciones.

Flux se gestiona a sí mismo

Una característica distintiva de Flux es bootstrap. El comando flux bootstrap instala Flux en el clúster y hace commit de los propios manifiestos de Flux en tu repositorio de Git, y luego configura Flux para sincronizarse desde ese mismo repositorio. Desde el día cero, incluso las herramientas GitOps se gestionan a través de Git. La siguiente guía lo recorre.

Mantén el código de la aplicación y la configuración en repositorios separados

La recomendación habitual son dos repositorios: uno para el código fuente de la aplicación y otro para la configuración de Kubernetes (Deployments, Services, HelmReleases, etc.).

La configuración cambia según su propio ritmo. Editar un Service o un ConfigMap no debería desencadenar un pipeline completo de construcción y pruebas para código que no cambió. Con dos repositorios, el último paso del pipeline de CI pasa a ser “haz commit de la nueva etiqueta de imagen en el repositorio de configuración”, y Flux se encarga del resto. También separa limpiamente la propiedad: los desarrolladores son dueños del CI, los equipos de plataforma u operaciones son dueños de la entrega.

Flux te da dos formas de llevar la nueva etiqueta de imagen al repositorio de configuración:

• El CI hace el commit. Un script del pipeline actualiza la etiqueta en el YAML y hace push. Funciona con cualquier sistema de CI.
• Flux hace el commit. Los controladores opcionales de automatización de imágenes vigilan el registro y hacen push del cambio de etiqueta a Git por sí mismos. Consulta la guía de automatización de imágenes de esta serie.

Haz de Git la única vía de entrada: corrección de desviaciones

Flux se reconcilia según un intervalo. Cuando el clúster en vivo difiere de Git, Flux vuelve a aplicar la versión de Git, así que un cambio manual se revierte. Esto tiene consecuencias prácticas:

• Cada cambio tiene un commit, un autor y normalmente un pull request revisado, lo que te da un rastro de auditoría.
• Los permisos se mueven a Git. Muchas personas pueden abrir pull requests; solo unas pocas pueden hacer merge.
• Un kubectl edit rápido en producción deja de ser un cambio silencioso y duradero.

Rollback y recuperación se vuelven operaciones de Git

Como el estado deseado está versionado, volver a un estado conocido y correcto es un git revert, y Flux hace converger el clúster hacia él. La misma idea cubre la recuperación. Si se pierde un clúster, creas uno nuevo, ejecutas flux bootstrap contra el mismo repositorio y la misma ruta, y las cargas de trabajo se recrean desde Git. Todo lo que no esté en Git, como los datos persistentes o los secretos que gestionas en otro lugar, sigue necesitando su propia estrategia de respaldo.

Lo que Flux no reemplaza

Flux es un toolkit de entrega, no una herramienta de construcción. Sigues necesitando CI para probar el código, construir imágenes y subirlas a un registro. Es específico de Kubernetes, por lo que otros destinos de despliegue necesitan otras herramientas. Y no es el único controlador GitOps: Argo CD implementa los mismos principios con un diseño distinto, que cubre la guía de comparación de esta serie. El resto de esta serie asume Flux y empieza con su instalación. Para la referencia completa, consulta la documentación oficial de Flux.