Argo CD vs Flux CD
Lately, I’ve been seeing more and more debates about two popular GitOps tools: Argo CD and Flux CD.
Actually, I find such debates to be unfounded because I’m deeply convinced that both tools deserve attention and each of them is good for solving its own set of problems.
In my professional activities I use both. I want to share with you my opinion and use cases. I hope this article will help you choose the most suitable tool for your needs.
The topic of Argo CD vs. Flux CD is ubiquitous and generates a huge amount of laughter. For example, at KubeCon, the popularity of these tools is determined by the distribution of cupcakes with their logos. Of course, they were all eaten instantly :)
There are less absurd methods, for example, comparing projects by the number of stars on GitHub:
Overall, it cannot be denied that the Argo CD is two to three times more popular than the Flux CD, but there is an explanation. Flux started earlier and has already conducted a post-mortem, released a second version, which now serves as the main one. Since Flux2 is being developed in a new repository, it had to start accumulating stars from scratch.
Another explanation for such popularity is that Argo CD focuses on the graphical interface, which is a significant factor for beginners when choosing it.
But let’s get a proper understanding.
Meet on clothes
The interface of Argo CD indeed deserves special praise. Just take a look at this cool visualization of resources:
It’s important to note that the Argo CD interface allows not only the deployment of your applications but also, in some form, their management. For example, with Argo CD, you can view pod logs, change manifests, or even execute exec in a container.
And with the latest releases, even add your own custom actions.
On one hand, this goes somewhat against the practices dictated by GitOps, where the Git repository should act as the source of truth. On the other hand the utility and relevance of these features cannot be overlooked. Sometimes they are quite useful and obvious to the end user.
Most people would prefer to have a single interface to monitor the status of deployments, instead of going what seems to be the more correct route, i.e., using a Grafana dashboard to monitor deployment status, receiving alerts in Slack, and reading logs in a logging system.
Nevertheless, I believe that tools should simplify work, not complicate it. Thus, for the typical developer, it would be much more convenient to click buttons and observe the deployment status in the Argo CD interface than in several separate systems, which also need to be configured in a certain way.
Alternatively, Flux CD implements the most standard patterns in Kubernetes. Being implemented as several controllers, it offers convenient CRD resources for configuration.
Using this approach allows Flux CD to be used not only as a GitOps tool but also as a foundation for building other systems. A huge number of third-party solutions are based on Flux CD, including our platform Cozystack, which uses Flux CD as the primary tool for deploying all system components and user applications.
Using Flux CD, you can implement any logic for your user’s interaction with the cluster.
By the way, did you know that the GitOps approach doesn’t limit you to using only Git? Instead, GitOps simply declares the use of the operator pattern and reconciliation method for external sources, and such sources can be not only Git but also an S3 bucket, Helm repository, or really anything.
Barrier to entry
Both tools are very easy to install and offer a quick start. But they do so in different ways. Argo CD provides you with an intuitive graphical interface.
Flux CD offers a simple and intuitive CLI, which automatically sets up tokens in GitHub/GitLab and integrates with your Kubernetes cluster, as well as being able to generate YAML manifests and store them in your repository, thereby teaching you proper organization.
Security
Both tools use different approaches to security organization.
Deployment Model
In Argo CD, you have two stages: first, a configuration plugin is called, which renders the manifests into YAML (for example, using the helm template command), and then the rendered YAML is applied to the cluster (aka kubectl apply).
It’s very convenient that you can describe the configuration in the format you prefer, and at the moment of applying this configuration, see what exactly is being applied to the cluster. Its live and desired state and the diff between them.
However, this approach has downsides because the GitOps Engine, the engine used by Argo CD for applying manifests to the cluster, is not always fully compatible with all Helm hooks, lookups, and so on.
Furthermore, your Helm charts should not have drift, which is when two calls to helm template return slightly different manifests. This is often observed if the Helm chart includes the generation of random passwords or certificates. Otherwise, you'll see constant Our-of-Sync.
Flux CD uses native tools for deploying, so Helm charts installed in this way support all the Helm-functions. But tracking changes is not as simple and will have to be caught during code review.
For example, you won’t always be able to understand what specific state the installation of a particular Helm chart with go-templates will lead to. You’ll have to render them in your head or come up with additional logic for your pipeline.
Access Control
It’s also worth clarifying that for access control, Flux CD reuses the standard RBAC model, which is certainly pleasing.
Argo CD implements its own model, where groups and access rights are set up in a CSV-like format, which is inconvenient to use outside of web interface.
Despite this, with its functionality, Argo CD covers almost all the needs of the average Kubernetes user, that allows you to restrict developers’ access to Kubernetes and rely only on Argo CD primitives to managing access control.
From the Flux CD side, denying direct access to Kubernetes for developers is also often practiced, but in practice, it’s a bit more difficult to apply, given that you need to offer something in return, some other convenient way to view logs and deployment status. After all, the convenience of local development is a very important thing before you can propose this solution to your developers.
In Flux CD, you can also disable deployments using the cluster admin serviceAccount, so it will require the mandatory specification of a service accounts with limited rights for installing releases.
Extensibility
Argo CD is extremely easy to extend! At the cluster level, you can describe additional plugins, which can be launched simply by running a binary with needed arguments or executing an arbitrary shell script. All it needs to do is to take a directory with the project’s source code and to output set of YAML manifests out of it. These YAML manifests will be applied to the cluster.
It’s important to note that Argo CD does not solve the secrets management, instead referring to external solutions. That’s precisely why such configuration plugins are most often used to teach Argo CD to work with secrets in some way. For example, integrating helm secrets to automatically decrypt secrets from your repository.
Flux CD, in turn, is not as easy to extend but it comes with everything needed out of the box. It supports SOPS (for storing secrets in the repository in encrypted form), and offers the ability to apply Kustomize patches with helm releases, which is useful for overriding resulted Helm-chart manifests without modifying the Helm-chart itself.
Writing a separate Flux CD controller is possible, but it requires significant effort because it will be a separate project, not just a simple dirty hack as in Argo CD.
Scalability
Both solutions can be scaled by simple increasing the number of instances. However ArgoCD by default stores all its resources in a single namespace. Flux CD, in turn, can select and operating resources by labels, thus implementing sharding.
It’s worth mentioning the two different paradigms of using these two solutions. Flux CD is typically installed separately in each cluster, acting as a GitOps operator that invariably installs everything in its local cluster. Argo CD more often implies a unified interface for managing multiple clusters.
When you have multiple projects and/or developer teams, it’s better to deploy several independent instances of Argo CD for each of them. There are two reasons: it makes no sense to store two independent projects in single Argo CD, this improves scalability and reduces conflicts related to application naming.
In other words:
- I would deploy one Argo CD per tenant, where each tenant is an independent developer team with their applications, but it can work with multiple clusters, for example, dev/stage/prod, etc.
- I would deploy one Flux CD per cluster because Flux CD works more as Kubernetes extension by introducing primitives for deploying from Git and other sources.
Conclusion
Here we are at the most interesting part, the conclusion. Now, you should make a choice between Argo CD or Flux CD. To do this, I first suggest you ask yourself: what specific problem do you want to solve?
Do you need a tool to simplify cluster administration or to simplify developers’ delivery of their applications?
For example, if you plan to deploy numerous ready-made infrastructure charts through Argo CD, be prepared to fine-tune them manually. This is because not all charts are written with consideration to work with external configuration management systems like Argo CD.
Flux CD uses native Helm for deployment, so all lookups, hooks, and capabilities will work right out of the box. You won’t need to fine-tune the charts — which is why admins primarily love it.
Developers particularly love Argo CD, and moreover, you can revoke their direct Kubernetes access and provide a ready-made interface for managing deployments. There, they can observe the process, view logs, and restart a pod if needed. I assure you, they will be simply delighted!
There are also a few corner cases, for example:
- If you want to deploy a unified, identical set of components across a large number of clusters, then Flux CD might be the better choice. This is due to the paradigm where an independent controller is often used for each Kubernetes cluster.
- If you wish to implement GitOps quickly but your developer team and infrastructure aren’t ready yet. If your developers want to perform operations like restarting individual pods, exec into containers, and have the ability to perform rollbacks without committing to Git — then Argo CD could be a good choice for you.
In any case, nothing prevents you from using both.
