ArgoCD vs. Flux vs. Jenkins-X — Which solution is the best for managing deployment in Kubernetes?

Choosing the right solution for managing your Kubernetes deployments can be difficult. Every use case has different needs, and there are a variety of solutions to choose from. In this blog post, we’ll compare three solutions: ArgoCD, Flux and Jenkins-X. We’ll outline the pros and cons of each solution, so you can make an informed decision about which one is best for your specific needs.

We were looking for a way to manage deployments in Kubernetes, and we decided to implement a GitOps methodology.

• Desired state is expressed declaratively and stored in git for version control.
• Controlled and auditable changes on the desired state through git workflows.
• Software agents are responsible for ensuring the desired state is applied correctly to the system and alert on divergence.

We have looked at solutions that facilitate this approach which we will discuss further in this post.

The criteria

When looking for the best solution for our use case, we had to compare different options that meet the following criteria:

Must-have:

• Multi-tenant: it was essential for us to have a system that allowed us to set up a basic infrastructure on a Kubernetes cluster and enable tenants to deploy their own resources to the cluster. Moreover, this needed to be implemented in a secure way so that tenants would operate with the principle of least privilege.
• Multi-cluster: We also needed the system to allow us to target different Kubernetes clusters and facilitate the use of a common set of configurations as much as possible.
• Automation support: We needed to be able to integrate the system with existing CI/CD workflows and we needed a solution that would make it easy to set up new workflows leveraging the selected system.
• Visibility: We needed a system that could provide an overview of all reconciliations in the cluster and their status since we wanted to compare the desired and actual states of the cluster.

Nice-to-have:

• Container workflow: Ideally the system should provide a workflow for updating container versions in deployments automatically.
• Alerts and notifications: The system should be able to send events/alerts on specific triggers such as a failing reconciliation loop.
• Progressive delivery: To facilitate the upgrade of applications in production we might want to have the possibility to specify canary deployments, blue/green deployments, etc. Having this integrated with the chosen gitops tooling allows for a unified release process to be defined.

Our analysis

To pick the best solution for our use case, we decided to compare three options: ArgoCD, Flux, and Jenkins-X.

ArgoCD and Flux are CNCF incubating projects, either in the process of graduating (Flux) or planning for graduation (ArgoCD). They both looked very promising to us; however, we decided not to move further with the evaluation of Jenkins-X mainly because of the lack of documented usage in a multi-tenant scenario.

ArgoCD

ArgoCD has the concept of an Application, a group of Kubernetes resources defined by a manifest that can be sourced from a git repository. Each Application belongs to a Project, which is ArgoCD’s representation of a tenant. An Application defines a source type that defines which tool is used to build Kubernetes manifests (Kustomize, Helm, or Ksonnet, among others.)

ArgoCD implements a sync process that specifies how the desired state of an application should move to a target state. This process is configurable and does this independently of the tool used to define the application. (It does not use Helm or Kustomize directly but renders the template files and pipes them to kubectl.)

Flux

Flux, on the other hand, is more loosely coupled and consists of several controllers that have a dedicated role:

• Source Controller, which provides a common interface for sourcing desired state,
• Kustomize Controller, which implements a reconciliation loop using Kustomize
• Helm Controller: implements reconciliation loop using Helm
• Notification Controller: responsible for handling inbound (e.g. webhooks) and outbound events (alerts).
• Image Reflector and Image Automation Controller: allows to scan container registry for new revisions (reflector) and update deployments with the new revision (automation).

Security

Security was a critical factor we considered when comparing the two solutions. We found that Flux has no built-in RBAC, but instead leverages Kubernetes RBAC and Service Accounts and conforms with Kubernetes best practices. ArgoCD has an ACL-based RBAC mechanism that is independent of Kubernetes RBAC and has its own user management. From the perspective of Kubernetes API, ArgoCD has full administrative permissions in the cluster, authentication and authorization are the responsibility of ArgoCD.

Comparison of features

• Multi-tenant: both are capable of supporting multiple tenants.

Flux builds on native Kubernetes RBAC and Service Accounts. In this way, the multi-tenancy infrastructure that is set up for the cluster in general (e.g., technologies like Hierarchical Namespaces or Capsule) can be leveraged for gitops multitenancy.

ArgoCD, through its ACLs, allows multiple Projects to co-exist on a Kubernetes cluster.

• Multi-cluster: both are capable of supporting multiple clusters and can be deployed in a ‘pull’ (instance deployed to each cluster) or ‘push’ (one central instance that targets remote clusters) configuration.
• Automation support: both are extensible and provide hooks for triggering deployments through webhook events and have a solution for secret management.
• Visibility: Both provide integrations with Prometheus and AlertManager to monitor the state of reconciliations and can use custom events.

An advantage that ArgoCD has over Flux here is that it comes with an extensive UI that visualizes the sync process. While there is a similar UI for Flux, it is considered highly experimental.

• Container workflow: both are able to automatically update deployments with a new revision pushed to a remote registry.
• Alerts and notifications: both have a system for sending events to remote systems (ArgoCD Notifications and Flux Notification controller).
• Progressive delivery: both have a companion project that allows to set-up progressive delivery (Argo Rollouts and Flagger).

And our winner was…

In the end, we chose to go with Flux for the following reasons:

• Using native Kubernetes RBAC and Service Accounts, Flux allows for integration with a multi-tenant solution such as Hierarchical Namespaces or Capsule. At the same time, multi-tenancy in ArgoCD is completely self-contained.
• The entire deployment of Flux can be automated using Flux bootstrap. All configuration is part of the cluster desired state, which effectively allows Flux to manage its own lifecycle.

We can conclude that both ArgoCD and Flux are great solutions with a comparable feature set. Both were capable of implementing the GitOps workflow we wanted; however, Flux seemed to be a better match for what we were looking for in this specific use case.

If you want to find out more about these solutions, click the links below:

Flux: official site and GitHub

ArgoCD: official site and GitHub

Jenkins-X: official site and GitHub