GitOps con Argo CD y Flux: CD Declarativo para Kubernetes

GitOps es un modelo operativo para Kubernetes donde Git es la única fuente de verdad del estado tanto de las aplicaciones como de la infraestructura. Describes el estado deseado de un clúster de forma declarativa — Deployments, Services, ConfigMaps, CRDs — y lo confirmas en un repositorio. Un agente dentro del clúster reconcilia continuamente el estado real hacia lo que dice Git. Cada cambio es un pull request, cada rollback es un git revert, y tu historial de commits es el registro de auditoría.

La distinción clave es CD pull vs push. En un modelo push (CI/CD clásico como GitLab CI/CD o GitHub Actions ejecutando kubectl apply), el pipeline necesita credenciales del clúster y empuja los cambios hacia adentro. En el modelo pull, un operador que corre dentro del clúster observa Git y aplica los cambios por sí mismo. Ningún sistema externo guarda credenciales de kube-admin, el drift se corrige automáticamente y el clúster puede vivir en una red privada sin acceso entrante.

Los cuatro principios de GitOps (del proyecto OpenGitOps) son: el sistema es declarativo; el estado deseado está versionado y es inmutable en Git; los cambios aprobados se traen automáticamente; y los agentes de software reconcilian continuamente y alertan ante divergencias. Argo CD y Flux son las dos herramientas graduadas por la CNCF que implementan este modelo — esta guía cubre ambas en profundidad.

Argo CD es un controlador GitOps declarativo con una interfaz web de primera clase, CLI y API. Su núcleo es el application-controller, que reconcilia recursos Application comparando los manifiestos deseados (renderizados desde Git) contra el estado real del clúster y reportando un estado de sync (Synced/OutOfSync) y un estado de salud. El repo-server clona Git y renderiza charts de Helm, overlays de Kustomize o YAML plano en manifiestos. El API server respalda la UI, la CLI y el RBAC/SSO.

Desde la línea 3.x, ApplicationSet y Notifications vienen incluidos en la distribución central — sin instalaciones aparte. Argo CD 3.0 integró el applicationset-controller y el controlador de notificaciones en los manifiestos por defecto, cambió el RBAC granular para que las políticas ya no se propaguen a los sub-recursos, e hizo que los selectores anidados de ApplicationSet siempre apliquen. El proyecto publica una versión menor cada trimestre aproximadamente y soporta las tres menores más recientes.

La instalación es un único manifiesto en el namespace argocd. Argo CD guarda su estado en Kubernetes (las Applications son CRDs; las credenciales de clúster y repositorio son Secrets) más Redis para caché — no hay base de datos externa. Para producción, pon el API server detrás de tu proveedor de identidad vía OIDC/SSO, habilita RBAC y corre Argo CD en su propio clúster de gestión o junto a las cargas de trabajo. La línea 3.5 refuerza aún más la seguridad de la cadena de suministro con mTLS interno entre componentes y verificación de firmas de commits de Git.

Flux (Flux CD) es un conjunto de controladores del GitOps Toolkit componibles, no un monolito. El source-controller obtiene artefactos de fuentes GitRepository, OCIRepository o HelmRepository; el kustomize-controller construye y aplica overlays de Kustomize vía server-side apply; el helm-controller gestiona objetos HelmRelease; y el notification-controller maneja webhooks entrantes y alertas salientes. Cada controlador es un reconciliador pequeño e independiente que adoptas a la carta.

No trae UI incluida — Flux se maneja por CLI y API, lo que lo hace liviano y una opción natural para equipos de plataforma y automatización de flotas. Arrancas Flux con flux bootstrap, que instala los controladores y confirma sus propios manifiestos en tu repositorio, de modo que el propio Flux se gestiona por GitOps. Los CRDs Kustomization y HelmRelease luego declaran qué sincronizar, desde qué fuente, con qué frecuencia y si hacer prune.

Flux 2.x es estable y está graduado por la CNCF. Flux 2.8 agregó soporte para Helm v4 con server-side apply y chequeos de salud más ricos; Flux 2.9 (2026) introdujo un sistema de plugins para la CLI, reglas de ignorar campos en server-side apply para control fino del drift, autenticación a AWS CodeCommit vía Workload Identity, y descubrimiento de directorios por patrones de ruta en el ArtifactGenerator para monorepos. Los controladores de automatización de imágenes permiten a Flux escribir nuevos tags de imagen de vuelta a Git.

