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.
- Ease of setup
- Ease of maintenance
- 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
Create a new namespace
1kubectl create ns argocd 2
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.Install Argo CD
Add repository
1helm repo add argo https://argoproj.github.io/argo-helm 2
Install chart
1helm install argocd argo/argo-cd --version 5.21.0 -n argocd 2
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
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
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
The API server can then be accessed using https://localhost:8080
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
Using the username
admin
and password from above, log in to Argo CD’s IP or hostnameargocd login <ARGOCD_SERVER>
Change the password using the following command:
argocd account update-password
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.
- We need to set the current namespace to Argo CD by running the following command:
kubectl config set-context --current --namespace=argocd
- 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
Created EKS cluster using Argonaut? Here is how you can access your EKS clusters from CLI.
- We need to set the current namespace to Argo CD by running the following command:
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
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
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
Start with:
brew install fluxcd/tap/flux
This installs the Flux CLI on to your system.
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
, andsource-controller
.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
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
andclusters/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
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:
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
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
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
💡 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
Pros | Cons |
---|---|
True pull-based GitOps solution | Takes time to set up and get used to |
Additional permission and user management features | Limited to one UI |
Supports Kustomize and Helm | |
Self-healing ability | |
Supportive and active community | |
App of apps, multiple clusters deploys | |
More mature product with better errors messages | |
Can work without kubectl access |
Flux
Pros | Cons |
---|---|
GitOps toolkit provides flexibility | Designed to support only one repository |
Supports Kustomize and Helm | Lack of self-healing for Helm |
API-led approach enables multiple UIs | Needs kubectl access to resolve issues |
Supportive and active community | Harder for first-time users |
Built with security in mind | |
Better support for advanced Helm functionality |
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.