GitOps Comparison: Argo CD vs Flux

GitOps is the practice of using Git as a single source of truth for declaratively specifying the desired state of infrastructure and applications. GitOps provides increased reliability and velocity, reduced downtime, and other advantages such as self-healing. Argo CD and Flux are the most popular options for GitOps continuous deployment.

Argo CD and Flux have been instrumental in the rise of GitOps and are a part of CNCF’s OpenGitOps initiative. In 2022, both tools reached the CNCF graduated status. In this blog, we will explore the difference between these tools and give you pointers on going about choosing between the two. We will also explore the community around these tools, some recent announcements, and their future roadmaps.

Fleet is a relatively new offering from Rancher with capabilities to manage fleets of Kubernetes clusters using GitOps practices. For more tools, check out our popular GitOps Tools article. Find out about the fundamentals of GitOps here.

Argo CD vs Flux

Let’s look at each tool through these specific feature comparisons around these three themes.

1. Ease of setup
2. Ease of maintenance
3. Capability

And we have also put a Pros and Cons table at the very end for quick reference.

If you’d like to skip the installation, click here.

Installation

Argo CD

Argo CD can be set up using both CLI and UI. There is also an Argo CD core installation option that installs only the essential components and skips UI, SSO, etc. We will be using helm charts and argocd CLI to make the installation on a kubernetes cluster. For other installation methods, visit Argo CD docs.

If you prefer to set it up using Argo CD’s UI, follow this tutorial.

Pre-requisites: Helm, Kubectl installed

1. Create a new namespace

   1kubectl create ns argocd
   2
   Copy

   This will create a new namespace, argocd, where Argo CD services and application resources will live. Here you can modify any custom values in values.yaml.

