Tras cubrir ArgoCD como práctica deploy, toca el otro grande del espacio GitOps: Flux CD. Ambos son proyectos CNCF graduados, ambos resuelven el mismo problema, pero con filosofías y trade-offs distintos. Cubrimos las diferencias prácticas que importan al elegir entre ambos.
Filosofías diferentes
La diferencia más fundamental:
- ArgoCD es una aplicación con UI: te conectas, ves apps, sincronizas, gestionas. La UI es ciudadana de primera clase.
- Flux es un conjunto de controllers que vive dentro del cluster. Pensado como “todo es Kubernetes-native”. La UI es opcional (Weave GitOps).
Esta diferencia se refleja en cómo cada uno modela los conceptos.
Cómo modelan las cosas
ArgoCD tiene un único CRD principal: Application. Cada Application apunta a un repo + path y se sincroniza a un destino.
Flux descompone la responsabilidad en varios CRDs:
GitRepository/HelmRepository/OCIRepository: definen una fuente.Kustomization: aplica recursos Kustomize/YAML del source.HelmRelease: aplica un Helm chart.ImageRepository/ImagePolicy/ImageUpdateAutomation: para automatización de imágenes.
La descomposición de Flux es más granular y “Kubernetes-idiomática”. La centralización de ArgoCD es más simple para empezar.
Multi-tenancy
Ambos lo soportan, con aproximaciones distintas:
ArgoCD usa el concepto de Project — agrupa apps con permisos similares. Combinado con RBAC, defines qué usuarios pueden hacer qué en qué proyectos. La UI hace explícito quién accede a qué.
Flux usa namespaces de Kubernetes nativamente. Puedes desplegar instancias de Flux por tenant en namespaces separados, o usar un Flux compartido con Kustomization por namespace + RBAC nativo. Es más “Kubernetes way” pero menos visual.
Para organizaciones grandes con muchos equipos, ambos funcionan; ArgoCD da más visibilidad a quién hace qué.
Image automation
Aquí Flux tiene una ventaja histórica:
Flux incluye image automation nativa. Detecta nuevas imágenes en un registry, evalúa contra una ImagePolicy (semver, regex, etc.), y commitea automáticamente al config repo el nuevo tag. Sin componente extra.
ArgoCD requiere ArgoCD Image Updater, un componente separado con configuración y operación propia. Funciona pero es claramente add-on.
Si automatizar el bump de tag tras cada release es importante para ti, Flux es más natural.
Soporte de Helm y Kustomize
Ambos cubren los dos sistemas, con matices:
- Flux tiene
HelmReleasecomo CRD nativo — sintaxis muy alineada conhelm install. YKustomizationpara Kustomize/YAML. - ArgoCD modela ambos dentro del mismo
Application, distinguiendo por el tipo de manifest detectado.
En Helm específicamente, Flux ofrece más opciones de gestión avanzada (rollback automático, hooks personalizados). ArgoCD lo cubre pero con menos detalle.
Notification y alerting
Cuando algo va mal en GitOps, querer enterarte importa.
Flux tiene Alert y Provider CRDs que enrutan notificaciones a Slack, Discord, MS Teams, GitHub commit status, etc. Configuración declarativa.
ArgoCD lo cubre vía ArgoCD Notifications (componente integrado). Funcionalidad similar, configuración un poco distinta.
Multi-cluster
Flux asume el modelo “una instancia de Flux por cluster”. Si tienes 10 clusters, instalas Flux en cada uno y cada uno gestiona su propio config. Coordinación cross-cluster requiere bootstrap.
ArgoCD soporta nativamente gestionar múltiples clusters desde una sola instancia. Una ArgoCD UI muestra apps de todos los clusters. Es más cómodo para equipos centralizados de plataforma.
Para multi-cluster grande, ArgoCD ofrece visibilidad central; Flux ofrece autonomía por cluster.
Curva de aprendizaje
ArgoCD: bajada media. La UI ayuda mucho a entender qué está pasando. Concepto de Application es directo.
Flux: más empinada al principio. Múltiples CRDs y conceptos. Después de pasar la curva, se siente muy “natural” en Kubernetes.
Para equipos que prefieren tooling visual y rápida productividad, ArgoCD. Para equipos comfortable con Kubernetes-as-platform, Flux puede sentirse más coherente.
Cuándo elegir cada uno
Elige ArgoCD si:
- Quieres UI rica visible para múltiples equipos.
- Multi-cluster con visibilidad central importa.
- Prefieres una herramienta unificada simple.
- Tu equipo valora UX de tooling.
Elige Flux si:
- Image automation nativa es prioridad.
- Prefieres modelar todo como CRDs Kubernetes.
- Cada cluster autónomo encaja con tu modelo.
- Tu equipo está cómodo con CLI + YAML como interfaz primaria.
No te equivocas con ninguna. Ambas son maduras, mantenidas activamente y tienen comunidades sólidas. La elección puede depender más de qué encuentre tu equipo más cómodo que de capacidades absolutas.
Patrones híbridos
Algunas organizaciones grandes usan ambas:
- ArgoCD para apps de producto con visibilidad central.
- Flux para infraestructura del cluster (ingress controllers, monitoring, operators).
Esta separación tiene sentido: las apps de producto se benefician de UI compartida; la infraestructura puede gestionarse cluster-local con Flux.
Otros aspectos a considerar
Algunos detalles operativos que conviene evaluar:
- Performance a escala. ArgoCD a veces sufre con miles de apps en una instancia (mejorando con sharding). Flux escala mejor “horizontalmente” con instancias por cluster.
- Comunidad y Slack. ArgoCD tiene comunidad muy activa; Flux también, distinta cultura.
- Soporte enterprise. Ambos tienen proveedores que ofrecen versiones soportadas (Akuity para ArgoCD; Weaveworks/historial para Flux — Weaveworks cesó actividad pero el proyecto continúa fuertemente sostenido).
- Roadmap futuro. Ambos siguen activos con releases regulares.
Conclusión
Flux y ArgoCD son herramientas excelentes con filosofías distintas. La elección no es “cuál es mejor” sino “cuál encaja mejor con tu equipo y caso”. Para mucha gente, la UI rica de ArgoCD es decisiva; para otros, la integración nativa de Flux con el ecosistema Kubernetes pesa más. Si tu organización ya tiene una en producción y funciona, no migres por moda. Si empiezas, elige la que tu equipo entienda más rápido y avanza.
Síguenos en jacar.es para más sobre GitOps, deployment automation y operación de Kubernetes.
