GitOps the Hard Way, with Argo CD

The Four Install Methods, and When Each Fits

There are multiple ways to install Argo CD. Each method has its own advantages, disadvantages, and use case.

The Full Installation

The full installation uses the YAML manifests Argo CD provides in its official GitHub repository, applied with kubectl. Argo CD ships four sets of these manifests, organized along two axes: the level of cluster access Argo CD needs, and whether you want high availability.

The first axis is access scope. The standard install.yaml grants Argo CD cluster-admin rights by creating a ClusterRole and ClusterRoleBinding. It needs this to deploy applications into the same cluster it runs in. Choose it if you want to deploy applications into the same cluster where Argo CD is running. This is the most common setup; Argo CD can still manage external clusters, but that requires extra configuration.

kubectl apply -n argocd -f \
  "https://github.com/argoproj/argo-cd/raw/v3.4.2/manifests/install.yaml"

The alternative, namespace-install.yaml, asks only for namespace-level privileges. It creates a Namespace, Role, and RoleBinding instead of cluster-scoped objects, so Argo CD has no cluster-wide access. Pick it when Argo CD does not deploy into its own cluster and instead targets external clusters, or when you simply do not want to grant cluster-admin. You can still deploy to the local cluster afterward by registering it with argocd cluster add.

One caveat with the namespace-scoped install: it does not bundle the Argo CD Custom Resource Definitions. You have to apply them yourself from the manifests/crds kustomize directory before Argo CD will work:

kubectl apply -k \
  "https://github.com/argoproj/argo-cd/manifests/crds?ref=v3.4.2"

The second axis is high availability. Each of the two manifests above has an HA counterpart under the ha/ path: ha/install.yaml and ha/namespace-install.yaml