Flamingo - The Flux Subsystem for ArgoCD (FSA)

You are all familiar with these two very powerful open source tools that enable GitOps (using Git as the single source of truth and to automate operations) for both infrastructure and application deployment.

Argo CD is a continuous delivery tool that uses GitOps to sync the state of the cluster with a Git repository. It monitors changes in the Git repository and automatically deploys applications when changes are detected. Argo CD offers advanced features like version comparison, update tracking, release management, and the ability to deploy to multiple clusters.

FluxCD, on the other hand, is a continuous delivery tool that also uses GitOps to sync the cluster state with a Git repository. FluxCD takes a more modular approach, where features are provided by plugins called "controllers." FluxCD has controllers for application deployment, image updating, events handling, and release management.

In summary, both tools are similar in their use of GitOps to sync cluster state with a Git repository, but Argo CD is more focused on application management and offers more advanced features, while FluxCD takes a more modular approach and provides features via plugins called controllers. The choice between them will depend on each organization's specific needs regarding continuous delivery.

Ultimately, the choice between Argo CD and Flux CD depends on the needs and preferences of each development team. Both tools offer similar capabilities and are both able to handle continuous delivery of applications on Kubernetes.

Tools:

• ArgoCD
• FluxCD

Repositories:

• https://github.com/flux-subsystem-argo/flamingo
• https://github.com/flux-subsystem-argo/fsa
• https://github.com/herveleclerc/flamingo

The Flamingo project

Flamingo is an interesting project that allows combining the best features of Flux and ArgoCD into a single solution.

Flamingo patches ArgoCD by adding a Flux subsystem.

What I don't like about ArgoCD

If you deploy a helm chart via an Application "custom resource" defined in ArgoCD, this resource, equivalent to a helm template, deploys the resulting manifest.

In this case, you lose the ability to use helm CLI commands. E.g. helm list will obviously return nothing.

What I don't like about FluxCD

FluxCD is a very powerful "GitOps" tool, but it does not have a graphical interface.

Weaveworks offers a simple dashboard, but with little functionality.

On the contrary, ArgoCD offers a powerful graphical interface allowing the different teams of a project to work together. ArgoCD offers the notions of projects, teams, users with fine-grained access rights management.

Flamingo's approach

Have both GitOps tools working together in a Kubernetes cluster. This allows, for example, to have a unified interface with ArgoCD to monitor projects deployed either by ArgoCD, Flux, or both at the same time.

The Flamingo patch on ArgoCD allows managing Flux resources either via the command line or in the graphical interface.

If you deploy a Helm chart-based application you can ask for Flux resources to be created automatically.

You will then be able to use both the helm and flux commands.

How Flamingo works

Loopback Reconciliation

A Loopback Reconciliation is a Flamingo feature that synchronizes applications deployed using the GitOps approach. The function is enabled if the FluxSubsystem flag is set to "true" in the ArgoCD UI or of course in the application manifest.

Workflow of "Loopback Reconciliation"

1. The application manifest is created or deployed either in Kustomize or Helm mode
2. Flamingo converts the ArgoCD application into Kustomization or HelmRelease objects, the source object will be deduced from the previous objects. If the objects already exist, Flamingo will use them as references rather than creating new ones.
3. Flamingo synchronizes or reconciles the state of the ArgoCD application with the states of the Flux objects as desired state. ArgoCD's native reconciliation is not used and is replaced by that of Flux.

Deploying Flamingo

Prerequisites to use flamingo:

• a Kubernetes cluster
• Flux CLI (https://fluxcd.io/docs/cmd/)
• ArgoCD CLI (https://argo-cd.readthedocs.io/en/stable/cli_installation/)
• Helm CLI (https://helm.sh/)

Install Flux on the cluster

flux install

Flamingo can be deployed in 3 different ways:

First determine which version of flamingo you are going to use

export FSA_VERSION=v2.6.6-fl.4-main-0d5eae51

• By upgrading an existing ArgoCD, simply replacing the ArgoCD image with the modified flamingo image

kustomize build https://github.com/flux-subsystem-argo/flamingo//release?ref=${FSA_VERSION} \
  | yq e '. | select(.kind=="Deployment" or .kind=="StatefulSet")' - \
  | kubectl  -n argocd apply -f -

This method is interesting if you already have an ArgoCD configured for Flamingo (rbac, users, plugins, etc).

• By replacing the entire ArgoCD already deployed (ArgoCD configurations will be reset!)

kubectl -n argocd apply -k https://github.com/flux-subsystem-argo/flamingo//release?ref=${FSA_VERSION}

• By installing Flamingo from scratch

kubectl create ns argocd
kubectl -n argocd apply -k https://github.com/flux-subsystem-argo/flamingo//release?ref=${FSA_VERSION}

Alternative to the latter:

You can also use the OCI package I created from the manifests directory in the repo (https://github.com/herveleclerc/flaming). The package is stored in a public github registry (ghcr.io/herveleclerc/manifests/argocd)

Deploy the following manifest:

cat <<EOF | kubectl apply -f -
---
apiVersion: source.toolkit.fluxcd.io/v1beta2
kind: OCIRepository
metadata:
  name: flamingo-demo
  namespace: flux-system
spec:
  interval: 30s
  url: oci://ghcr.io/herveleclerc/manifests/argocd
  ref:
    tag: 1.0.1
---
apiVersion: kustomize.toolkit.fluxcd.io/v1beta2
kind: Kustomization
metadata:
  name: flamingo-demo
  namespace: flux-system
spec:
  targetNamespace: argocd
  prune: true
  interval: 2m
  path: "./init"
  sourceRef:
    kind: OCIRepository
    name: flamingo-demo
    namespace: flux-system
  timeout: 3m
EOF

The first resource defines an OCIRepository "custom resource" to fetch manifests packaged in OCI format from a github registry

The second a Kustomization to deploy the manifests contained in the init directory of the OCI package.

This Kustomization deploys Flamingo (FSA).

Accessing the ArgoCD interface

• Retrieve the administrator password with the following command:

kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d; echo

Small Note: Did you know that there is a nice plugin for kubectl to decode secret passwords?

Just deploy it with the krew utility. Then to decode a secret just do:

kubectl view-secret -n argocd argocd-initial-admin-secret

Simpler right? 😜

• Go to the interface by proxying ArgoCD's port 443

kubectl port-forward -n argocd svc/argocd-server 9000:443

You can now access the ArgoCD interface by typing the url https://localhost:9000 in your browser.

You should get this login interface:

user: admin
password: the value returned from the argocd-initial-admin-secret secret

Hooray! you're in the ArgoCD main interface

For our tests, we will use a Helm chart to deploy a small Go-based web application that gathers best practices for running microservices in Kubernetes: PodInfo

First test: Deploy a Helm chart with ArgoCD

...

Second test: Deploy a Helm chart with ArgoCD and the Flux Subsystem enabled

...

Third test: Deploy an application based on an OCI package and Flux

...

Conclusions

Flamingo allows us to manage Flux resources in ArgoCD. The project is young and must obviously mature and acquire new features. The main problem today is that when an application is deleted even if its finalizer is set, the Flux resources are not deleted and must be cleaned up "by hand" with Flux commands.

E.g.

flux delete helmrelease bb-podinfo-helm-with-fsa -n podinfo-helm-with-fsa
flux delete source helm bb-podinfo-helm-with-fsa -n podinfo-helm-with-fsa

In summary, Flamingo combines the strengths of ArgoCD and Flux into a single GitOps solution with a unified interface. It is a promising project that will likely continue to evolve and improve over time.