GitOps no es una herramienta. Es un modelo de operación, y el stack que lo sostiene se arma combinando piezas que hacen cosas distintas. El error habitual es pensar que basta con instalar ArgoCD y ya está, cuando en realidad un flujo GitOps completo necesita un operador que reconcilie, un gestor de paquetes que empaquete y, casi siempre, una capa de infraestructura como código por debajo. Este artículo separa cada herramienta por su función real para que elijas según el problema que tienes delante y no según lo que esté de moda este trimestre.
TL;DR. El stack GitOps se construye por capas, no con una sola herramienta. El operador de reconciliación es la pieza central: ArgoCD si quieres interfaz visual y RBAC granular, Flux si prefieres un enfoque kubernetes-native sin UI. Sobre ese operador se apoyan Helm para empaquetar aplicaciones y Kustomize para personalizar configuraciones por entorno sin duplicar archivos. Por debajo, Terraform provisiona la infraestructura cloud que el clúster necesita, y herramientas como Jenkins X cosen el CI/CD con el flujo declarativo. La elección no es excluyente: en producción casi siempre conviven un operador, un gestor de paquetes y una capa de IaC trabajando juntos.
El stack GitOps se monta por capas, no con una sola herramienta
Antes de comparar nombres conviene entender la estructura. Un flujo GitOps de verdad tiene tres capas que resuelven problemas diferentes y que rara vez se cubren con una única pieza. La primera es el operador de reconciliación, el componente que vive dentro del clúster y se encarga de comparar el estado declarado en Git contra el estado real del entorno para corregir cualquier desviación sin que nadie ejecute comandos a mano sobre producción. La segunda es el empaquetado y la personalización: cómo defines aplicaciones reutilizables y cómo adaptas esa definición a desarrollo, pruebas y producción sin mantener tres copias del mismo manifiesto. La tercera es la infraestructura que está por debajo del clúster, los recursos cloud que alguien tiene que provisionar antes de que GitOps tenga dónde desplegar nada.
Entender ese reparto importa. Helm y Kustomize no compiten con ArgoCD; trabajan dentro de él. Terraform no es GitOps, pero casi todo despliegue GitOps serio se apoya en él para la capa de cloud. Mezclar las capas es justo lo que lleva a stacks frágiles que nadie sabe mantener seis meses después.
Comparativa de herramientas GitOps por función
Esta tabla resume las herramientas que más aparecen en un stack GitOps en producción, qué hace cada una y en qué escenario tiene sentido elegirla. No es una lista de favoritas. Es un mapa de funciones.
| Herramienta | Para qué sirve | Cuándo elegirla |
|---|---|---|
| ArgoCD | Operador de reconciliación que sincroniza lo declarado en Git con un clúster de Kubernetes, con interfaz visual y RBAC granular | Cuando varios equipos tocan los mismos clústeres y necesitas ver el estado de los despliegues y controlar permisos desde una UI |
| Flux | Operador kubernetes-native sin interfaz incluida, configurado por completo con recursos de Kubernetes | Cuando prefieres operar todo desde manifiestos de Kubernetes y no quieres mantener una UI ni un plano de control aparte |
| Helm | Gestor de paquetes que empaqueta aplicaciones de Kubernetes en charts reutilizables con plantillas y versionado | Cuando despliegas aplicaciones con muchas dependencias o instalas software de terceros que ya distribuye su chart oficial |
| Kustomize | Personaliza manifiestos base de Kubernetes por entorno mediante overlays, sin plantillas ni duplicación de archivos | Cuando tienes una base común y solo cambian unos pocos valores entre desarrollo, pruebas y producción |
| Terraform | Infraestructura como código para provisionar recursos cloud de forma declarativa por debajo del clúster | Cuando necesitas crear y versionar la infraestructura base (redes, clústeres, bases de datos) antes de desplegar con GitOps |
| Jenkins X | Plataforma que une CI/CD con el flujo declarativo de GitOps en entornos cloud-native | Cuando quieres conectar la integración continua y el despliegue GitOps en una sola tubería gestionada |
ArgoCD y Flux: cómo decidir el operador de reconciliación
La pieza más importante del stack es el operador, porque es lo que convierte Git en la fuente de verdad que de verdad se aplica sola, y aquí la decisión real se reduce casi siempre a dos opciones maduras. ArgoCD es la más adoptada en Kubernetes y su gran baza es la visibilidad: trae una interfaz web donde ves el estado de cada aplicación, el diff entre lo declarado y lo desplegado, y un control de acceso basado en roles que se vuelve crítico en cuanto más de un equipo comparte clústeres. Flux toma el camino contrario. No incluye interfaz y se configura por completo con recursos de Kubernetes, lo que gusta a los equipos que quieren operar todo desde manifiestos versionados y evitar mantener un plano de control con su propia UI.
No hay un ganador absoluto. ArgoCD encaja mejor cuando hay varios equipos y necesitas gobernanza visible; Flux encaja cuando el equipo es pequeño, kubernetes-native y prefiere mínima superficie operativa. Los dos sincronizan Git con el clúster y los dos se integran con Helm. La pregunta correcta no es cuál es mejor, sino cuánta visibilidad y control de permisos necesita tu organización.
Helm y Kustomize resuelven el empaquetado y la personalización
Ni Helm ni Kustomize son herramientas GitOps en sentido estricto, pero casi ningún stack en producción prescinde de al menos una de las dos porque resuelven un problema que el operador no toca: cómo defines y adaptas lo que se despliega. Helm empaqueta una aplicación entera (sus manifiestos, sus valores, sus dependencias) en un chart reutilizable que puedes versionar e instalar con un comando, y por eso es la vía habitual para desplegar software de terceros que ya publica su propio chart. Kustomize ataca otro ángulo. En lugar de plantillas, parte de un manifiesto base y le aplica overlays que cambian solo lo que difiere entre entornos, de modo que mantienes una sola fuente y no tres copias divergentes de la misma configuración.
Se usan dentro de ArgoCD o Flux, no en su lugar. Un patrón muy común es Helm para empaquetar la aplicación y Kustomize para ajustar valores por entorno, todo orquestado por el operador. Elegir entre plantillas y overlays depende de cuánta lógica de configuración tengas: si es mucha y dinámica, Helm; si son pocos valores que cambian entre entornos, Kustomize.
Terraform y Jenkins X: la infraestructura y el CI/CD alrededor de GitOps
GitOps necesita un sitio donde desplegar, y ese sitio no aparece solo. Terraform es la herramienta de infraestructura como código que provisiona de forma declarativa los recursos cloud (las redes, los clústeres de Kubernetes, las bases de datos gestionadas) que tu flujo GitOps va a usar después, y aunque no es GitOps en sí, encaja en el mismo principio declarativo y versionado, así que conviven con naturalidad: Terraform monta la base, el operador GitOps despliega encima. Jenkins X cubre el otro extremo del flujo. Es una plataforma cloud-native que une la integración y entrega continua con el modelo declarativo de GitOps, de manera que el camino desde un commit de código hasta el despliegue en el clúster queda cosido en una sola tubería gestionada en lugar de quedar repartido entre piezas sueltas que nadie integró del todo.
La idea de fondo se repite. Estas herramientas no sustituyen al operador. Lo rodean. Terraform por debajo, el CI/CD por delante, y el operador GitOps en el centro reconciliando el estado.
El cuello de botella no es la herramienta, es el perfil que la opera
Instalar ArgoCD o configurar Flux es cosa de una tarde para alguien que ya lo ha hecho, pero llevar un stack GitOps completo a producción en una empresa con datos reales, varios equipos compartiendo clústeres y requisitos de auditoría encima es un problema de otra naturaleza que el tooling por sí solo no resuelve. El reto deja de ser técnico y pasa a ser de talento, porque los perfiles senior con experiencia verificada combinando ArgoCD, Flux, Helm, Kustomize y Terraform en entornos serios escasean en el mercado europeo y los procesos de contratación tradicionales se alargan durante meses que el proyecto no tiene.
Shakers funciona como infraestructura de contratación para cubrir ese hueco con talento certificado en skills verificado por proyecto, que entra para diseñar el stack, cubrir un pico de migración o auditar la configuración antes de producción. Si todavía estás antes de elegir el modelo, conviene tener claro qué es GitOps y los beneficios de la metodología GitOps antes de montar el tooling, y si ya vas a escalar a varios equipos, repasa cómo formar un equipo GitOps y CI/CD enterprise. El stack que elijas también marca el perfil que necesitas, una decisión que conecta con la disciplina de platform engineering que suele gobernar estas plataformas.
Preguntas frecuentes sobre herramientas GitOps
- ¿Cuál es la mejor herramienta para empezar con GitOps?
ArgoCD. Su interfaz visual hace que el modelo se entienda rápido y el control de acceso por roles encaja bien cuando hay más de un equipo desde el principio, mientras que Flux es una alternativa muy sólida si el equipo es pequeño y prefiere operar todo desde manifiestos de Kubernetes sin mantener una interfaz aparte.
- ¿ArgoCD o Flux?
Depende de la visibilidad que necesites. ArgoCD aporta interfaz web y RBAC granular, ideal cuando varios equipos comparten clústeres y hace falta gobernanza visible. Flux es kubernetes-native y se configura solo con recursos de Kubernetes, sin UI, lo que reduce la superficie operativa en equipos pequeños. Ambos sincronizan Git con el clúster y ambos se integran con Helm.
- ¿Helm es una herramienta GitOps?
No exactamente. Helm es un gestor de paquetes para Kubernetes que empaqueta aplicaciones en charts reutilizables, y aunque no reconcilia estado por sí solo, se usa dentro de operadores como ArgoCD o Flux para empaquetar lo que esos operadores despliegan.
- ¿Para qué se usa Kustomize en GitOps?
Para personalizar configuraciones de Kubernetes por entorno sin duplicar archivos. Parte de un manifiesto base y aplica overlays que cambian solo los valores que difieren entre desarrollo, pruebas y producción, de modo que mantienes una sola fuente de verdad y se integra de forma directa con ArgoCD y Flux.
- ¿Necesito Terraform si ya uso ArgoCD?
Suelen convivir. Terraform provisiona la infraestructura cloud por debajo (redes, clústeres, bases de datos) y ArgoCD despliega las aplicaciones encima de esa base. No se solapan: uno crea el entorno, el otro reconcilia lo que se ejecuta dentro de él, así que en un stack completo lo normal es usar ambos.