Ambas herramientas están graduadas por la CNCF, son pull-based y están probadas en producción — la elección es sobre ergonomía y alcance. Argo CD te da una UI multi-tenant pulida, SSO/RBAC integrados y un modelo mental centrado en aplicaciones; brilla cuando muchos equipos o personas no expertas necesitan visibilidad de qué está desplegado y por qué está OutOfSync. Flux es un toolkit minimalista con un controlador por preocupación que compone limpiamente, tiene una huella diminuta y trata todo (incluido a sí mismo) como CRDs reconciliables — ideal para equipos de plataforma que automatizan flotas grandes.

Diferencias prácticas: Argo CD centraliza la visibilidad (una UI para todos los clústeres) y suele correrse desde un clúster de gestión que alcanza a los clústeres de carga; Flux corre una copia por clúster y se maneja enteramente por CLI/GitOps, combinándose bien con Terraform y Cluster API para el aprovisionamiento de flotas. Para progressive delivery, Argo CD se combina con Argo Rollouts, mientras que Flux se combina con Flagger. Ambas integran SOPS; ambas soportan Helm y Kustomize; ambas soportan artefactos OCI como alternativa a Git.

No tienes que elegir solo una. Un patrón común es Flux para los add-ons del clúster y componentes de plataforma (arrancados y autogestionados) con Argo CD para los equipos de aplicación que quieren una UI. Elige Argo CD cuando la experiencia de desarrollo y la visibilidad multi-tenant importen más; elige Flux cuando quieras un motor componible y de bajo overhead y gestionar todo como código. Ambas son apuestas seguras a largo plazo en 2026.

El CRD Application es la unidad atómica de Argo CD: apunta a una fuente (URL del repo, revisión, ruta) y a un destino (clúster + namespace), con un syncPolicy que puede ser manual o automated. La sincronización automática con prune: true elimina los recursos quitados de Git, y selfHeal: true revierte los cambios manuales en el clúster. Este único recurso es el bloque de construcción de todo lo demás.

ApplicationSet genera muchas Applications a partir de un generador, eliminando el copiar-pegar. Los generadores incluyen list (valores estáticos), git (una app por directorio o por archivo en un repo), cluster (una app por clúster registrado), matrix y merge (combinan generadores), y generadores de pull request para entornos de vista previa efímeros. Habilita goTemplate: true para expresiones completas de plantillas Go en el template de la app.

