Choosing the Right GitOps Tool: ArgoCD vs. FluxCD

Introduction

Kubernetes adoption is on the rise, which has proportionately increased the adoption of tools that perform deployments specifically into Kubernetes. But Kubernetes deployments are challenging if one relies on traditional deployment practices. It is complex and time-consuming, especially for large and complex applications. To simplify deployment into Kubernetes, developers prefer to use GitOps, a pull-based deployment mechanism. GitOps is made possible with tools like Argo CD and Flux CD, which can automate the deployment process into Kubernetes.

We will understand the difference and similarities between Argo CD and Flux CD on the concepts below:

• Installation
• Interface
• Application Deployment
• Deployment strategies
• Feedback notification
• Security
• Multi Tenancy

What is Flux CD

Flux CD is an open-source Continuous Delivery(CD) tool for automated Git-based Kubernetes deployments. It uses a declarative approach to manage Kubernetes deployments using Git repositories to store application configurations. It syncs the Kubernetes clusters with the Git configuration repository.

Flux CD also provides several other features, such as the ability to perform automated rollbacks and to integrate with Helm and Kustomize to provide a more flexible deployment process. It also allows users to perform deployment strategies like Canary and Blue-Green deployments.

Flux Architecture and Components

Flux comprises a set of Kubernetes controllers. Kubernetes controllers handle the lifecycle of objects in Kubernetes. Infrastructure and workload dependency is inbuilt, which lets you sequence your prerequisites before an application is deployed. For example, a database must be up and running before the application gets deployed to ensure the application works fine.

Source controllers

Source controllers monitor a version-controlled repository like GitHub for detecting changes in the application’s source code and configuration. On detecting changes source controller initiates a deployment process to update the application's deployment manifests and apply the changes to the Kubernetes cluster. It can also trigger automated tests and perform security scans based on validation to ensure consistency and reliability.

Kustomize controller

The Kustomize controller manages the deployment of Kubernetes resources using Kustomize. The Kustomize controller in Flux CD monitors the source repository for change and automatically applies the appropriate updates and code upgrades to the base manifests to get the desired configuration.

Helm Controller

In Flux CD, the Helm controller is a component that manages the deployment of Kubernetes resources using Helm, a package manager for Kubernetes. The Helm controller in Flux CD monitors a Helm chart repository for changes, detects changes, and automatically deploys the updated chart to the Kubernetes cluster. It can also roll back deployment to a previous version in case of errors or issues.

Notification Controller

In Flux CD, the Notification controller is a component that sends notifications based on events that occur within the Flux CD system. The Notification controller can send messages to various channels, such as Slack, email, or other messaging platforms, to inform team members about application deployment status changes.

Image reflector controller

In Flux CD, the Image Reflector controller is a component that automatically updates the Kubernetes manifests with the latest available container image from a registry. The Image Reflector controller monitors the specified container image registry for new photos and updates the Kubernetes manifests with the latest image tag.

Image automation controller

The Image Automation controller monitors a container image repository for new versions of images and automatically triggers the update of the application deployment manifests with the new image tag.

How Flux CD Works

As Flux also works on the concept of GitOps, it can automatically deploy the changes in the application found in the Git Repository to the respective Kubernetes clusters ensuring up-to-date applications.

• Developers and DevOps must update Kubernetes manifests and push them to the source Git Repository.
• The current configuration of the pod is stored in the memory cache is frequently synced with the repository using a Kubernetes operator for changes. The Flux container compares that with the pod's existing configuration in cached memory.
• Any mismatch detected will trigger a set of kubectl apply/delete commands to bring the cluster to the latest configuration.
• The latest configuration gets stored as cache data, which is continuously tracked for changes.

What is Argo CD

ArgoCD is a Continuous Deployment(CD) tool that has gained popularity in DevOps for performing application delivery onto Kubernetes. Similar to FluxCD, ArgoCD is a tool that used the GitOps principles. It will sync with the Git repository and ensure that the state of Kubernetes cluster objects and the state manifest will match at all times. ArgoCD is widely adopted in the Kubernetes space as it helps developers manage infrastructure and applications lifecycle in one single platform.

