GitOps con ArgoCD: del hype a la produccion estable

Actualizado: 2026-05-03

ArgoCD^[1] ha pasado en pocos años de proyecto interesante a práctica deploy estándar para Kubernetes. GitOps — donde el repositorio Git es la única fuente de verdad del estado deseado del cluster — ha demostrado funcionar mejor que las pipelines push tradicionales para muchos equipos. Esta guía cubre los principios, lo que ArgoCD hace bien, los errores que se ven en producción y la comparativa con Flux.

Puntos clave

• GitOps no es solo “deployar desde Git”: su esencia es la reconciliación continua que corrige el drift automáticamente.
• ArgoCD destaca por su UI rica, multi-tenancy maduro y soporte amplio de Helm, Kustomize y YAML plano.
• El patrón app-of-apps permite gestionar el cluster entero de forma declarativa.
• Los secretos nunca van en el repositorio de configuración — usa Sealed Secrets o External Secrets Operator.
• El sync mode correcto para producción al inicio es manual; escala hacia auto-sync conforme crece la confianza.

Los cuatro principios reales de GitOps

GitOps tiene cuatro principios formales:

1. Declarativo: el sistema entero se describe declarativamente (YAML de Kubernetes, manifiestos Helm/Kustomize), no como secuencia de comandos.
2. Versionado e inmutable: el estado deseado vive en Git. Cada cambio es un commit auditable.
3. Pulled automáticamente: agentes en el cluster tiran del repositorio y aplican cambios. No hay push externo desde CI.
4. Reconciliación continua: el agente compara estado real vs deseado constantemente y corrige el drift.

La implicación más importante es la cuarta. Si alguien edita un recurso a mano (kubectl edit), ArgoCD lo revierte al estado del Git. Esa diferencia con las pipelines tradicionales es el valor central.

Por qué ArgoCD ha ganado adopción

ArgoCD es la opción más popular porque combina varias ventajas:

• UI excelente: vista visual de aplicaciones, sus recursos, estado de salud y diff entre Git y cluster.
• Multi-tenancy serio: soporta múltiples equipos con permisos granulares vía RBAC + projects.
• Sync policies flexibles: manual, auto, con prune, con self-heal — cada combinación útil para escenarios distintos.
• Soporte amplio de herramientas: Helm, Kustomize, YAML plano y Jsonnet coexisten en el mismo cluster.
• App-of-apps pattern: una app de ArgoCD que despliega otras apps — útil para gestionar el cluster entero declarativamente.
• Sync waves y hooks: control sobre orden de despliegue cuando importa (CRDs antes que recursos que los usan).

Estructura típica del repositorio

config-repo/
├── applications/
│   ├── prod/
│   │   ├── app-a.yaml      # ArgoCD Application apuntando a manifests
│   │   └── app-b.yaml
│   └── staging/
│       └── ...
├── manifests/
│   ├── app-a/
│   │   ├── base/           # Kustomize base
│   │   └── overlays/
│   │       ├── prod/
│   │       └── staging/
│   └── app-b/
│       └── helm/           # Chart o values de Helm
└── argocd-bootstrap/       # Configuración del propio ArgoCD

Patrones que funcionan bien:

• Separar app code de configuración: cambios de configuración no requieren rebuild de imagen.
• Directorios por entorno (overlays Kustomize) en lugar de branches — más fácil ver diferencias.
• Image automation con commits automatizados: ArgoCD Image Updater detecta nuevas imágenes y commitea al config repo.

Sync policies: cuándo usar cada una

• Manual sync: alguien pulsa “Sync” tras cambios en Git. Recomendado en producción inicialmente.
• Auto-sync sin prune: aplica cambios pero no borra recursos que desaparecen del Git. Conservador.
• Auto-sync con prune: aplica todos los cambios y borra lo que ya no está en Git. Peligroso si alguien borra algo accidentalmente.
• Self-heal: además de aplicar Git, revierte cualquier cambio manual. GitOps estricto real.

Recomendación progresiva: manual en producción al principio, auto-sync sin prune en staging, self-heal en dev. Migrar producción a auto-sync controlado conforme crece la confianza del equipo.

Errores comunes en producción

Los errores que más se ven en proyectos reales:

• Self-heal sin disciplina de equipo: si alguien cambia algo a mano para depurar y ArgoCD lo revierte al minuto, hay frustración. Política clara: cambios manuales solo en emergencias documentadas.
• Secretos en Git: nunca. Usa Sealed Secrets, External Secrets Operator o similar.
• Repositorios de configuración monstruosos: un único repo con 200 apps es lento de sincronizar. Divide por dominio o equipo.
• Sync waves mal usadas: demasiadas dependencias entre waves complica deploys. Mantén el grafo simple.
• CRDs como app normal: las CRDs deben estar antes que los recursos que las usan. Usa sync waves o una app separada de bootstrap.
• Sin backups de la configuración de ArgoCD: ArgoCD mismo debe estar en Git (app-of-apps). Si el cluster muere, recuperas haciendo argocd app create apuntando al config repo.
• Cluster admin para todos: configura proyectos ArgoCD con permisos limitados por equipo y namespace.

Comparativa con Flux

Flux^[2] es la otra herramienta GitOps madura. Las diferencias prácticas más relevantes:

• UI: ArgoCD tiene UI rica nativa; Flux la tiene más limitada (mejorando con Weave GitOps).
• Multi-tenancy: ArgoCD usa projects; Flux usa namespaces nativos de Kubernetes.
• Filosofía: ArgoCD se siente más “aplicación”; Flux se siente más “controllers en el cluster”.
• Image automation: Flux la tiene nativa; ArgoCD requiere el componente Image Updater.
• Multi-cluster: ArgoCD soporta gestionar múltiples clusters desde una instancia; Flux asume una instancia por cluster.

Lee la comparativa completa Flux vs ArgoCD para un análisis más detallado. Ambos son graduados de la CNCF y elecciones sólidas; la diferencia está en qué encaja mejor con tu equipo.

Conclusión

ArgoCD ha consolidado GitOps como práctica deploy madura para Kubernetes. Bien implementado — con disciplina de equipo, secretos gestionados aparte y sync policies adecuadas — mejora confiabilidad de deploys, audit trail y velocidad de recuperación. Mal implementado — con secretos en Git, configuración monstruosa y sin backups — solo añade otra capa de complejidad. La diferencia está en los detalles operativos, no en la herramienta.

1. ArgoCD
2. Flux