GitOps en producción: ArgoCD vs Flux en 2026 — guía de elección

GitOps lleva varios años siendo el buzzword favorito de las charlas de KubeCon, pero en 2026 ha pasado de experimento a estándar de facto en organizaciones que despliegan sobre Kubernetes. La promesa es simple: Git como fuente de verdad única, y el clúster reconciliándose continuamente con ese estado declarado.

El problema no es si adoptar GitOps, sino cuál de los dos grandes proyectos elegir: ArgoCD —el favorito de los equipos que priorizan visibilidad y experiencia de usuario— o Flux v2 —la apuesta de quienes valoran la arquitectura composable y el control fino sobre la reconciliación—. Este post te da los elementos técnicos y contextuales para tomar esa decisión con criterio.

¿Qué es GitOps de verdad (más allá del hype)?

GitOps no es simplemente "guardar los manifiestos en Git". El término, acuñado por Weaveworks en 2017, implica un modelo operativo con cuatro principios fundamentales definidos por el OpenGitOps Working Group:

1. Declarativo: todo el sistema se describe como estado deseado, no como procedimientos.
2. Versionado e inmutable: el estado deseado se almacena en Git con historial completo.
3. Pulled automáticamente: el agente en el clúster extrae los cambios; nunca se empuja desde fuera.
4. Reconciliado continuamente: el agente detecta y corrige desviaciones (drift) de forma continua.

El flujo básico en producción funciona así:

# El desarrollador solo hace esto:
git commit -m "feat: actualizar imagen a v2.1.0"
git push origin main

# El agente GitOps (ArgoCD o Flux) detecta el cambio
# compara el estado deseado con el estado actual
# y aplica la diferencia al clúster automáticamente

Nada de kubectl apply manuales, nada de secretos de cluster en el CI, y rollback instantáneo con un simple git revert.

ArgoCD: visibilidad y experiencia como arma principal

ArgoCD nació como respuesta a un problema real en Intuit: cómo gestionar cientos de aplicaciones en Kubernetes manteniendo visibilidad. Su apuesta diferencial es su interfaz web, que convierte la reconciliación GitOps en algo que cualquier miembro del equipo puede entender con un vistazo.

Instalación en minutos

# Crear namespace
kubectl create namespace argocd

# Instalar ArgoCD (manifest oficial)
kubectl apply -n argocd -f \
  https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

# Esperar que los pods estén listos
kubectl wait --for=condition=Ready pods --all \
  -n argocd --timeout=120s

# Obtener la contraseña inicial del admin
kubectl -n argocd get secret argocd-initial-admin-secret \
  -o jsonpath="{.data.password}" | base64 -d

# Port-forward para acceder a la UI
kubectl port-forward svc/argocd-server -n argocd 8080:443

Definir tu primera Application

# application.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: mi-servicio
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/nubyron/infra-gitops
    targetRevision: HEAD
    path: apps/mi-servicio
  destination:
    server: https://kubernetes.default.svc
    namespace: produccion
  syncPolicy:
    automated:
      prune: true       # elimina recursos huérfanos
      selfHeal: true    # corrige cambios manuales (drift)
    syncOptions:
      - CreateNamespace=true
      - PrunePropagationPolicy=foreground
    retry:
      limit: 5
      backoff:
        duration: 5s
        factor: 2
        maxDuration: 3m

El patrón App-of-Apps

Cuando gestionas decenas de aplicaciones, el patrón App-of-Apps es esencial: una Application raíz que apunta a un directorio de otras Applications. El resultado es un árbol de dependencias gestionado completamente desde Git.

# root-app.yaml — la Application que gestiona todas las demás
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: root-app
  namespace: argocd
spec:
  source:
    repoURL: https://github.com/nubyron/infra-gitops
    path: apps   # directorio con múltiples Application manifests
    targetRevision: HEAD
  destination:
    server: https://kubernetes.default.svc
    namespace: argocd
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

ApplicationSets: escalado dinámico

Para escenarios multi-cluster o multi-entorno, ApplicationSets es el recurso que permite generar Applications dinámicamente a partir de generadores (lista, Git, cluster, matrix):

# applicationset-multienv.yaml
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: mi-servicio-multienv
spec:
  generators:
    - matrix:
        generators:
          - clusters: {}              # itera sobre todos los clusters registrados
          - list:
              elements:
                - env: staging
                - env: production
  template:
    metadata:
      name: 'mi-servicio-{{name}}-{{env}}'
    spec:
      source:
        repoURL: https://github.com/nubyron/infra-gitops
        targetRevision: HEAD
        path: 'envs/{{env}}/mi-servicio'
      destination:
        server: '{{server}}'
        namespace: mi-servicio