Read here to Understand the architecture and components of Argo CD

Comparison of Flux CD with Argo CD

Both Argo CD and Flux CD are powerful tools for managing Kubernetes deployments. You might be wondering which tool is best for you. Both tools have some key differences between each other. Let us analyze some key differences and similarities between Argo CD and Flux CD:

Installation

ArgoCD and FluxCD are both installed inside your Kubernetes cluster and they monitor and ensure that the state of the cluster and Git repository are synced. Let's take a look at how the two tools different in installation.

Argo CD Installation

Installation of Argo CD is relatively straightforward and all you need to a terminal with kubectl. Installation ArgoCD involves running two commands. Let's get a understanding for the whole installation process.

The standard installation steps for ArgoCD are as follows:

1. Creation of a namespace Argocd and applying the latest ArgoCD release manifest using kubectl. At this point, ArgoCD is installed in the cluster.
2. For a hardened CLI user, you can skip installing the UI and can make Argo CD work with just the essential components.
3. As an external IP is not configured on the Argo CD API, the user has to configure one to access it from the outside.
4. Setting up Ingress is necessary to perform advanced touring and rollback strategies.
5. Argo CD wasn't designed to be run in an air-gapped environment, but there are ways to perform air-gapped installations. For installing Argo CD in an air gapped environment, you will have to use HELM charts.

Flux CD Installation

The Flux CD installation involves downloading and installing the FluxCD CLI utility, and bootstrapping the Kubernetes cluster. While bootstrapping the cluster, you need to provide a Git User along with an API token.

Let's take a look at the installation process for FluxCD

1. Download and install the FluxCD CLI utility
2. Generate a API Token for your Git account. It is recommended to export the values for your API Token, Git username and Git Repository as Environment variables so it is easy to reuse these values.
3. Using the flux bootstrap command, a user can install Flux on a Kubernetes cluster and configure it to manage itself from a Git repository. Flux will create a new directly in the Git repository called as flux-system which will is used to store the Flux configurations.
4. For Air-Gapped installation of FluxCD without access to the internet, the FluxCD binaries and the container images need to be downloaded from a system with internet access. Unlike ArgoCD, Flux can run in an offline environment off the shelf.

Manual Cluster Sync

Both ArgoCD and FluxCD automatically sync the state of the Kubernetes cluster, with the state of the manifests in the Source repositories. However, they also have a option to stop the auto-sync, trigger a manual sync as required. Both ArgoCD and FluxCD have a slightly different way for handling manual syncs.

ArgoCD

With ArgoCD, the manual sync can be defined by setting the syncPolicy: {} on the Application resource which is a ArgoCD Custom Resource. With this, ArgoCD will detect the changes and show it in the ArgoCD UI. However, it will not automatically sync the state of the objects. Instead, the reconciliation will have to be manually triggered by clicking on Sync on the dashboard, or by running the CLI command argocd app sync

FluxCD

By default, FluxCD automatically syncs the resources and it is recommended to use an auto-sync policy. However, you can disable the auto-sync by 'suspending' the GitOps resource. This can be done by updating the manifest to suspend: true

To perform a manual sync on a suspended fluxCD resource, set the annotation reconcile.fluxcd.io/requestedAt to that particular fluxCD resource at the specified time. You can use the below command for the same.

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

UI Interfaces

A web-based UI is necessary for most Developers and DevOps teams as business demands them to perform operations faster and with shorter learning curves. Having access to a UI becomes a necessity when teams prefer low-code operations. While a UI adds value to day-to-day operations, it is essential that the UI can provide end-to-end visibility of the system and the proper controls for a better user experience.

ArgoCD Interface

ArgoCD provides a web-based user interface that makes managing and monitoring your deployments easy. The GUI dashboard enables users to perform various tasks, from application onboarding to deployment into Kubernetes clusters, without using the CLI. Though limited capability for advanced troubleshooting and monitoring of Kubernetes resources, most jobs can be quickly done on ArgoCD UI. All deployment-related information is available in a single dashboard, saving the users from logging in to each cluster separately to perform deployment operations.