2. Install Argo CD

   Add repository

   1helm repo add argo https://argoproj.github.io/argo-helm
   2
   Copy

   Install chart

   1helm install argocd argo/argo-cd --version 5.21.0 -n argocd
   2
   Copy

   An example of overrides to values.yaml look something like this:

   1    applicationSet:
   2        args:
   3            dryRun: false
   4            metricsAddr: ':8080'
   5            policy: sync
   6            probeBindAddr: ':8081'
   7    configs:
   8        cm:
   9            account.argonaut-admin: 'apiKey, login'
   10            account.argonaut-admin.enabled: true
   11            cluster.inClusterEnabled: true
   12    knownHosts:
   13            data:
   14            ssh_known_hosts: >
   15                bitbucket.org ssh-rsa
   16                AAAAB3NzaC1yc2EAAAABIwAAAQEAubiN81eDcafrgMeLzaFPsw2kNvEcqTKl/VqLat/MaB33pZy0y3rJZtnqwR2qOOvbwKZYKiEO1O6VqNEBxKvJJelCq0dTXWT5pbO2gDXC6h6QDXCaHo6pOHGPUy+YBaGQRGuSusMEASYiWunYN0vCAI8QaXnWMXNMdFP3jHAJH0eDsoiGnLPBlBp4TNm6rYI74nMzgz3B9IikW4WVK+dc8KZJZWYjAuORU3jc1c/NPskD2ASinf8v3xnfXeukU0sJ5N6m5E8VLjObPEO+mN2t/FZTMZLiFqPWc/ALSqnMnnhwrNi2rbfg/rd/IpL8Le3pSBne8+seeFVBoGqzHM9yXw==
   17
   18                github.com ecdsa-sha2-nistp256
   19                AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBEmKSENjQEezOmxkZMy7opKgwFB9nkt5YRrYMjNuG5N87uRgg6CLrbo5wAdT/y6v0mKV0U2w0WZ2YB/++Tpockg=
   20
   21                github.com ssh-ed25519
   22                AAAAC3NzaC1lZDI1NTE5AAAAIOMqqnkVzrm0SdG6UOoqKLsabgH5C9okWi0dh2l9GKJl
   23    knownHostsAnnotations: {}
   24     policy.csv: |
   25        p, role:argonaut-readonly, applications, get, */*, allow
   26        p, role:argonaut-readonly, certificates, get, *, allow
   27        p, role:argonaut-readonly, clusters, get, *, allow
   28        p, role:argonaut-readonly, repositories, get, *, allow
   29        p, role:argonaut-readonly, projects, get, *, allow
   30        p, role:argonaut-readonly, accounts, get, *, allow
   31        p, role:argonaut-readonly, gpgkeys, get, *, allow
   32        p, role:argonaut-readonly, logs, get, */*, allow
   33
   34        p, role:argonaut-admin, applications, create, */*, allow
   35        p, role:argonaut-admin, applications, update, */*, allow
   36        p, role:argonaut-admin, applications, delete, */*, allow
   37        p, role:argonaut-admin, applications, sync, */*, allow
   38        p, role:argonaut-admin, applications, override, */*, allow
   39        p, role:argonaut-admin, applications, action/*, */*, allow
   40        p, role:argonaut-admin, applicationsets, get, */*, allow
   41        p, role:argonaut-admin, applicationsets, create, */*, allow
   42        p, role:argonaut-admin, applicationsets, update, */*, allow
   43        p, role:argonaut-admin, applicationsets, delete, */*, allow
   44        p, role:argonaut-admin, certificates, create, *, allow
   45        p, role:argonaut-admin, certificates, update, *, allow
   46        p, role:argonaut-admin, certificates, delete, *, allow
   47        p, role:argonaut-admin, clusters, create, *, allow
   48        p, role:argonaut-admin, clusters, update, *, allow
   49        p, role:argonaut-admin, clusters, delete, *, allow
   50        p, role:argonaut-admin, repositories, create, *, allow
   51        p, role:argonaut-admin, repositories, update, *, allow
   52        p, role:argonaut-admin, repositories, delete, *, allow
   53        p, role:argonaut-admin, projects, create, *, allow
   54        p, role:argonaut-admin, projects, update, *, allow
   55        p, role:argonaut-admin, projects, delete, *, allow
   56        p, role:argonaut-admin, accounts, update, *, allow
   57        p, role:argonaut-admin, gpgkeys, create, *, allow
   58        p, role:argonaut-admin, gpgkeys, delete, *, allow
   59        p, role:argonaut-admin, exec, create, */*, allow
   60
   61        g, role:argonaut-admin, role:argonaut-readonly
   62        g, argonaut-admin, role:argonaut-admin
   63    controller:
   64        clusterAdminAccess:
   65            enabled: true
   66        containerPort: 8082
   67    dex:
   68        containerPortGrpc: 5557
   69        containerPortHttp: 5556
   70        containerPortMetrics: 5558
   71    global:
   72        additionalLabels:
   73            argonaut.dev/cd-integration-id: acd-akwtupm4z47ag7r8
   74            argonaut.dev/organization-id: ar2nsbcq25kwi63r
   75    redis:
   76        containerPort: 6379
   77    metrics:
   78        containerPort: 9121
   79        containerSecurityContext:
   80            allowPrivilegeEscalation: false
   81            capabilities:
   82                drop:
   83                    - ALL
   84            readOnlyRootFilesystem: true
   85            runAsNonRoot: true
   86            seccompProfile:
   87                type: RuntimeDefault
   88        image:
   89            imagePullPolicy: IfNotPresent
   90            repository: public.ecr.aws/bitnami/redis-exporter
   91            tag: 1.26.0-debian-10-r2
   92        resources: {}
   93    repoServer:
   94        clusterAdminAccess:
   95            enabled: false
   96        containerPort: 8081
   97    server:
   98        clusterAdminAccess:
   99            enabled: true
   100        containerPort: 8080
   101
   102
   Copy

3. Download the latest CLI version or use the following brew install command. Instructions for Windows users can be found here. (Optional - only needed if you’re interacting using CLI)

   1brew install argocd
   2
   Copy

4. You can now access the Argo CD API server using load balancer, Ingress, or port forwarding. Shown below is the port-forwarding method.

   1kubectl port-forward svc/argocd-server -n argocd 8080:443
   2
   Copy

   The API server can then be accessed using https://localhost:8080

5. Login using the Argo CD CLI

   The initial password is stored in the password field. Retrieve it by:

   argocd admin initial-password

   Alternatively, it can also be accessed by accessing the kubernetes secrets”

   1kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath='{.data.password}' | base64 -d
   2
   Copy

   Using the username admin and password from above, log in to Argo CD’s IP or hostname

   argocd login <ARGOCD_SERVER>

   Change the password using the following command:

   argocd account update-password

6. We’ll deploy an app to the same cluster that Argo CD is running in. We’ll deploy using the CLI. To deploy to an external cluster, follow these commands. We’ll use the example repository containing a guestbook application.

   1. We need to set the current namespace to Argo CD by running the following command: kubectl config set-context --current --namespace=argocd
   2. Create the example guestbook application, set the destination, and with the following command:

      1argocd app create guestbook --repo https://github.com/argoproj/argocd-example-apps.git --path guestbook --dest-server https://kubernetes.default.svc --dest-namespace default
      2
      Copy

   Created EKS cluster using Argonaut? Here is how you can access your EKS clusters from CLI.

7. Deploy (Sync) the App

   You will get the following output once the app is created.

   1$ argocd app get guestbook
   2Name:               guestbook
   3Server:             https://kubernetes.default.svc
   4Namespace:          default
   5URL:                https://10.97.164.88/applications/guestbook
   6Repo:               https://github.com/argoproj/argocd-example-apps.git
   7Target:
   8Path:               guestbook
   9Sync Policy:        <none>
   10Sync Status:        OutOfSync from  (1ff8a67)
   11Health Status:      Missing
   12
   13GROUP  KIND        NAMESPACE  NAME          STATUS     HEALTH
   14apps   Deployment  default    guestbook-ui  OutOfSync  Missing
   15       Service     default    guestbook-ui  OutOfSync  Missing
   16
   Copy

   As you can see, the deployment status is OutOfSync since the app is yet to be deployed, and no k8s resources have been created. Run the following command to deploy.

   1argocd app sync guestbook
   2
   Copy

   This command retrieves the manifests from the repository and performs a kubectl apply of the manifests. The guestbook app is now running, and you can now view its resource components, logs, events, and assessed health status.

Flux

The installation in Flux terms is called as Flux Bootstrap. The Flux CLI binaries are available on all major platforms and can be downloaded from here. Below are the basic installation steps.

Requirements: Kubernetes v1.21 or higher

1. Start with: brew install fluxcd/tap/flux

   This installs the Flux CLI on to your system.

2. The flux bootstrap command creates a flux namespace on your Kubernetes cluster and configures it to manage itself from a Git repository. Connecting to other Git repositories like AWS CodeCommit, Azure DevOps, Bitbucket Server, GitHub, or GitLab. requires an Access Token. Find those instructions here. These Flux components are installed to your cluster in this step: helm-controller, kustomize-controller, notification-controller, and source-controller.

3. The bootstrap git command takes an existing Git repository, clones it, and commits the Flux components manifests to the specified branch. Then it configures the target cluster to synchronize with that repository.

   Authenticating with your SSH agent. This command generates an SSH key and will prompt you to add the SSH public key as a deploy key to your repository.

   1flux bootstrap git \
   2  --url=ssh://git@<host>/<org>/<repository> \
   3  --branch=<my-branch> \
   4  --path=clusters/my-cluster
   5
   Copy

4. If your Git server uses a self-signed TLS certificate, you can specify the CA file with --ca-file=<path/to/ca.crt>.

   With --path you can configure the directory, which will be used to reconcile the target cluster. To control multiple clusters from the same Git repository, you have to set a unique path per cluster e.g. clusters/staging and clusters/production:

   1./clusters/
   2├── staging *# <- path=clusters/staging*
   3│   └── flux-system *# <- namespace dir generated by bootstrap*
   4│       ├── gotk-components.yaml
   5│       ├── gotk-sync.yaml
   6│       └── kustomization.yaml
   7└── production *# <- path=clusters/production*
   8    └── flux-system
   9
   Copy

5. After running bootstrap, you can place Kubernetes YAMLs inside a dir under path e.g. clusters/staging/my-app, and Flux will reconcile them on your cluster.

   For examples of how you can structure your Git repository, see:

   • flux2-kustomize-helm-example
   • flux2-multi-tenancy

GitOps

Both tools have been instrumental in the rise of GitOps and can manage both application and infrastructure deployments.

Argo CD is a full-featured product for GitOps, while Flux is a GitOps toolkit. This makes the Argo project more capable and a well-rounded solution as a whole. Argo Project includes Argo CD, Argo Workflows, Argo Events, and Argo Rollouts.

Flux's mature system of integrations and extensions makes it a well-rounded solution. Along with its other benefits, it can be much more than a GitOps toolkit and might be the right solution for your GitOps workflows.

Source Tracking

Source tracking controls how changes are detected in the GitOps resource. Both Argo CD and Flux can be configured to track a branch, a tag pattern, or a fixed commit hash in git.

Application delivery

Argo CD supports both push and pull-based deployments. It supports several different Kubernetes manifest formats — helm charts, jsonnet, YAML, and customized applications.

Ability to add custom resource hooks that can trigger custom scripts or interact with external services at various stages of the Argo CD sync operation. Such as PreSync, Sync, PostSync, or when synchronization fails.

Flux’s pull-based model uses webhook receivers to make it as fast and responsive as push-based pipelines. Flux is designed to work with existing tools in mind. It’s GitOps Toolkit components include specialized tools and Flux Controllers, composable APIs, and reusable Go packages for GitOps under the fluxcd GitHub organisation.

Custom Resource Definitions (CRDs)

Argo CD offers mainly two major CRDs - Application and AppProject.

The Application CRD is a Kubernetes object representing an app instance. It has two parts: source (Git repo, revision, path, env) and destination (cluster or name, not both).

The AppProject CRD is a Kubernetes resource object that defines sourceRepos, destination clusters and namespaces, and roles for entities with access to the project, allowing for the logical grouping of applications.

Flux, on the other hand, offers separate CRDs for each concept like Kustomization (kustomize-controller), HelmRelease, HelmChart (helm-controller), HelmRepository, GitRepository (source-controller), Alert, Event (notification-controller), etc.

Flux’s implementation here offers a way cleaner and more flexible approach. Some differences can be seen in the way they handle secrets and ConfigMaps.

Reconciliation Configurability

Reconciliation or synchronization (sync) is the act of modifying the cluster state to match the description stored in git. Both tools support automatic reconciliation.

Argo CD

Argo CD offers global reconciliation settings that can be modified via a ConfigMap, with a default setting of three minutes. Reconciliation can be disabled globally or per application, but the reconciliation time can only be set globally.

Flux

Flux, built on the GitOps Toolkit, is a reconciliation loop that can be configured at a component level, which allows for staggered reconciliation, e.g: you check a git repository every five minutes and sync every 10 minutes.

Cluster drift reconciliation (self-heal)

Using GitOps and source tracking, the cluster configuration and its resources are automatically matched to the Git source. But what if someone makes a manual edit to a resource? Such as through kubectl. In such cases, cluster drift reconciliation can ensure that the cluster adheres to the declared state (eventually). Both Argo CD and Flux support this feature with caveats.

In Argo CD, it is available as an optional feature, which requires automatic sync to be enabled, and it disables rollbacks.

In Flux, it depends on the GitOps resource kind. For Kustomizations, cluster drift reconciliation is enabled by default. Whereas Flux does not support this feature for Helm releases at all.

Manual Sync

Argo CD - possible by specifying manual syncPolicy: {} on the Application GitOps resource.

Flux - Declaratively set suspend: true

1kubectl annotate --field-manager=flux-client-side-apply --overwrite \
2kustomization/podinfo reconcile.fluxcd.io/requestedAt="$(date +%s)"
3
Copy

Web UI

The Argo Project tools, including Argo CD, come with a web UI for ease of use and provide a visual understanding of the pipelines and workflows. Argo CD’s UI components can be found in this repo and can be extended using javascript extension files.

Flux has an API-led approach that enables multiple GUIs and relies on other open-source projects for its web UI. The two popular ones are Weaveworks GitOps and VS Code GitOps tools.

Garbage collection (Pruning)

The garbage collection is a process by which the Kubernetes objects previously applied on the cluster are missing from the current source revision and automatically removed from the cluster.

Both Argo CD and Flux have similar approaches to garbage collection.

In Argo CD,

Pruning can be set to happen automatically by running the argocd app set <APPNAME> --auto-prune command or by setting the prune option to true in the automated sync policy.

1spec:
2  syncPolicy:
3    automated:
4      prune: true
5
Copy

In Flux,

To enable garbage collection, set spec.prune to true.

To disable the pruning of certain resources, annotate them with:

1kustomize.toolkit.fluxcd.io/prune: disabled
2
Copy

💡 Kustomize is a CLI tool offering template-free, structured customization of declarative configuration targeted to k8s-style objects.

Secret Management

Argo CD allows plenty of flexibility when it comes to secret management. It works well with external secrets operators, sealed secrets, helm secrets, KSOPS, plugins, and more.

For those secret management solutions that use plugins to inject secrets into application manifests, check out these steps to mitigate the security risks of secret-injector plugins.

Flux also has several options for secret management. It has specific guides for sealed secrets, SOPS, secret decryption, and externally mounted CSI drivers.

It also has a list of considerations when it comes to secret management while using Flux.

💡 Want to learn more about these secret management approaches and tools? Check out our Kubernetes secret management blog.

Permissions and Access Control

Organizing your applications based on ownership can help simplify the permission setup. VCS-based permission management can be implemented, e.g. the code owners can be used to control write permissions based on globs within a mono repo. Assigning a different repo for each team can help them achieve greater confidentiality. The GitOps platform can offer additional features for access control.

In Argo CD, the AppProject is used to specify that an application belongs to a  project, which makes use of Argo CD’s own user management and permission system, enabling us to allow/deny

• Access to sources
• Deploying resource kinds
• Access for users
• Deploying to target clusters

Flux doesn’t offer its own user management as Argo CD does. Instead, platform administrators should use Kubernetes RBAC and policy-driven validation to establish security. Flux has a multi-component design and integrates with many other systems. Having different components and CRDs, such as git repositories, charts, notifications, etc, helps separate concerns and thus facilitates the setting up of fine-grained policies. Platform admins can enforce service account impersonation to minimize privileges. (source)

Multi-Cluster Deployment

Both platforms support syncing remote cluster targets.

Argo CD offers a dedicated ApplicationSet resource for templating Applications targeting multiple clusters. With Flux, you can use conventional tooling (such as kustomize overlays) to generate GitOps manifests for the separate targets.

Enterprise options

Both Argo CD and Flux have enterprise version offerings. These are by using tools built on top of the open-source versions. They offer improved support, guaranteed SLAs, provide disaster recovery, and more.

Akuity is an on-prem enterprise-ready solution built by Argo CD’s creators.

Weave GitOps Enterprise is the enterprise solution built on top of Flux and Flagger.

Other solutions like Azure Arc, D2iQ Kommander, and Giant Swarm GitOps are built on top of Flux.

CNCF

Journey of Argo CD

Argo was accepted to CNCF on March 26, 2020.

Argo project graduated from CNCF on December 6, 2022. Argo achieved and maintains an OpenSSF Best Practices Badge and went through a third-party security audit in July 2022.

Over 250 organizations officially use Argo CD, and over 400 use at least one of the 4 Argo projects. There is also the annual ArgoCon event that takes place in collaboration with CNCF.

The recent 2022 Argo Project user survey shows the types of organizations and users using Argo CD and for how long they’ve been using it. It also shows us that Prometheus is the preferred metrics provider, and Istio and NGINX dominate the service mesh.

Top contributions to the project are from companies like Intuit, RedHat Inc., and Akuity, Inc.

If you’re interested in contributing to the Argo project, here’s how.

Journey of Flux

Flux was accepted into CNCF on July 15, 2019, and it joined the CNCF incubator in March 2021.

Flux graduated from CNCF on the 30th of November, 2022. The project also received a Core Infrastructure Initiative Best Practices Badge and went through a third-party security review last year. Flux has seen a 400% increase in growth activity during its incubator phase.

Flux has over 70 organizations that have officially adopted it. Though flux doesn’t have its own event, it will be a part of cdCon 2023.

Flux v1 was archived in November 2022, and Flux v2 CLI is production ready.

Top contributions to the project are from Weaveworks Inc., Cybercom Group AB, and D2iQ Inc.

If you’re interested in contributing to Flux, here’s how.

2023 Roadmaps

Argo CD

New versions of Argo CD are released approximately every 3 months. The upcoming release cadence can be found here. Find the full Argo CD roadmap here. Other minor updates are added more frequently.

Here are a few of the key features that are coming to Argo CD in 2023.

• ApplicationSets in the user interface
• Config Management Plugins parameters in UI
• Merge Argo CD Image Updater into Argo CD
• Allow specifying parent/child relationship in configs
• Support for secrets in application parameters

Flux

New flux version releases happen every 2 weeks or so. These include version changes for the individual controllers, API version upgrades, etc. Flux’s roadmap for 2023 can be found here. The roadmap is broken down into milestones.

Here are some key updates coming this year:

• Adopt Kubernetes serverside apply (Flux GitOps GA)
• Alert and providers API to GA (Flux notifications GA)
• Flux Helm APIs and the Flux Helm functionalities GA
• Image policies and image update automation to GA
• S3 compatible APIs and OCI artifacts to GA

Pros and Cons

Argo CD

Flux

Conclusion

Argo and Flux are both established and well-tested technologies that are able to bring together and further extend the concept of GitOps within the broader Kubernetes framework. With two reliable projects available, teams have the opportunity to select the most suitable GitOps platform for their specific needs or even combine the two to create a unique and advantageous solution. This gives developers greater freedom to create and manage their own systems, taking advantage of the power and flexibility of both Argo and Flux.

In our next article in the GitOps series, we will discuss how Argonaut builds on top of the Argo Project - with additional capabilities and automation for your cloud deployments.