Ecco perché conviene evitare Flux per il GitOps pull-based. Un'alternativa è il GitOps push-based con pipeline CICD, ma la scelta migliore resta ArgoCD.
ArgoCD è la scelta migliore per il GitOps pull-based
Chi lavora con Kubernetes prima o poi scopre il valore del GitOps. A quel punto si pone la domanda sulla best practice da adottare: meglio ArgoCD o FluxCD v2? Esistono altre opzioni? Se queste domande Le suonano familiari, è nel posto giusto.
In questo articolo spiegherò perché Flux andrebbe evitato e perché ArgoCD è la scelta migliore per chi vuole adottare il GitOps pull-based. Un'altra opzione da valutare è il GitOps push-based realizzato tramite una pipeline CICD.
Cosa ci aspettavamo dal GitOps?
Anzitutto, è una buona soluzione a un problema introdotto da una soluzione precedente: l'Infrastructure as Code (IaC) aiuta a ottenere deployment riproducibili e una source of truth garantisce che i team più ampi restino allineati con un overhead di comunicazione minimo. Purtroppo, questi vantaggi dell'IaC dipendono dal fatto che lo stato reale dell'infrastruttura coincida con lo stato desiderato definito in Git. Il GitOps risolve proprio questo nuovo problema del config drift, ovvero la necessità di mantenere la realtà sincronizzata con git.
Adottare il GitOps per risolvere il config drift rende anche più semplice applicare il principio del minimo privilegio e snellire il role-based access control (RBAC). Si può evitare di concedere alle persone l'accesso kubectl in sola lettura, optando invece per l'accesso in sola lettura ai repository git. L'accesso diretto a kubectl può essere ridotto al minimo, applicando l'RBAC ai service account GitOps e ai repository git.
Il GitOps eredita inoltre i controlli di sicurezza già integrati in git. Richiedere merge revisionati dai colleghi equivale a richiedere deployment revisionati dai colleghi. La cronologia git diventa così un audit trail di chi ha modificato cosa, quando è avvenuta la modifica e chi l'ha approvata.
Perché preferisco ArgoCD a FluxCD per il GitOps pull-based
In breve: ArgoCD è un prodotto molto più maturo, con un'esperienza utente nettamente superiore rispetto a Flux v2.
In primo luogo, se con Argo si pubblica una configurazione errata, basta accedere via SSO a una GUI per ricevere un feedback visivo sull'errore e sulla sua posizione, oltre a un messaggio di errore davvero utile. Con Flux, invece, è difficile persino accorgersi che esiste un errore. Per far comparire il messaggio bisogna eseguire il comando giusto sull'oggetto giusto nel namespace giusto, usando il CLI giusto. Alcuni errori si vedono con kubectl, altri con fluxctl.
In secondo luogo, solo ArgoCD offre un vero GitOps pull-based capace di garantire i vantaggi elencati sopra. Con Argo si risolvono i problemi senza accesso a kubectl: si pubblica una modifica su git, Argo riconcilia all'infinito il cluster live sulla base di git e restituisce feedback nella GUI.
Con Flux, invece, non è possibile risolvere i problemi senza accesso a kubectl. Mettiamo che abbia dedicato tutto il tempo necessario a creare pipeline di logging perfette con alert per far emergere gli errori. Flux non usa un loop di riconciliazione infinito in stile KISS come Argo, bensì un fragile loop basato su eventi che si blocca spesso in uno stato incoerente (problema più frequente con helm).
In un lavoro precedente ho formato centinaia di persone sull'uso di Flux per il GitOps. Durante quelle sessioni, Flux si bloccava per almeno 5 partecipanti su 20. La riconciliazione si ferma finché lo stato confuso non viene risolto: le modifiche al repository git vengono temporaneamente ignorate ed è necessario un intervento manuale.
L'unico modo per uscirne è ricorrere a vari comandi fluxctl. In più, fluxctl dipende da kubectl e, dovendo correggere lo stato, l'accesso in sola lettura non basta. Un caso tipico sono gli errori "install retries exhausted". Anche se nel frattempo ha già corretto il problema in git, poco importa: Flux ha alzato bandiera bianca dopo essersi "esaurito". Per forzare un nuovo deploy servono diversi comandi fluxctl. Si può modificare la configurazione predefinita impostando retries = -1 (infinito), ma questo non risolve il problema: lo rende solo meno frequente. Flux tenta di eseguire la logica di deployment solo quando rileva modifiche. Esistono casi limite in cui non riesce a riconciliare perché non ha rilevato un cambiamento legato a helm.
Esistono casi in cui Flux è migliore di Argo?
ArgoCD evita di proposito alcune funzionalità avanzate di helm usate raramente, puntando invece su una stabilità a tutta prova nei casi d'uso più comuni. Se sta usando un helm chart molto avanzato che ricorre, ad esempio, agli helm hooks, ArgoCD potrebbe non supportarlo. Flux, su questo fronte, offre un supporto migliore alle funzionalità di helm.
Quali altre opzioni esistono?
Ho visto spesso ripetersi lo stesso schema nei team che devono decidere come implementare il GitOps:
ArgoCD vs FluxCD vs una sovrarappresentazione di altri strumenti basati sull'operator pattern. Sospetto che siano proprio gli strumenti che compaiono nei motori di ricerca alla voce "GitOps".
Un'alternativa che spesso sfugge è puntare una generica pipeline CICD verso codice IaC e logica di scripting conservati in un repository git. Io chiamo questo approccio GitOps push-based. Lo apprezzo perché permette di combinare con facilità logica di deployment imperativa e dichiarativa, soluzione ottima per gestire situazioni come gli aggiornamenti che introducono breaking change: casi difficili da risolvere con una soluzione GitOps puramente dichiarativa e pull-based.
In sintesi
Chi si avvicina al GitOps per la prima volta dovrebbe escludere Flux dalle opzioni da considerare. ArgoCD o una pipeline CICD sono soluzioni decisamente migliori per implementare il GitOps.