Flux y Argo CD son los dos principales controladores GitOps para Kubernetes. Ambos son proyectos graduados de la CNCF, ambos están listos para producción y ambos implementan los mismos cuatro principios de GitOps: declarativo, versionado, obtenido automáticamente (pull) y reconciliado continuamente. La diferencia está en el diseño, y cuál encaja depende más de tu equipo que de las funciones. Esta guía los compara para que puedas elegir, o decidir ejecutar ambos.

Dos filosofías de diseño

Argo CD está centrado en la aplicación y se distribuye como un sistema integrado: un API server, un repo server que renderiza manifiestos, un application controller y una interfaz web. Defines una Application que asigna una ruta de Git a un clúster y namespace, y Argo CD hace el resto.

Flux es un toolkit de controladores pequeños de propósito único (source, kustomize, helm, notification y, opcionalmente, automatización de imágenes) que se comunican mediante recursos personalizados. Los sources y los despliegues son objetos separados, así que un GitRepository puede alimentar varias Kustomizations. No hay una interfaz integrada, y la CLI y kubectl son la interfaz principal.

Una regla práctica útil: Argo CD encaja con equipos que quieren ver y hacer clic, Flux encaja con equipos que quieren componer y automatizar con scripts.

Lado a lado

Área	Argo CD	Flux
Arquitectura	Componentes integrados	Controladores independientes y componibles
Interfaz web	Integrada, con árbol de recursos en vivo y rollback con un clic	Ninguna integrada; CLI, Grafana o dashboards de la comunidad
Instalación	kubectl apply de un manifiesto	flux bootstrap, que también hace commit de los manifiestos de Flux en Git
Autogestión	Puede gestionarse a sí mismo, configurado por ti	Bootstrap se gestiona a sí mismo desde Git por defecto
Control de sincronización	Sincronización manual por defecto; la automatización (auto-sync, prune, self-heal) es opcional	Automático por defecto; controla producción mediante Git, etiquetas o suspend
Multiclúster	De primera clase: una instancia registra y gestiona muchos clústeres	Una instalación de Flux por clúster por defecto; clústeres remotos posibles mediante kubeconfig
Helm	Renderiza los charts como plantillas y aplica los manifiestos	helm-controller ejecuta el ciclo de vida real de Helm, con tests y rollback automático
Artefactos OCI	Soportados como sources	Sources de primera clase para manifiestos y charts de Helm
Actualizaciones de imágenes	Proyecto complementario aparte	Controladores opcionales integrados que hacen commit de etiquetas en Git
Secretos	Plugins u operators externos (Vault, External Secrets, SOPS mediante plugins)	Descifrado SOPS integrado en kustomize-controller, además de otros enfoques
Multi-tenancy	Proyectos y políticas RBAC en Argo CD	Namespaces e impersonación de service accounts, aplicados por RBAC de Kubernetes
SSO	Integrado (OIDC, SAML mediante Dex o directo)	No hace falta; el acceso es RBAC de Kubernetes
Notificaciones	Motor de notificaciones con plantillas	notification-controller con Alerts, Providers y Receivers

Cuándo encaja Argo CD

• Los desarrolladores quieren ver el estado de sincronización, el grafo de recursos y los logs sin kubectl.
• Una instancia central debe gestionar muchos clústeres, con una incorporación rápida para usuarios nuevos.
• Dependes mucho de SSO y de un portal de autoservicio para los equipos de producto.
• Tu equipo prefiere un paso de sincronización manual explícito para algunos entornos.

Cuándo encaja Flux

• Quieres actualizaciones automatizadas de imágenes confirmadas en Git.
• Los secretos deben vivir cifrados en Git con un mínimo de herramientas adicionales.
• Usas Helm intensamente y quieres una gestión real del ciclo de vida de los releases, incluido el rollback automático.
• Estás construyendo una plataforma interna y prefieres controladores componibles y RBAC nativo de Kubernetes para los tenants.
• Quieres que cada clúster sea autónomo, con credenciales que nunca salen de él.

Escalado

Ambos escalan a grandes infraestructuras. Argo CD ofrece sharding del application controller y clustering de Redis para instancias únicas muy grandes. Los controladores de Flux escalan de forma independiente y cada clúster ejecuta los suyos, lo que evita un cuello de botella central. Las cifras publicadas varían según la carga de trabajo, así que haz tus propias pruebas de rendimiento en lugar de fiarte de un número de titular.

Puedes ejecutar ambos

No son enemigos. Un reparto común es Argo CD para la entrega de aplicaciones, donde los desarrolladores se benefician de la interfaz, y Flux para los complementos del clúster, la infraestructura y los secretos. Simplemente nunca dejes que los dos gestionen los mismos recursos, o se pelearán por ellos.

Cómo elegir

1. ¿Los desarrolladores necesitan una interfaz desde el primer día? Empieza con Argo CD.
2. ¿Necesitas automatización de imágenes, descifrado de secretos integrado o autonomía estricta por clúster? Empieza con Flux.
3. ¿Sigues sin decidirte? Prueba cada uno en un clúster kind desechable durante una tarde, usando las guías de primera aplicación de esta biblioteca.

Migrar entre ellos es posible porque ambos leen YAML plano, Helm y Kustomize desde Git, pero planifícalo con cuidado: es más que renombrar archivos. Para los detalles de referencia, consulta la documentación de Flux y la documentación de Argo CD.