Un uso típico: un generador de directorios git que crea una Application por cada carpeta bajo tenants/*, de modo que incorporar un nuevo tenant es solo agregar un directorio y abrir un PR. Combinado con el generador cluster, un ApplicationSet puede desplegar el mismo add-on a cada clúster de tu flota automáticamente, con valores por clúster inyectados desde las etiquetas del clúster.

El patrón app-of-apps usa una única Application raíz cuya fuente es un directorio lleno de otros manifiestos de Application. Sincronizar la raíz crea y gestiona todas las Applications hijas, dándote un solo lugar para arrancar todas las cargas de trabajo de un clúster. Es la forma clásica de declarar 'todo lo que corre este clúster' en una ruta de Git y dejar que Argo CD lo despliegue en abanico.

App-of-apps es ideal para el bootstrap: apunta una app raíz a argocd/apps/, confirma ahí los YAMLs de Application hijos, y cada archivo nuevo se convierte en una aplicación gestionada en la próxima sincronización. Mantiene el orden simple y hace que el inventario completo del clúster sea revisable en un solo PR. Muchos equipos lo combinan con sync waves para que los componentes de plataforma (CNI, ingress, cert-manager) suban antes que las cargas de aplicación.

Para conjuntos dinámicos, ApplicationSet suele ser la mejor opción moderna — genera hijas de forma programática en vez de requerir un archivo YAML por app. Un híbrido común es una raíz app-of-apps que incluye uno o más ApplicationSets: la raíz te da un único punto de arranque, y los ApplicationSets manejan el abanico repetitivo (por tenant, por clúster). Usa app-of-apps para la estructura y ApplicationSet para la escala.

Argo CD aplica todos los recursos de una sincronización juntos por defecto, pero los despliegues reales necesitan orden. Los sync waves lo imponen: anota los recursos con argocd.argoproj.io/sync-wave: "N" y Argo CD aplica primero los números menores, esperando a que los recursos de cada wave estén sanos antes de empezar el siguiente. Usa waves negativas para prerrequisitos (namespaces, CRDs) y waves más altas para cargas dependientes.

Los resource hooks corren en fases de una sincronización: PreSync (por ejemplo, un Job de migración de base de datos antes de que la app se despliegue), Sync, PostSync (pruebas de humo después) y SyncFail (limpieza ante fallos). Anota un recurso con argocd.argoproj.io/hook y controla la limpieza con hook-delete-policy (por ejemplo, HookSucceeded para borrar un Job una vez que pasa). Los hooks son la forma de tejer pasos imperativos dentro de una sincronización declarativa.

Flux expresa la misma intención de otra manera: el orden viene de dependsOn entre objetos Kustomization o HelmRelease, y el gating por salud usa wait: true con healthChecks para que un dependiente no reconcilie hasta que su prerrequisito esté Ready. Los hooks de Helm siguen funcionando en ambas herramientas para pasos de ciclo de vida a nivel de chart. Elige sync waves/hooks en Argo CD y dependsOn en Flux para modelar el orden de despliegue.

Ambas herramientas renderizan manifiestos con las mismas herramientas del ecosistema en vez de reinventar el templating. En Argo CD, la source de una Application puede apuntar a un chart de Helm (con helm.values, valueFiles y releaseName) o a un directorio de Kustomize — el repo-server ejecuta helm template o kustomize build y aplica el resultado. Ten en cuenta que Argo CD instala charts renderizándolos, así que los hooks de Helm se mapean a los hooks de Argo CD.

Flux mantiene Helm verdaderamente nativo vía el helm-controller y el CRD HelmRelease, ejecutando releases reales de Helm (con historial y rollback) y, desde Flux 2.8, Helm v4 con server-side apply. Kustomize lo maneja el kustomize-controller aplicando overlays del lado del servidor. Las fuentes — Git, un registro OCI o un repositorio Helm — están desacopladas del release, así que puedes fijar una versión de chart y reconciliar en un intervalo.

Una buena práctica con cualquiera de las dos es base + overlays: una base de Kustomize con overlays por entorno (staging/producción) o un chart con values-*.yaml por entorno. Mantén las diferencias entre entornos en los values y patches, no en manifiestos bifurcados. Fija las versiones de chart e imagen de forma explícita para que una reconciliación sea reproducible, y deja que GitOps — no un helm upgrade desde un portátil — sea la única vía a producción.

Los Secrets planos de Kubernetes solo están codificados en base64, así que confirmarlos en Git es inseguro. GitOps tiene tres respuestas principales. Sealed Secrets (Bitnami) cifra un Secret con una clave pública cuya mitad privada nunca sale del clúster; el SealedSecret resultante es seguro para confirmar, y el controlador dentro del clúster lo descifra en un Secret real. No necesita ningún sistema externo — ideal para clústeres autocontenidos.

El External Secrets Operator (ESO) mantiene los secretos en un vault real (AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, HashiCorp Vault y más de 40 proveedores) y los sincroniza a Kubernetes vía un ExternalSecret que referencia un SecretStore. Git solo guarda punteros, nunca texto cifrado; la rotación ocurre en el vault y ESO refresca en un intervalo. Las APIs v1 de ESO son GA, y es la opción por defecto cuando ya corres un gestor de secretos en la nube.

SOPS (con age o KMS) cifra los valores de los secretos en el lugar para que el YAML siga siendo amigable a los diffs y revisable. Flux descifra SOPS de forma nativa — configura decryption.provider: sops en una Kustomization con un Secret de clave age — y Argo CD lo soporta vía el ecosistema KSOPS / argocd-vault-plugin. Regla práctica: Sealed Secrets para necesidades simples locales al clúster, ESO cuando un vault es la fuente de verdad, SOPS para cifrado a nivel de archivo que vive en Git.

El progressive delivery reemplaza los despliegues de golpe con lanzamientos canary y blue-green automatizados y controlados por métricas. En el ecosistema Argo, Argo Rollouts introduce un CRD Rollout que reemplaza a un Deployment y define pasos explícitos — poner 20% de peso, pausar, ejecutar un AnalysisTemplate contra Prometheus, y luego avanzar o hacer auto-rollback. Te da control preciso y ordenado y se integra con la UI de Argo CD.

Flagger toma el enfoque opuesto: mantienes un Deployment estándar, y un recurso Canary describe el análisis (peso por paso, intervalo, umbrales de métricas). Flagger sube el tráfico automáticamente según stepWeight en cada intervalo mientras las métricas pasen, y hace rollback ante una violación — sin lista manual de pasos. Nació en el mundo del service mesh y dirige el tráfico vía Istio, Linkerd, App Mesh, Gateway API o controladores de ingress soportados.

Cómo elegir entre ellos: Argo Rollouts requiere migrar los Deployments al CRD Rollout pero da control explícito paso a paso y una gran UI — un compañero natural de Argo CD. Flagger no necesita cambios de manifiesto en tus cargas y automatiza la progresión declarativamente — un compañero natural de Flux. Ambos soportan canary, blue-green y análisis de métricas vía Prometheus/Datadog/etc.; ambos son de grado producción en 2026. Empareja la herramienta con tu motor de CD y con cuánto control manual quieras.

GitOps brilla en las flotas. Argo CD soporta multi-cluster desde un plano de control central: registra clústeres externos con argocd cluster add (guarda un Secret por clúster con el endpoint de la API y credenciales), y luego apúntalos desde el destination.server de una Application. Un solo Argo CD puede gestionar decenas de clústeres, con la UI dando un único panel de control sobre todos ellos.

Para escalar esto sin escribir a mano una Application por clúster, usa un ApplicationSet con el generador de cluster: emite una Application por clúster registrado, inyectando el nombre del clúster, la URL del servidor y las etiquetas en el template. Así es como los equipos despliegan add-ons de plataforma (ingress, cert-manager, monitoreo) a una flota entera desde un solo manifiesto, con overrides por clúster impulsados por etiquetas en el Secret del clúster.

El modelo de Flux es un Flux por clúster, cada uno arrancado en su propia ruta dentro de un repo 'fleet' compartido — una estructura que combina naturalmente con Cluster API y Terraform para el aprovisionamiento. No hay UI central, pero la autonomía por clúster mejora el aislamiento del radio de impacto. Ambos enfoques funcionan a escala; elige control central (Argo CD) para visibilidad unificada, o reconciliadores descentralizados (Flux) para aislamiento y gestión de flotas como infraestructura-como-código.

El bucle de reconciliación es lo que hace que GitOps sea más que 'CI que ejecuta kubectl'. El syncPolicy.automated de Argo CD con selfHeal: true significa que cualquier kubectl edit manual que se desvíe de Git se detecta y revierte; prune: true elimina los recursos que quitaste de Git. Sin automatización, Argo CD igual detecta el drift y muestra OutOfSync, dejando la sincronización a una persona — útil para producción con control de cambios.

Ajusta el comportamiento con syncOptions: ServerSideApply=true para aplicaciones conscientes del field-manager, CreateNamespace=true, PrunePropagationPolicy=foreground, y un backoff de retry para sincronizaciones inestables. Usa ignoreDifferences para dejar de pelear con otros controladores — por ejemplo, ignora /spec/replicas en un Deployment gestionado por un HPA, o ignora campos que inyecta un webhook mutante, para que Argo CD no reporte un drift perpetuo.

Flux reconcilia en un interval y hace cumplir el estado deseado con server-side apply; prune: true en una Kustomization recolecta los recursos eliminados, y las reglas de ignorar campos de Flux 2.9 te dejan eximir rutas específicas de la corrección de drift. En ambas herramientas, el bucle de reconciliación más las alertas (Argo CD Notifications, o el notification-controller de Flux hacia Slack/webhooks) es lo que convierte a Git en una fuente de verdad forzada y observable.

GitOps separa deliberadamente CI de CD. Tu pipeline de GitLab CI/CD o GitHub Actions compila y prueba el código, publica una imagen inmutable y fijada por digest en un registro, y luego actualiza el estado deseado en el repo de configuración — nunca ejecuta kubectl apply contra el clúster. El agente en el clúster (Argo CD o Flux) toma el commit y reconcilia. Esto mantiene las credenciales del clúster completamente fuera de CI.

Ese paso de 'actualizar el repo de configuración' lo automatiza la automatización de imágenes. El image-reflector-controller y el image-automation-controller de Flux escanean un registro (ImageRepository), seleccionan un tag mediante un ImagePolicy (semver, numérico o regex), y confirman el nuevo tag de vuelta a Git vía ImageUpdateAutomation — cerrando el ciclo con cero acceso del pipeline al clúster. Argo CD ofrece el equivalente vía Argo CD Image Updater.

Mantén dos repositorios: un repo de app (código fuente, CI) y un repo de configuración (manifiestos, la fuente de verdad de GitOps). CI escribe solo el digest/tag de la imagen en el repo de configuración; CD lo reconcilia. Combínalo con progressive delivery para que un nuevo tag dispare un canary, y con verificación de firmas (cosign) para que solo se promuevan imágenes firmadas. Este es el pipeline canónico y seguro de 2026: compilar → firmar → actualizar manifiesto → reconciliar por GitOps → despliegue progresivo.

En producción, GitOps es la columna vertebral de despliegue para una flota de clústeres Kubernetes que corre decenas de microservicios. Cada cambio — subidas de versión de aplicación, configuración, add-ons de plataforma — fluye a través de un repo de configuración en Git y es reconciliado por un agente dentro del clúster. Nada llega a un clúster salvo mediante un commit revisado y versionado, y los rollbacks están a un git revert de distancia.

Argo CD 3.x (ApplicationSet + Notifications en el núcleo): A partir de Argo CD 3.0, el controlador ApplicationSet y el controlador de Notifications vienen en los manifiestos de instalación por defecto — ya no hay despliegues separados de Argoproj-Labs. 3.0 también endureció el RBAC granular (las políticas ya no se propagan a los sub-recursos) e hizo que los selectores anidados de ApplicationSet siempre apliquen. La línea 3.x sigue una cadencia menor trimestral con las tres menores más recientes soportadas.

Argo CD 3.4 / 3.5 (endurecimiento de la cadena de suministro): Los releases 3.x recientes se enfocan en seguridad y escala; v3.4.5 (julio de 2026) es el release estable actual. La línea 3.5 — todavía en release candidate a julio de 2026 — agrega soporte de mTLS en el repo-server y verificación opcional de integridad de las fuentes dry del hydrator (alpha), además de mejoras en la gestión nativa de ApplicationSet. Combinado con fuentes de artefactos OCI y verificación cosign, Argo CD puede forzar que solo se sincronicen a un clúster manifiestos firmados y atestados.

Flux 2.9 (junio de 2026): Flux 2.9 introdujo un sistema de plugins para la CLI (con los plugins Mirror y Schema), reglas de ignorar campos en server-side apply para control fino del drift, autenticación a AWS CodeCommit vía Workload Identity, y descubrimiento de directorios por patrones de ruta en el ArtifactGenerator para gestionar artefactos en monorepos. Se apoya en Flux 2.8, que trajo soporte de Helm v4 con server-side apply y chequeos de salud mejorados.

OCI como fuente GitOps de primera clase: Ambas herramientas ahora tratan los registros OCI como un par de Git para entregar manifiestos y charts. Empaquetar la configuración como un artefacto OCI inmutable y direccionado por digest — publicado por CI, verificado por cosign, referenciado por OCIRepository (Flux) o una fuente de tipo OCI (Argo CD) — da despliegues reproducibles y a prueba de manipulaciones y desacopla el artefacto de entrega del churn de ramas.

External Secrets Operator v1 GA y ESO 2.x: Las APIs centrales de ESO alcanzaron la estabilidad v1 y la línea 2.x (2.8 a julio de 2026) abarca más de 40 proveedores, haciendo de los vaults externos la forma dominante de mantener el texto cifrado fuera de Git. Junto con SOPS+age para cifrado a nivel de archivo y Sealed Secrets para necesidades locales al clúster, los equipos tienen ahora una historia de secretos madura y en capas que se adapta a cualquier topología GitOps.

El progressive delivery se vuelve estándar: Argo Rollouts (con Argo CD) y Flagger (con Flux) son ambos estándar de producción en 2026, con el enrutamiento de tráfico de Gateway API sumándose a las opciones de Istio/Linkerd/mesh. El pipeline moderno canónico es compilar → firmar (cosign) → actualizar manifiesto vía automatización de imágenes → reconciliar por GitOps → canary controlado por métricas — un camino de extremo a extremo donde cada paso es declarativo, versionado y verificable.