Argo CD vs Flux CD — Right GitOps tool for your Kubernetes cluster

Before we start with the battle, let me set some context for those who are new to GitOps and its tooling. The basic idea behind GitOps is having a version-controlled code, like in a Git repo, that holds a declarative definition of the infrastructure that we expect in production and an automated process that will make sure we have that state there.

This means that every pull request can release a new feature for your audience and any breaking point can be rolled back with a simple git revert. Ergo, the developers need access to only the code and not the live environment. Note that this does not mean that we are limiting the developers; this only enables your developers by bringing the environment closer to them.

Both Argo CD and Flux CD are renowned tools that match your live environments with the desired states in your Git repositories. And this story will help you understand the core functionality of these tools followed by a fair comparison so that you can make the right choice.

Argo CD

Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. It has scalability, security (with SSO integration as well), multi-cluster multi-tenancy support and extensibility.

Installation

The installation of Argo CD is pretty straightforward and can be seen on the getting started page.

To access the UI, expose the Argo CD server with either of these 2 methods

And if you plan to use just the core Argo CD, you can control it with the argocd CLI. To install the CLI, simply run

Core concept

In Argo CD, all related resources are grouped and deployed as a unit called Application. Each application will be part of a Project, which is Argo CD’s unit of tenancy. Each tenant can be restricted to a namespace and cluster.

Your application is linked to a version control like Git, which decides the states of the application. Once deployed, the resources are said to be in Live state. Whenever the code gets changed in Git, a new Desired state gets created which can be viewed by a quick Refresh on the dashboard. To match your live state with the desired one, you can Sync them.
It will also allow you to monitor the Health of your application and in case of a failure, will let your roll back to the old revisions using History & Rollback feature.

Walkthrough

Now onto the dashboard…
The dashboard looks very contemporary and is quite intuitive. To start with a new project, just click the New App button and fill in the following details.

In the source section, provide the Git repo URL and path to the folder (which is a reactive drop-down derived from your repo). Then scroll down to choose the cluster which can be any one of those that you’ve already registered.

Once created, you’ll see a card that goes by your app name on the home dashboard. Click on it to reach this view. For this demo, the guestbook example app is used.

The live state is not equal to the desired state (since we haven’t deployed anything yet) and so it displays the OutOfSync state. Click on the Sync button now to deploy.

This view shows as granular as the pods within the replicasets within the deployments. Here you can click on any element to view their events, logs and state.

Now whenever the code in your Git changes, you can click Refresh to see the new Sync status. If it goes out of sync i.e. resource change is needed, you can click on App Diff to view those differences and click Sync to deploy them.

Flux CD

Originally developed by Weaveworks and now incubated under CNCF, Flux is a set of continuous and progressive delivery solutions for Kubernetes that are open and extensible.

Installation

Flux has a CLI-first approach with UI being just a supplementary add-on. To install Flux CLI, use either of these

Once you have the CLI installed, use the following command to install Flux on your Kubernetes cluster

Core concept

Flux is a more direct approach to GitOps with lesser human interference. The process starts by Bootstrapping. This installs the flux components on the cluster which will monitor a directory on the Source. Anything that changes on this source will be updated onto the cluster through the process of Reconciliation. It can be used with Helm releases, Kustomization or artefacts stored in a bucket.

Walkthrough

Let's start with some pre-configuration…
Export the Git login details that’ll be used by flux CLI to interact with your repo.

Next, check if your cluster is compatible. You should see an output like this

Now install flux to your cluster with git configuration

This will create a test-repo in your GitHub account and add the Flux component manifest in the repo. It will also deploy the flux components to the cluster and configure them to track ./clusters/my-cluster/ directory in your cluster. If you clone this repo and check the content, you’ll find something similar to this

With this, your setup is ready. You can create any manifest in test-repo/clusters/my-cluster/ and flux will poll it and deploy the updates.

You can also try out its experimental web UI.

So which one should I go for?

Though they both follow the same path, there are differences between these tools. Let’s see them and then I’ll let you decide what works best for you

Flexibility in code collaboration

Argo lets you connect multiple repositories by adding new applications to a project. Flux lets you do the same by adding new repositories once it has bootstrapped. Hence, in both cases, it is easier to collaborate when multiple teams work on a single application and provide different manifests.

Manifest tooling support

Both Argo and Flux work with Helm and Kustomization. Argo additionally works with ksonnet and jsonnet as well. Furthermore, both these support custom config management tools configured as a config management plugin.

Multi-tenancy

Till a few months ago, this would’ve fallen in Argo’s basket as well, however, Flux v2 support for multi-tenancy and server-side reconciliation now evens this field.

Web UI

Argo comes with a powerful UI that helps visualize relations between different objects and monitor them better while with Flux you rely completely on CLI. You can add on the web UI to Flux but it still stays experimental.

Authentication

Argo can be integrated with SSO and has additional built-in support for RBAC. Flux works with just RBAC for the service account.

Automation container updates

Flux has the upper hand here with automation container updates which on the other hand requires a manual commit and sync in Argo.

Management

Another point to Flux for its simple design. Flux can automatically deploy your applications with next to zero maintenance. Argo needs you for deployments but I personally prefer it here for having that control.

The final verdict

Both Argo and Flux are amazing tools that serve great for their use cases. Simply due to the extensible control and versatility of Argo, I’m always inclined towards Argo. However, Flux v2 might change that soon!