Descubre por qué conviene evitar Flux para GitOps basado en pull. Una mejor alternativa es GitOps basado en push con un pipeline CICD, pero la mejor es ArgoCD.
ArgoCD es una mejor opción para GitOps basado en pull
Quienes se meten de lleno con Kubernetes terminan descubriendo el valor de GitOps. Y entonces aparece la pregunta sobre las mejores prácticas. ¿Vamos con ArgoCD o con FluxCD v2? ¿Existen otras opciones? Si estas preguntas te suenan, llegaste al lugar indicado.
En este artículo te explico por qué conviene evitar Flux y por qué ArgoCD es la mejor opción si quieres hacer GitOps basado en pull. Otra alternativa que vale la pena considerar es GitOps basado en push con un pipeline CICD.
¿Qué buscábamos lograr con GitOps?
Para empezar, es una buena solución a un problema que trajo una solución anterior: Infrastructure as Code (IaC) te ayuda a conseguir despliegues reproducibles, y una fuente única de verdad permite que los equipos grandes se mantengan sincronizados, con mínima sobrecarga de comunicación. El problema es que estos beneficios de IaC dependen de que el estado real de tu infraestructura coincida con el estado deseado definido en Git. GitOps resuelve ese nuevo problema del config drift, donde la realidad tiene que mantenerse sincronizada con git.
Usar GitOps para resolver el config drift también facilita aplicar el principio de mínimo privilegio y simplifica el control de acceso basado en roles (RBAC). Te puedes ahorrar el dar acceso de solo lectura a kubectl y, en su lugar, dar acceso de solo lectura al repositorio de git. El acceso directo a kubectl se reduce al mínimo y, en su lugar, se aplica RBAC a las cuentas de servicio de GitOps y a los repositorios de git.
GitOps también hereda los controles de seguridad propios de git. Exigir merges revisados por pares se traduce en exigir despliegues revisados por pares. El historial de Git se convierte en un registro de auditoría: quién cambió qué, cuándo ocurrió el cambio y quién lo aprobó.
Por qué prefiero ArgoCD sobre FluxCD para GitOps basado en pull
La respuesta corta: ArgoCD es un producto mucho más maduro y ofrece una experiencia de usuario muy superior a la de Flux v2.
Primero, si haces push de una configuración mala con Argo, inicias sesión por SSO en una GUI, recibes feedback visual de que existe un error y dónde encontrarlo, y además obtienes un mensaje de error útil. Con Flux, en cambio, es difícil incluso darse cuenta de que existe un error. Para que aparezca el mensaje, tienes que ejecutar el comando correcto contra el objeto correcto en el namespace correcto usando la herramienta CLI correcta. Algunos errores aparecen con kubectl, otros con fluxctl.
Segundo, solo ArgoCD permite hacer GitOps basado en pull de verdad y obtener los beneficios mencionados arriba. Con Argo puedes resolver problemas sin acceso a kubectl. Haces push de un cambio a git, Argo reconcilia de forma infinita un cluster en vivo a partir de git y te da feedback en la GUI.
Con Flux no puedes resolver problemas sin acceso a kubectl. Supongamos que invertiste el tiempo necesario para armar pipelines de logging impecables con alertas que expongan los errores. Flux no usa un loop de reconciliación infinita estilo KISS como Argo. Usa un loop de reconciliación frágil basado en eventos que se traba con frecuencia en un mal estado (más común con helm).
En un trabajo anterior, capacité a cientos de personas en cómo hacer GitOps con Flux. Durante esas capacitaciones, Flux se quedaba "trabado" en al menos 5 de cada 20 asistentes. La reconciliación se detiene hasta que se arregla el estado confuso. Los cambios en el repositorio de git se ignoran temporalmente, así que se requiere intervención manual.
La única forma de arreglarlo es con varios comandos de fluxctl. Además, fluxctl depende de kubectl y, como hay que corregir estado, el acceso de solo lectura no alcanza. Un ejemplo común son los errores "install retries exhausted". Si ya arreglaste el problema en git, mala suerte: Flux se rindió después de quedar "agotado." Hacen falta varios comandos de fluxctl para forzar un redeploy. Puedes actualizar la configuración por defecto a retries = -1 (infinito), pero eso no soluciona el problema, solo hace que se trabe con menos frecuencia. Flux intenta ejecutar la lógica de despliegue solo cuando detecta cambios. Hay casos límite en los que no logra reconciliar porque no detectó un cambio relacionado con helm.
¿Hay casos límite en los que Flux es mejor que Argo?
ArgoCD evita a propósito algunas funcionalidades avanzadas de helm que se usan poco. En su lugar, se enfoca en una estabilidad a toda prueba para los casos de uso más comunes. Si estás usando un helm chart muy avanzado que hace cosas como helm hooks, puede que ArgoCD no lo soporte. Flux tiene mejor soporte para la funcionalidad de helm.
¿Qué otras opciones existen?
He visto con frecuencia el siguiente patrón en equipos que están decidiendo cómo implementar GitOps:
ArgoCD vs FluxCD vs una sobrerrepresentación de otras herramientas que siguieron el patrón operator. Sospecho que esas herramientas son las que aparecen en los buscadores cuando uno busca "GitOps."
Una alternativa que tal vez pases por alto es apuntar un pipeline CICD genérico a la lógica de IaC y scripting guardada en un repositorio de git. A este enfoque le llamo GitOps basado en push. Me gusta porque permite mezclar fácilmente lógica de despliegue imperativa y declarativa, lo cual es ideal para lidiar con problemas como actualizaciones que implican breaking changes. Esos casos son difíciles de resolver con una solución de GitOps puramente declarativa basada en pull.
Para cerrar
Quienes adoptan GitOps por primera vez deberían tachar a Flux de su lista de opciones. ArgoCD o un pipeline CICD son alternativas mucho mejores a la hora de implementar GitOps.