Image Source:https://argo-cd.readthedocs.io/en/stable/

If you are looking for a much more advanced dashboard for Kubernetes management where you can perform all Kubernetes applications lifecycle management without using the CLI or kubectl command, explore the Kubernetes dashboard by Devtron.

Flux CD Interface

FluxCD does not provide a user interface and requires you to use the command line interface to manage your deployments. So a user has to rely on the CLI command to manage the deployment lifecycle. This increases the learning curve of using the FluxCD, making ArgoCD more popular among users.

There are some unofficial FluxCD web UI projects, which attempt to reduce the learning curve for FluxCD through a Dashboard. However, many of these projects are not actively maintained.

Devtron has it's own Dashboard for listing and gaining visibility into FluxCD and is actively maintained by a team of passionate cloud native developers. Please give out Devtron's FluxCD Dashboard a try if you're looking for a robust FluxCD Dashboard.

Image Source: https://github.com/fluxcd/webui

Application Deployment

ArgoCD and FluxCD support Kubernetes objects/manifest (YAML), Kustomize, and Helm. But both tools are fundamentally different in how they apply those manifests. Let us understand how they differ.

FluxCD for Application Deployment

• FluxCD uses Kustomize Controller heavily that performs all the lifecycle operations of Kubernetes manifests of applying the manifests, updating and deleting resources by syncing with the source repository. Without Kustomize, Flux generates its own kustomization.yaml to address dependencies.
• FluxCD also has native support for Helm, which enables it to perform Helm-based releases. FluxCD used a custom resource called as HelmRelease for managing deployments for Helm applications and provides FluxCD with the advantage of using hem chart libraries from various marketplaces.
• FluxCD can connect and manage to multiple Git repository using the GitRepository custom resource. For multi-cluster deployments, FluxCD used the Hub and Spoke architecture. One Hub cluster will have the FluxCD installation and the other clusters (spokes) can be managed from the Hub.

flux get kustomizations --watch

ArgoCD for Application Deployment

• ArgoCD has Kustomize, Helm and raw Kubernetes YAML. While FluxCD needed Kustomize to modify manifest files, Argo doesn't need to use Kustomize. It can perform deployments without a Kustomoize template and can sync resource directly from raw YAML manifests. But this sometimes creates an issue of sequencing builds, and some apps may fail to start because their resources aren't yet available.
• Though it may seem counterintuitive, its creators made this architecture such, to exercise far greater control over its resources. ArgoCD performs sync operations in a sequence of steps and is broadly classified into three phases pre-sync, sync, and post-sync. The sequencing allows ArgoCD to ensure resources are healthy before syncing subsequent resources.
• ArgoCD also has native support for Helm, but the approach for application deployment is different. While Flux uses the golang library directly, Argo uses the Helm charts and converts them into ArgoCD sync waves and hooks. This internal configuration prevents users from using the HELM CLI for clusters.
• ArgoCD provides far more valuable capabilities for multi cluster management. It can connect multiple Git repositories to one cluster and can manage multiple clusters from one ArgoCD instance
  

Image Source: https://argoproj.github.io/cd/

Multi-tenancy

In Kubernetes, multi tenancy refers to share the same set of Kubernetes resources with multiple tenants that are a part of the cluster, all while maintaining isolation between individual tenants. Multi Tenancy is used in large organizations as it helps reduce costs, and serve more users by efficently utilizing all avaliable resources.

Let us explore how both ArgoCD and FluxCD handle deployments in environments that have multi tenancy architectures.

Multi-tenancy in Flux CD

• FluxCD supports Multi Tenancy by segmenting and isolating resources using Kubernetes namespaces and RBAC to ensure a secure multi-tenant architecture.
• To enable secure multi-tenancy, FluxCD uses the authorization model where the FluxCD controller impersonates a service account for accessing resources and applying configurations. This in turn lets the users limit the operations performed by the FluxCD controller by using Kubernetes RBAC.
• The model assumes two user roles i.e Platform Admin and a Tenant. Platform admins have unrestricted access to the cluster and are responsible for installing and configuring FluxCD and it's relevant objects. Tenants on the other hand have restricted access to the cluster and are limited to the environments and namespaces provided to them.