Flux v2: composabilidad y control fino sobre la reconciliación

Flux v2 rompió completamente con su versión anterior y adoptó una arquitectura basada en controladores especializados siguiendo el patrón operator de Kubernetes. No hay un servidor central: cada componente de Flux es un controlador independiente que puede instalarse o no según tus necesidades.

Instalación con flux CLI

# Instalar el CLI de Flux
curl -s https://fluxcd.io/install.sh | sudo bash

# Verificar prerequisitos del clúster
flux check --pre

# Bootstrap con GitHub (crea el repo si no existe)
flux bootstrap github \
  --owner=nubyron \
  --repository=infra-gitops \
  --branch=main \
  --path=./clusters/produccion \
  --personal

# Resultado: Flux instala sus componentes en el clúster
# y comite los manifests de instalación en el repo de Git
# El clúster ahora se gestiona a sí mismo desde Git

Anatomía de Flux v2: los controladores clave

# GitRepository — define la fuente Git a monitorizar
apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  name: infra-gitops
  namespace: flux-system
spec:
  interval: 1m
  url: https://github.com/nubyron/infra-gitops
  ref:
    branch: main
  secretRef:
    name: github-credentials
---
# Kustomization — reconcilia un directorio del repo
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: mi-servicio
  namespace: flux-system
spec:
  interval: 5m
  sourceRef:
    kind: GitRepository
    name: infra-gitops
  path: ./apps/mi-servicio
  prune: true
  wait: true              # espera a que los recursos estén Ready
  timeout: 5m
  healthChecks:
    - apiVersion: apps/v1
      kind: Deployment
      name: mi-servicio
      namespace: produccion

Ventaja clave: dependencias entre Kustomizations

Una de las funcionalidades más potentes de Flux que no tiene equivalente directo en ArgoCD: definir dependencias explícitas entre Kustomizations para garantizar el orden de despliegue:

# La infraestructura debe estar lista antes de desplegar las apps
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: apps
spec:
  dependsOn:
    - name: infrastructure    # espera a que esta Kustomization esté Ready
    - name: cert-manager
  interval: 10m
  path: ./apps
  sourceRef:
    kind: GitRepository
    name: infra-gitops
  prune: true

Actualización automática de imágenes con Image Automation

# Monitorizar nuevas imágenes en el registry
apiVersion: image.toolkit.fluxcd.io/v1beta2
kind: ImageRepository
metadata:
  name: mi-servicio
spec:
  image: ghcr.io/nubyron/mi-servicio
  interval: 5m
---
# Política de selección: solo versiones semver estables
apiVersion: image.toolkit.fluxcd.io/v1beta2
kind: ImagePolicy
metadata:
  name: mi-servicio
spec:
  imageRepositoryRef:
    name: mi-servicio
  policy:
    semver:
      range: '>=1.0.0'
---
# Automation: comitea el cambio de imagen en Git automáticamente
apiVersion: image.toolkit.fluxcd.io/v1beta1
kind: ImageUpdateAutomation
metadata:
  name: flux-system
spec:
  interval: 30m
  sourceRef:
    kind: GitRepository
    name: infra-gitops
  git:
    checkout:
      ref:
        branch: main
    commit:
      author:
        email: fluxbot@nubyron.com
        name: FluxBot
      messageTemplate: 'chore: actualizar {{range .Updated.Images}}{{.}}{{end}}'
    push:
      branch: main
  update:
    strategy: Setters

Comparativa detallada: criterios que importan en producción

¿Cuál elegir? La guía de decisión

No hay una respuesta universal. El criterio de elección depende de tres factores: el perfil de tu equipo, la complejidad de tu entorno, y la importancia que le das a la experiencia operativa del día a día.

Rollback: la operación que más importa en producción

Con ArgoCD:

# Ver el historial de sync
argocd app history mi-servicio

# Rollback a un revision anterior (desde UI o CLI)
argocd app rollback mi-servicio 3

# O el rollback gitops puro: revert en Git
git revert HEAD --no-edit
git push origin main
# ArgoCD detecta el cambio y reconcilia automáticamente

Con Flux:

# Ver el estado de reconciliación
flux get kustomizations --watch

# Suspender la reconciliación momentáneamente
flux suspend kustomization mi-servicio

# El rollback GitOps: revert en Git
git revert HEAD --no-edit
git push origin main

# Reanudar la reconciliación
flux resume kustomization mi-servicio

# Forzar reconciliación inmediata
flux reconcile kustomization mi-servicio --with-source