Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

🏠 Back to Blog

Installing ArgoCD

One of the key features to ArgoCD, besides the capability to deploy Kubernetes resources within source repos and applyl them automatically to a cluster, is it’s ability to continually enforce those configurations and automatically manage configuration state drift. ArgoCD does this with a controller.

ArgoCD Configuration

  • Most of the configuration for ArgoCD is stored in config maps and secrets. However, ArgoCD does create some custom resource definitions that it uses to manage the state of more esoteric resource types. These resources include:
    • Applications
    • ApplicationSets
    • AppProjects

Controllers vs. Operators

  • Controller: non-terminating control loop that watches the desired state of at least one resource and reconciles the current state to match
    • ex: Deployment > ReplicaSet > ReplicaSet controller makes sure the pods actually match
  • CRD: registers a new resource type with the k8s API server. Defines the allowed fields and adds a new API endpoint
    • needed because configmaps/secrets are just key/value and can’t model much
  • Operator: a controller that is applied to CRDs and has domain knowledge about what the values mean
  • ArgoCD uses all of this. The controllers/CRDs are fundamental to how it works

Installation Types

Three decision points:

  1. Who are the users? (multi-tenant vs. core)
  2. What scope should ArgoCD manage? (cluster vs. namespaced)
  3. Is HA a concern?
  • There are two installation modes:
    1. Cluster-Scoped
    • The most common and default method for installing ArgoCD
    1. Namespace-Scoped

Multi-tenant vs. Core

  • Multi-tenant: the full feature set. Most common
  • Core: minimal set of components
    • no API server, UI, SSO, or notifications
    • each component is tuned to use minimal resources, non-HA
    • good for a single user who is both admin and end user and just wants the GitOps basics

Cluster vs. Namespaced

  • Cluster (default): ArgoCD can control resources across the entire cluster. Preferred when cluster admins are the ones using it
  • Namespaced: ArgoCD is deployed in a namespace and can only manage resources in specific namespaces
    • for multi-tenant envs where app teams run their own ArgoCD but don’t get access to cluster scoped resources

High Availability

  • Each component can be tuned for resiliency/performance with more replicas + tunable parameters
  • Careful: just bumping the replica count on everything uniformly can actually hurt performance
  • ArgoCD provides separate HA manifests for both cluster and namespaced modes
  • The standard install has a single replica of each component. Fine for getting started, not for prod. If one dies, that functionality is gone
  • HA manifests = multiple replicas + extra tuning. If one dies, the other replica keeps going in a degraded state

Deploying ArgoCD (YAML Manifests)

The simplest option. One yaml document with everything. Non-HA, multi-tenant.

kind create cluster
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
kubectl get pods -n argocd
  • kind cluster is named kind by default. Change with --name or KIND_CLUSTER_NAME
  • Pods that come up:
    • argocd-application-controller
    • argocd-applicationset-controller
    • argocd-dex-server
    • argocd-notifications-controller
    • argocd-redis
    • argocd-repo-server
    • argocd-server

Accessing the UI

  • Nothing is exposed outside the cluster by default. Options: LoadBalancer service, Ingress, or just port-forward for testing
kubectl port-forward svc/argocd-server -n argocd 8080:443
  • Blocks the terminal, use another one for more commands
  • Browse to https://localhost:8080. Self signed cert so the browser will warn
  • Username: admin
  • Password: stored in the argocd-initial-admin-secret secret
kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d

Deploying ArgoCD (Helm)

  • Advantage over raw yaml: templating. You can enable/disable entire components and tweak properties
helm repo add argo https://argoproj.github.io/argo-helm
helm upgrade -i argo-cd argo/argo-cd -n argocd --create-namespace
  • helm upgrade -i = install if no release exists, upgrade otherwise. Same command for both. helm install only works the first time
  • Helm prints the chart’s NOTES on install, which include how to reach the UI and get the admin password
  • Pod names are prefixed with the release name (argo-cd-...)
  • See all tunable values:
helm show values argo/argo-cd

Cleanup (before switching install methods)

# option 1: nuke the cluster
kind delete cluster
kind create cluster

# option 2: uninstall the manifest install
kubectl delete -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
kubectl delete namespace argocd