GitOps on Kubernetes: Deciding Between Argo CD and Flux
If you’ve heard of GitOps and its benefits, you may have come across two open source projects in the Cloud Native Computing Foundation: Argo CD and Flux. Members of these projects are involved in the CNCF’s OpenGitOps initiative, and both are incubating projects. With GitOps, you increase reliability and velocity, lower downtime, and can enjoy other benefits such as automatic self-healing.
When building out a Kubernetes cluster, the actual process of building the code is just as important as the firewalls, load balancers and provisioning systems at the front. There are many ways to build out application continuous integration/continuous delivery (CI/CD) pipelines in Kubernetes, but in this article we are going to focus specifically on two options for continuous deployment: Flux and Argo CD.
Below are the results of exploring the differences between these two projects. Both have their uses, and both are quite well maintained and have active communities.
Current Landscape
| Flux | Argo CD | |
| CNCF Status: | Incubating | Incubating |
| Public references: | 30 | 176 |
| Contributing companies: | 14 on average | 90 on average |
| Notes: |
|
|
Similarities
Part of the challenge most people face when researching these two tools is that most find that there’s a lot of similarities. So this section will summarize how the two are similar and will link to relevant documentation.
Secrets Management
GitOps’ practice of storing the source of truth in git has had some contention with respect to storing Kubernetes secrets. This has to do with the fact that secrets often contain sensitive information like passwords or tokens, and these secrets are only encoded.
Both Flux and Argo CD have mechanisms in place to handle the encrypting of secrets.
Webhook Receivers
Webhooks can be used to help with immediate reconciliation with traditional, event-driven workflows. This doesn’t take the place of the reconciliation loop, but rather acts as an “on-demand” reconciliation if you don’t want to wait after making a commit to a repo.
This is another area where Flux and Argo CD have similar approaches.
Alerting and Notifications
Alerting is an important part of the CI/CD workflow. These notifications send information when resource statuses change, as new app versions are deployed and when health checks pass or fail. Users tend to use these status updates on reporting channels such as Slack or embedded in git commit status checks.
Flux provides a mechanism for alerting and outgoing notifications, and Argo CD uses Argo CD Notifications via its plugin mechanism.
Image Updates Automation
Image updating is the process of notifying the GitOps controller that a new image has been created and pushed into a repository. This helps in expediting the process of rolling out new versions of applications.
Flux has this concept with something called Image Update Automation, and Argo CD has the Argo CD Image Updater.
Differences
There are so many similarities between the two tools that most users want to get down to the differentiating factors. This section will focus on the differences and will go a little deeper than the previous section.
Installation/Bootstrapping
Both Flux and Argo need to be installed on the cluster you want to manage. Once installed, they need to be configured to read YAML files from a git repository. This initial configuration step, where you install and configure together, is called “bootstrapping.” This is where the differences start to become noticeable.
Flux
The Flux installation/bootstrapping mechanism can be done together, and it is the recommended way to get started. During bootstrapping, Flux creates a repository on GitHub or GitLab (a generic “git” mode can also be used), then creates all the manifests for installation and connection to the repo in that same git repo.
The Flux installer will then “hand-off” the responsibility of managing/syncing the cluster to the flux system that is installed on the cluster, pointing to the repo that was just created.
Argo CD
Argo CD has no native mechanism for bootstrapping and is not opinionated about how it’s configured. The install is just that: the install of the Argo CD components via YAML manifests. It leaves the rest of the configuration up to the end-user.
Reconciliation Configurability
Reconciliation is at the heart of GitOps. Based on the idea of a closed control loop in control theory, GitOps controllers continuously check and correct any drift in the system. Both projects offer a way to configure the way reconciliation works, but differ in some key areas.
Flux
Flux is built on the GitOps Toolkit, which has different components. The Flux reconciliation loop can be configured at each component. For example, you can have your git repository checked every five minutes, but then do the sync every 10 minutes. This gives you the ability to stagger how the reconciliation happens.
Argo CD
Argo CD reconciliation is a global setting. This is one setting that can be modified via the Argo CD ConfigMap. By default, this is set to three minutes and can be changed by the end-user. Although you have a choice of disabling reconciliation globally or per application, you can only set the reconciliation time globally. This means you cannot set the reconciliation time differently for each application.
Application Delivery
Both tools support raw Kubernetes manifests (YAML), Kustomize and Helm. However, this is another area where there are big differences in the way each of the tools approaches how to apply YAML manifests or deploy a Helm chart.
Flux
Flux uses Kustomize heavily. Its Kustomize Controller renders and applies all the manifests that Flux syncs from the source repository, even when using raw Kubernetes YAML. Flux will create a kustomization.yaml file on the fly if Kustomize wasn’t detected. You can use DependsOn to create dependencies between Kustomizations.
Flux also has native support for Helm. Its Helm Controller manages all the Helm charts you want to deploy onto the cluster. Flux uses the native Helm golang library to deploy a Helm release onto the cluster. You also get the advantage of Helm’s chart hooks for ordering. If you are using a hub/spoke model (more on multicluster later), you can also see Helm charts installed on other clusters. Similar to the Kustomize controller, you can use DependsOn to create dependencies.
Argo CD
Argo CD also supports Kustomize and raw Kubernetes YAML. It can, however, apply raw YAML files directly, without using Kustomize. This can have side effects of Argo CD applications not syncing right away as resources need to be reapplied in a retry, or use ordering built into Argo CD.
Argo CD does the equivalent of kubectl apply -f or a kubectl apply -k if Kustomize is detected. This is by design, as the Argo CD creators wanted to emulate the kubectl client as closely as possible. You also have more control over ordering of individual resources (i.e. specific YAML file) with syncwaves and phases. This allows you to apply each YAML manifest one at a time.
Argo CD also has support for Helm, but approaches it in a different way. Argo CD does not use the Helm golang library directly but instead uses Helm to render the template files and pipes them directly to kubectl. Helm chart hooks are converted into Argo CD syncwaves/hooks (more on this next) where it can. This has the side effect of users not being able to use the Helm command-line interface (CLI) against the cluster because Helm install wasn’t called in the first place (i.e. helm ls will return empty).
Web UI
A web user interface doesn’t change the functionality of either tool, but it’s worth noticing the differences. Both tools have a feature-rich CLI that doesn’t impede on functionality.
Flux
Flux, by itself, does not have a web UI. There is an experimental UI started about a year ago, but nothing official. There are open source platforms like Weave GitOps Core that are based on Flux that have a UI.
Argo CD
Argo CD has a rich UI and was built with the UI in mind, so it’s been there from the beginning. It also integrates with Argo CD’s access control policies (more on that next) and has the ability to show a “read-only” dashboard.
RBAC
With role-based access control, each tool not only takes a different technical approach, but also a different philosophical approach. This is another area where both Flux and Argo CD differ significantly.
Flux
Flux relies strictly on the RBAC capabilities of Kubernetes; it does not manage its own users, permissions, identity, authentication or authorization. There are no “Flux users” or “Flux admins.” Flux’s permissions are limited by the role bound to the service account it runs as. This is by design to conform to Kubernetes practices of least privilege for the service account.
Argo CD
Argo CD has an access control list-based RBAC, independent of Kubernetes. Argo CD also has a separate group/user mechanism, which is also independent of Kubernetes. Normally, a user sets up Argo CD’s ServiceAccount with full admin, and manages users using Argo CD’s user/group mechanism. Or a user can use a combination of the two to get the desired outcome.
The RBAC/access system on Argo CD is very granular. Although it can be complex to set up, it is very flexible. The Argo CD authentication mechanism can be integrated with any provider that supports OpenID Connect (OIDC) or brokers it using Dex.
Multicluster
Multicluster management is a challenge. Good news: Both tools can help with multicluster management and deployment of workloads to different clusters you may have. Both tools have similar models, but different implementations. Both tools cannot install clusters and rely on other tools for this, such as CAPI, Crossplane or Open Cluster Management.
Flux
Flux has the concept of connecting to the remote clusters via Kustomization’s (and HelmRelease’s) KubeConfig setting. A centralized “management cluster” is possible, where one Flux instance manages workloads on many clusters. Multicluster is achieved through design and process, via a reference architecture. Without having the concept of clusters built into Flux directly, Flux can work through a common interface to manage clusters.
Argo CD
Argo CD can be configured in a “pull” (instance of Argo CD on each cluster) or “push” (one Argo CD instance connecting to many clusters). Argo CD has a native concept of clusters. A user can install a central “hub” Argo CD instance and connect many clusters to it, without having to install Argo CD in every cluster.
Conclusion
This is only the beginning! The GitOps Working Group is the governing body of OpenGitOps, a CNCF sandbox project that sets vendor-neutral open source standards, best practices, and community-focused education to help organizations adopt a structured, standardized approach to implementing GitOps. From this set of standards, both Argo CD and Flux projects have stemmed to deliver a choice in tools to GitOps practitioners.
For a comprehensive look into each tool, including best practices, reference architectures and white papers, visit the OpenGitOps blog and review documentation at GitHub. The GitOps Working Groups is working on a more in-depth comparison based on this article that can be viewed via this PR.
We invite anyone who is interested in being part of the process to go to https://opengitops.dev/ or https://github.com/gitops-working-group/ or find us on the CNCF Slack account in the #opengitops and #wg-gitops channels.