Fleet HelmOps, and ArgoCD GitOps

Which should I use?

  To cut to the chase, it is my contention that you should use both. I have had this conversation a number of times now, and there is a time and place for both in your infrastructure assuming one or more of the following conditions:

1. You use Rancher MCM
2. You have many clusters
3. You deploy development clusters on a regular basis

  How often has a bare cluster been enough? How many times have you needed to deploy your preferred ingress? How many applications have you deployed that have a dependency on cert-manager? Once you have deployed your cluster, what about DNS, how do you actually access the cluster? In short: I just need a test cluster, and I need cert-manager, Traefik, and a CSI. How do I intend on doing that simply, so I can just test an application before deciding if I want to use it?

  ArgoCD is a phenomenal tool, but getting a downstream cluster into ArgoCD requires a whole pipeline of some sort to deploy your cluster, generate access credentials, pass that to ArgoCD, and configure ArogCD to deploy said applications. A well oiled machine can do this, but it would require a whole pipeline of tools running in order. Why make life so complicated though, what if all you need is a test cluster? That is a whole lot of work to do something exceptionally simple. ArgoCD makes starting/pausing deployments easy, it is easy to debug deployment failures, has a clear UI for finding differences between git and what is deployed, etc. So why use Fleet?

  Fleet, and in particular, Fleet’s HelmOps CRD, makes simple deployments to downstream Rancher clusters phenomenally simple. With the HelmOps CRD you don’t even need a git repo. Define your Helm deployment, what clusters to target, and you are done. When you create, or import a cluster in Rancher you can label it, this is often how I use cluster labels to define what applications I want deployed to a cluster.

An Example

  The Intel device plugin operator: This is one part of the Intel GPU operator, it relies on cert-manager, and the Node Feature Discovery operator (note: both cert-manager, and NFD are also HelmOp CRs not displayed here). The CR below defines those as dependencies, when those have deployed, the Intel device plugin operator will deploy via Helm. No git, no access credentials needed, nothing. Any cluster attached to a Rancher instance automatically has Fleet deployed to it, no further configuration required.

---
apiVersion: fleet.cattle.io/v1alpha1
kind: HelmOp
metadata:
  name: intel-device-plugins-operator
spec:
  defaultNamespace: kube-intel-gpu
  dependsOn:
    - name: cert-manager
    - name: node-feature-discovery
  keepResources: true
  targets:
    - name: default
      clusterSelector:
        matchLabels:
          fleet.application.deploy/intel-gpu-operator: "true"
  helm:
    releaseName: intel-device-plugins-operator
    repo: https://intel.github.io/helm-charts/
    chart: intel-device-plugins-operator
    version: 0.37.1
    takeOwnership: true

  I have made extensive use of this method of deployment. I have removed my GitOps tool of choice (ArgoCD) from needing to handle low level cluster applications, and moved that to Fleet. Most of the deployments you see below have little to no differences between them. Some do need some minimal per-cluster changes, like external-dns but that is easily handled by using Fleets built in templating. You can see my current use of the HelmOps CR below:

  I have a rather simple convention for labels too. I have a table in my Fleet repo’s README file that defines the labels each HelmOps CR uses to target clusters:

It is worth noting the labels are also arbitrary, they could be anything, even just: longhorn: true. If I apply any of these labels to a cluster, the corresponding application is deployed….just like that, no song and dance, and no pipelines.