Multi-tenancy in Argo CD

• Argo CD architecture supports multi tenancy natively. But it isn't available on the core package for users who don't want to use such a feature or do not have the need. To use Multi Tenancy you need to install the multi-tenancy package for ArgoCD
• Argo CD supports RBAC and SSO natively, which is crucial to limit resource operations by different users on the same cluster. It is the primary requirement to enable Multi-tenancy.
• ArgoCD lets you create projects which is a logical separation of applications. Each project is a environment for a particular tenant.
• ArgoCD can be deployed to with either a cluster scope or a namespace scope. The advantage of a cluster scope is that ArgoCD has elevated permissions and can observe the entire cluster. NameSpace Scope on the other hand limits ArgoCD to a particular namespace which is ideal for multi tenancy.
• ArgoCD allows defining RBAC permissions for each individual users at a global level or specific to projects.

Similarities in Deployment Strategies

Argo CD provides rollout strategies such as Canary, blue-green, and Progressive deployments. Flux also provides some standard Canary and blue-green releases, but the options to configure them as per need are limited.

Deployment strategies are essential in reducing risk while releasing applictions; let us understand how they differ in providing these critical features.

• To perform these deployment strategies in Flux, developers must use Flagger. Argo CD relies on Argo rollouts. Using ingress resources like Envoy API gateway, NGINX, Traefik, or a service mesh such as Istio, Linkered, and AWS App Mesh which allows users of Argo and Flux to perform run traffic switching or traffic splitting.
• Both tools provide essential metrics like CPU and throughout data for validating canary or blue-green releases. ArgoCD and FluxCD support a range of metrics analysis, such as Prometheus, Datadog, and New Relic.
• While these deployment strategies are possible, assessing a release before deployment into production requires understanding the new releases' behavior in a real-time environment. APM data is essential to perform behavior analysis enabled by CRDs in ArgoCD. Bit Flux CD lacks a feature to provide a detailed assessment of new releases. This allows Argo CD to be proactive and detect new releases before significant issues are seen in production.
• Both support rollbacks to older versions instantly.

Similarities in Feedback and Notifications Mechanisms

Alerting and instant notifications on the right channel are essential. While executing CI/CD pipelines, these notifications send out important information about status updates, metrics, health checks, risks, etc. Most users are active on messaging platforms, so they must be notified through these channels. Flux can deliver alerts using alerting and outgoing notifications. Argo CD uses Argo CD Notifications via its plugin mechanism to provide alerts and updates.

Security Concurrence

GitOs core concept is to observe Git as the sole source of truth for application and configuration data. In the case of security, one has to divert from this logic of storing all data on Git. Secrets are sensitive data like encoded tokens, passwords, etc., that should not be placed in Git repositories.

• Flux and Argo CD have their way of managing these secrets, but it is highly recommended to use external secrets management.
• While Flux has limited accessibility management capabilities and follows that of the Kubernetes RBAC, Argo CD has built-in SSO and its own RBAC configuration making access control easy for large teams.

Similarities in achieving Extensibility

Argo CD integrates with several Kubernetes tools, such as Helm and Kustomize, to provide a more flexible deployment process. Flux CD also integrates with these tools but does not provide as many integration options as Argo CD.

Argo CD and Flux are pretty modular, and through API servers inbuilt into their architecture, webhooks and extension are feasible. This allows users to build and execute more bespoke activities suites yo ones team’s needs.

Conclusion

Both the GitOps tools are resourceful while managing Kubernetes deployments. While the absence of a UI makes Flux a little tricky for new engineers, it is still a preferable tool where the requirements are not high, and one needs a cost and resource-effective solution.

Arog CD is more prevalent among budding developers becue it provides a holistic GitOps solution. Flux is limited to only Kubernetes deployments and configuration management as code.