4 ms·

You might like Flux instead of Argo. A single controller still reconciles cluster-wide, but it does have the ability to define resources in different namespace

You might like Flux instead of Argo. A single controller still reconciles cluster-wide, but it does have the ability to define resources in different namespaces and repositories, as well as dropping privileges to enforce k8s RBAC for resource creation.

aliasxneo 3y ago
I'm working through the Argo vs Flux debate right now. Not that they have to be mutually exclusive, just would rather start with one. It's a pretty tough decision.
- willejs 3y ago
  Deploy both and see which patterns you prefer, and what fits into your organisation better. I have used both, but find Argo can be unnecessarily complex, and focuses solely as git as a source of truth for your k8s resources. The image updater can even write back to git to reflect version numbers etc, which is arguably an anti-pattern (git is not a database). However, the UI is excellent and is very powerful, and if your just getting started in the gitops space, its very intuitive. I feel like the weaveworks team (who created flux) have encountered the problem of using git as a source of truth at scale. They let you specify other sources such as S3 and OCI containers, this gives you a lot more power to build custom, powerful workflows. This means that you define your k8s resources (kustomizations definitions defining k8s resources, and flux resources) in git, but build, lint and test them in a CI/CD pipeline and publish them as a container. Then you can just tag that container with the cluster name or environment and treat your k8s resources like you would code. You can observe this with the flux ui too. I think people get too hung up on the git part of gitops. All infrastructure should be defined in a version control system, and follow a sane CI process, but the way your cluster pulls that state to enforce it should be any source that is a reflection of that versioned code in SCM.
  - hanikesn 3y ago
    Absolutely, and argo really falls short when you have more complex patterns, like monorepos and promotion between different envs. Then you have to revert to argo events and workflows anyways and script your way through it.
    - RyeCombinator 3y ago
      Totally, then you have argo rollouts, argo workflows,argo events, and now kargo https://github.com/akuity/kargo https://github.com/akuity/kargo They're encouraging adoption of the entire stack, which is interesting on its own. Argo has arguably done a much better job selling themselves with all the resources poured into their marketing.
- nullify88 3y ago
  At dayjob we run ArgoCD, at home I prefer to run Flux which is much lighter for my home lab. No GUI, redis, dex, and the various controllers and servers. Flux is very simple and is able to suite my needs.
- linuxftw 3y ago
  The two features that worked easily in Flux that pushed my team to pick that over argo are 1) Flux can source helm values (and postRender variable replacements) from configmaps and secrets on the cluster; This allows us to setup each cluster with environment specific information at creation time (immutable information about the cluster essentially) without having to copy that data to our flux repos and 2) The ability to use kustomize to patch manifests from helm post-render as well. You can patch anything before it's applied to a cluster, which allows you do deploy upstream charts without having to fork them for your needs.

aliasxneo 3y ago

I'm working through the Argo vs Flux debate right now. Not that they have to be mutually exclusive, just would rather start with one. It's a pretty tough decision.

willejs 3y ago
Deploy both and see which patterns you prefer, and what fits into your organisation better. I have used both, but find Argo can be unnecessarily complex, and focuses solely as git as a source of truth for your k8s resources. The image updater can even write back to git to reflect version numbers etc, which is arguably an anti-pattern (git is not a database). However, the UI is excellent and is very powerful, and if your just getting started in the gitops space, its very intuitive. I feel like the weaveworks team (who created flux) have encountered the problem of using git as a source of truth at scale. They let you specify other sources such as S3 and OCI containers, this gives you a lot more power to build custom, powerful workflows. This means that you define your k8s resources (kustomizations definitions defining k8s resources, and flux resources) in git, but build, lint and test them in a CI/CD pipeline and publish them as a container. Then you can just tag that container with the cluster name or environment and treat your k8s resources like you would code. You can observe this with the flux ui too. I think people get too hung up on the git part of gitops. All infrastructure should be defined in a version control system, and follow a sane CI process, but the way your cluster pulls that state to enforce it should be any source that is a reflection of that versioned code in SCM.
- hanikesn 3y ago
  Absolutely, and argo really falls short when you have more complex patterns, like monorepos and promotion between different envs. Then you have to revert to argo events and workflows anyways and script your way through it.
  - RyeCombinator 3y ago
    Totally, then you have argo rollouts, argo workflows,argo events, and now kargo https://github.com/akuity/kargo https://github.com/akuity/kargo They're encouraging adoption of the entire stack, which is interesting on its own. Argo has arguably done a much better job selling themselves with all the resources poured into their marketing.
nullify88 3y ago
At dayjob we run ArgoCD, at home I prefer to run Flux which is much lighter for my home lab. No GUI, redis, dex, and the various controllers and servers. Flux is very simple and is able to suite my needs.
linuxftw 3y ago
The two features that worked easily in Flux that pushed my team to pick that over argo are 1) Flux can source helm values (and postRender variable replacements) from configmaps and secrets on the cluster; This allows us to setup each cluster with environment specific information at creation time (immutable information about the cluster essentially) without having to copy that data to our flux repos and 2) The ability to use kustomize to patch manifests from helm post-render as well. You can patch anything before it's applied to a cluster, which allows you do deploy upstream charts without having to fork them for your needs.