FluxCD vs ArgoCD

Comparing Flux CD and Argo CD for Efficient GitOps Delivery

What is GitOps?

GitOps, like any other technology in DevOps, follows the practice of using Git as the centralized source of truth for both the application and the infrastructure it runs on.

The Git repository defines the state of the application and infrastructure, and any changes made to either of them are implemented through pull/merge requests that undergo peer review. Manual changes to the infrastructure are minimized or eliminated, particularly in Kubernetes environments where GitOps aligns well with the declarative programming model used by cluster manifests.

If already being familiar with using Git as the single source of truth for application code and infrastructure, similarly you store Helm charts / Kustomization files, and other manifests in a preferred Git platform. Changes are reviewed and automatically applied to the cluster through a CI/CD pipeline. Tools like Argo CD and Flux CD were developed to streamline operations and provide additional functionality.

Comparing with Traditional CI/CD

It’s important to note that GitOps tools are not intended to replace CI/CD; they serve different purposes.

CI/CD pipelines primarily focus on the CI part, while tools like Argo CD / Flux CD excel at managing the CD part, particularly Kubernetes environments.

A typical CI/CD pipeline, functions as a build server that connects to a Git repository. When changes are made to the main branch (e.g., through merging a branch), the pipeline is triggered and applies the code changes to the cluster. Deployment tools like Helm and Kustomize are commonly used to handle complex application deployments.

On the other hand, a GitOps tool operates within the cluster itself. It detects changes in the Git repository and automatically applies them to the cluster. Here are some key differences:

Authentication

CI/CD tools require a service account with the necessary credentials to connect to and manage the Kubernetes cluster. In contrast, GitOps tools don’t need to store Kubernetes credentials externally since they operate from within the cluster. This mitigates the risk of storing sensitive credentials outside your infrastructure.

Desired state enforcement

GitOps tools not only apply changes from Git when detected but also continuously monitor the cluster for any deviations. As Git represents the single source of truth, it defines the desired state of the cluster. If any divergence occurs, GitOps tools can automatically revert the cluster to conform to the code stored in Git.

Declarative programming

GitOps employs a fully declarative programming paradigm. Instead of specifying command-line instructions like “helm upgrade — install #rest of the command” in a CI/CD pipeline, you create a YAML document that defines which charts should be deployed to which namespaces and with which values. The GitOps tool takes care of tasks such as installing Helm, adding or updating the chart repository, making the process more automated and less reliant on specific CI/CD containers.

GitOps tools with greater visibility into the cluster’s operations. You can obtain detailed information about running deployments and other cluster-specific details beyond what CI/CD tools typically display in their logs.

Comparing Features

Synchronization

Both Argo CD and Flux CD automatically synchronize the state of the Kubernetes cluster to match the state defined in the Git repository.

The workflow typically involves creating a new branch for making changes, creating a merge request to merge the changes into the main branch, reviewing and approving the merge request, and then the GitOps tool, whether Argo CD or Flux CD, detecting the change and applying it to the cluster.

Flux CD offers an automated image update feature, which can detect updated images in the repository and automatically update the deployment manifest.

Argo CD, on the other hand, utilizes simplified synchronization, comparing the desired state in Git with the live state in the cluster and synchronizing them based on user-defined automation levels. This approach simplifies understanding and debugging in case of issues.

The UI / UX

In terms of user interfaces, Argo CD provides a feature-rich UI. It offers visual representations of applications, including health and sync status, detailed views of Kubernetes resources and their status, and a diff viewer to display differences between the live state and the desired state defined in Git. Argo CD’s UI allows manual synchronization, rollback to previous states, and direct management of application lifecycle. It also provides a consolidated view across multiple Kubernetes clusters if you’re managing applications in a distributed environment.

Although Flux CD does not offer a comparable built-in UI, there are projects and extensions that provide some graphical interfaces for managing Flux CD if you prefer a GUI-based approach. Weave GitOps and other similar tools can serve as UI options for Flux CD.

Deployment Strategies

Both Argo CD and Flux CD support advanced deployment strategies like Blue/Green and Canary deployments, but they require additional components to enable them.

Argo CD utilizes Argo Rollouts, an extension that provides advanced deployment strategies as a drop-in replacement for standard Kubernetes Deployment objects.

Flux CD, on the other hand, integrates with Flagger to support advanced deployment strategies. Flagger can be used with various GitOps tools and simplifies the management of complex deployment processes by offering automated handling of progressive delivery and extensive metrics and alerts.

Templating

Regarding templating, Argo CD offers flexibility through the ApplicationSet component, which allows for dynamic generation of Applications using Go templates.

Flux CD does not provide a similar level of flexibility out of the box, but you can leverage the Kustomize controller for achieving similar results, although with more complexity in the implementation.

Sync Intervals

When it comes to the granularity of sync intervals, Flux CD with Kustomize allows you to define the interval at which changes are applied to different clusters. Flux CD determines the target cluster through the Kustomization path.

In Argo CD, syncing with the Git repository happens every three minutes by default (configurable), and specifying different sync intervals or deployment intervals for clusters is not natively supported.

Helm Templates Support

Both Flux CD and Argo CD offer support for using Helm declaratively.

In Argo CD, you create an Application that uses Helm as the source and provide a values.yaml file and overrides for specific configurations. This allows you to define deployments declaratively, similar to using the below

```sh

helm upgrade — install myChart — set some.key=someValue -f values.yaml myChart

```

In Flux CD, you need to define two components: HelmRepository and HelmRelease, to utilize Helm functionalities.

Flamingo - to combine Flux CD with Argo CD into a unified tool, providing the benefits of both approaches.