Yesterday Weaveworks announced that they’re joining forces with ArgoCD – my favorite GitOps tool for Kubernetes. I think it’s a good time to compare what ArgoCD and Flux have in common and what are their differences.
Repositories
The basic features are the same – both tools allows us to connect Git repository and sync its contents with Kubernetes cluster in a declarative way. But here’s the first difference – Flux allows to connect only one repository per instance of Flux operator, ArgoCD can connect multiple git repositories to one cluster. This is useful if you have multiple teams that provide manifests for Kubernetes or if you decide to keep application manifests along with the application code.
Clusters
The second difference is the scope the tools work within – Flux works only inside the cluster like typical Kubernetes Operator so it can effectively manage only one cluster. On the other hand ArgoCD is much more powerful – one instance of ArgoCD can manage multiple clusters, so you can create a nice, centralized tool to manage all your clusters from one place, which is very handy.
GUI
ArgoCD comes with a very nice GUI that simplifies monitoring the state of you applications. The GUI also visualizes all relations between the objects in the app manifests, like that:
The graph not only shows the relationships, but also state of the synchronization as well as health of the components (certs, deployments, ingresses, etc).
Flux doesn’t provide any GUI, however it integrates with Weaveworks SaaS services (paid).
Enterprise readiness
ArgoCD is also more ready for enterprise usage – it features SSO as well as builtin support for role-based access control. Flux – as it’s just a controller – is limited to the Kubernetes RBAC for the service account the controller is associated.
Manifest generation
Both tools provide some ways to enable manifest generation, however ArgoCD has builtin support for more tools, including kustomize, helm and ksonnet. Using both tools we can also plug our own tools.
Updating container images
However, even the free version of Flux has one feature that ArgoCD misses – Flux can update your container images automatically – of course we can discuss if that behavior is desired in GitOps approach, but from practical point of view it can be useful to update revision versions of less critical containers. In ArgoCD in order to update container image version you have to commit the change to Git repo.
Summary
I chose ArgoCD a couple of months ago for my personal projects, and recently I’ve started deploying it to customers’ infrastructures and it works pretty well, greatly reducing complexity of Kubernetes management. It offers much more features, it’s easier to use, is more elastic as it supports wider range of scenarios.
On the other hand it’s hard not to notice the knowledge and experience that guys at Weaveworks have – I’m very glad that they’re joining forces and I’m quite sure that the final product will change the GitOps landscape :)
Dmitry Jun 03 , 2020 at 11:29 /
Thanks for a nice overview!
I’d like also to mention werf — another CLI tool. It uses Git as the single source of truth and implements a bit different view on GitOps. Shortly, it covers not only Kubernetes deployments (based on your configurations kept in Git) but also building and pushing images of your app — of course, making the whole process repeatable and deterministic. So it’s like GitOps but considering the bigger picture of CI/CD pipeline. If it sounds interesting, give it a try! :-)
Juan Ignacio Borda Aug 19 , 2021 at 02:06 /
This post deserves an update cause many of the features have changed mostly in fluxcd
Usando o Argo CD para implementar a abordagem GitOps nos clusters Kubernetes – Aécio Pires Sep 05 , 2021 at 01:43 /
[…] https://luktom.net/en/e1683-argocd-vs-flux […]