Argo, flux, fleet, gitlab pull based…. Does anyone have recommendations for a good comparison blog post?

I don't have anything written up but I extensively compared Argo CD vs Flux about 6 months ago and chose Argo CD in the end. I'm really happy with it and currently deploy multiple services to multiple environments (different AWS accounts for each env) in a way that works for multiple teams being able to deploy releases on their own.

I only use it in a pretty basic way for now (Argo CD + Pre/Post sync hooks + Notifications) but I'm starting to look into using Argo Events + Workflows. I feel like Argo CD pulls everything together as a cohesive framework for deploying workloads into Kubernetes, plus there's a built in web UI that's nice to give read-only access to developers so they can see details about their workloads without needing cluster access with kubectl.

Thanks for the thoughts. Looking at solutions to help with state drift in multi-tenant clusters. Using lots of rancher but a dev “flipping switches” sometimes creates pain for me. Argo seemed to be a good solution to “no more kubectl in prod” but I think there is some neato fleet integration with Rancher. Thanks again!!

The biggest difference between the two is how it runs.

If you have many clusters then you get to chose between many or one argocd instance. We run a few argo instances that manage many clusters.

If you use flux, all of cluster needs to have access to github. If you run argo you can restrict it so that the argo cluster (which manages many others) only needs access.

You still have to have argo get access to the child clusters.

I prefer the simplicity of flux, I like the read only ui of argo.

The thing I really don't like about argocd is that you have to give the parent cluster admin to every cluster it manages. If you use git webooks you've now had to expose your controller that can manage your fleet to the public.

Argocd also randomly has really bad bugs show up. Like completely ignoring appsets. Or pathological syncing cases.

I have seen a series of reviews from Giant Swarm. Example: https://www.giantswarm.io/blog/gitops-with-gitlab-agent-for-...

They forgot one con off pull based deployments which is that you need to put a repository key in your cluster where your code is running. This was a nonstarter for a lot of companies I worked for.

Also if I was going for pull based I would use Argo or Flux, not some gitlab feature half stitched together by underpaid devs

The GitLab PM responsible for the agent for Kubernetes work here.

The agent supports automatic (and short lived) support for registry keys for the push-based approach with [Auto Deploy](https://docs.gitlab.com/ee/topics/autodevops/stages.html#aut...), and we have documented how one can [set up container registry keys for the pull-based approach](https://docs.gitlab.com/ee/user/clusters/agent/gitops/secret...)

The difference between Argo/Flux and the agent is that Argo and Flux are pull-based deployment point solutions (especially Flux), while the agent (originally built on shared codebase with Argo) is the basic integration layer for GitLab - Kubernetes connections. This way, already today, GitLab provides integrated container vulnerability scanning that is out of scope for the other tools.

About the half-stitched solution, among the three mentioned tools, only the agent supports server-side applies. The others have it as planned features. If you ever struggled with setting up the right annotations to use pull-based deployments and any competing controller at the same time, using server-side applies provides a lot of benefits.

I use Flux, it's great once you grok it and get it configured. Docs are a bit sparse in some areas for things like containers but otherwise quite easy and powerful to set up. One example is that I had my infra code stored in Github and wanted to migrate it to Gitlab. Simple as pushing the existing repository up to Gitlab instead and then flux init Gitlab - everything works as it did before.

> They forgot one con off pull based deployments which is that you need to put a repository key in your cluster where your code is running.

Conversely for push-based deployments, there's a process running somewhere outside your cluster that has admin access to your cluster. Did you analyze the threat models for both push and pull, and decide that push is less risky?

Does the "GitLab Agent" need cluster admin privileges or can it be run in a single namespace with limited permissions?

By default it runs with "cluster-admin" privileges but you can "bring your own RBAC permissions for the agent", see https://docs.gitlab.com/ee/user/clusters/agent/install/index...

If normal operations expect to be able to use different namespaces to test branches, creating namespaces etc, then bringing your own RBAC can't help.

I tried doing that a couple of weeks ago, but it seems to be a GitLab premium feature