🐙 What is ArgoCD?
›GitOps — The Core Concept
| Traditional CD (Jenkins push) | GitOps (ArgoCD pull) | |
|---|---|---|
| How it works | Jenkins runs kubectl apply when triggered | ArgoCD polls Git, applies when changed |
| Credentials | Jenkins has cluster credentials | Only ArgoCD has cluster credentials |
| Audit trail | Jenkins build log (can be deleted) | Git history (permanent, immutable) |
| Rollback | Re-run old Jenkins build | git revert — ArgoCD auto-applies |
| Drift detection | None | Auto-detects and can auto-revert manual changes |
| Access control | Anyone with Jenkins access can deploy | Deployment = PR approval in Git |
📄 Application Object
›The ArgoCD Application is the core object
One Application = one service + one environment. It defines: WHERE to get the config (Git repo, path, branch), WHERE to deploy (cluster + namespace), and HOW to sync (automatic or manual, with or without self-healing).
🏗️ App of Apps Pattern
›Managing 15+ services
Instead of creating 15 Application objects manually, define them as YAML files in Git. A parent Application watches that directory. Add a service = add one YAML file. Bootstrap an environment = sync one parent app.
⏳ Sync Waves & Hooks
›Controlling deployment order
Wave 1 (database) must be ready before Wave 2 (app). PreSync hooks run database migrations. PostSync hooks run smoke tests. SyncFail hooks send alerts.
🔐 RBAC & Projects
›Multi-team isolation
Projects in ArgoCD isolate teams. Team A cannot see or sync Team B's applications. Sync windows prevent production deployments outside business hours.
🔍 Troubleshooting
›🔁 ApplicationSets — Deploy to Many Clusters at Once
›The problem ApplicationSets solve
Without ApplicationSets: you create 10 ArgoCD Applications manually — one per environment or cluster. Each one is nearly identical. When you need to add a new environment, you create another Application manually. With ApplicationSets: define a template once, and a Generator automatically creates Applications for every environment, cluster, or Git directory.
Three key generators
| Generator | What it does | Use case |
|---|---|---|
| List Generator | Define a list of clusters/environments explicitly | Fixed number of known environments |
| Git Generator (Directories) | Create one Application per directory in a Git repo | Each microservice in its own folder |
| Cluster Generator | Create one Application per registered cluster | Same app deployed to all clusters |
# ApplicationSet — deploy same app to dev, staging, prod
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
name: payment-service-appset
namespace: argocd
spec:
generators:
- list:
elements:
- cluster: dev
url: https://dev-cluster.example.com
namespace: payment-dev
values:
replicas: "1"
imageTag: "latest"
- cluster: staging
url: https://staging-cluster.example.com
namespace: payment-staging
values:
replicas: "2"
imageTag: "stable"
- cluster: production
url: https://prod-cluster.example.com
namespace: payment-prod
values:
replicas: "5"
imageTag: "v2.1.0"
template:
metadata:
name: "payment-service-{{cluster}}"
spec:
project: payment-team
source:
repoURL: https://github.com/company/payment-service
targetRevision: HEAD
path: helm/payment-service
helm:
values: |
replicaCount: {{values.replicas}}
image:
tag: {{values.imageTag}}
destination:
server: "{{url}}"
namespace: "{{namespace}}"
syncPolicy:
automated:
prune: true
selfHeal: true
🔔 ArgoCD Notifications and Webhooks
›Get alerted when deployments succeed, fail, or drift
ArgoCD Notifications sends alerts to Slack, Teams, email, PagerDuty, and more when Application state changes. Install via: kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj-labs/argocd-notifications/stable/manifests/install.yaml
Common notification triggers
| Trigger | When it fires |
|---|---|
on-sync-succeeded | Deployment completed successfully |
on-sync-failed | Sync attempt failed |
on-health-degraded | App health became Degraded (pods crashing) |
on-deployed | New version successfully deployed |
on-sync-status-unknown | ArgoCD cannot determine sync status |
Annotation to enable notifications on an Application
metadata:
annotations:
notifications.argoproj.io/subscribe.on-sync-succeeded.slack: deployments
notifications.argoproj.io/subscribe.on-sync-failed.slack: alerts
notifications.argoproj.io/subscribe.on-health-degraded.slack: alerts
Git webhook for instant sync (not polling)
By default ArgoCD polls Git every 3 minutes. For instant sync on push: configure a webhook in GitHub/GitLab pointing to https://argocd.example.com/api/webhook. ArgoCD receives the push event and syncs immediately — sub-second response to Git changes.
🌐 Multi-Cluster Management with ArgoCD
›One ArgoCD managing many clusters
ArgoCD runs in one cluster (the management cluster) but can deploy to many target clusters. This is the standard enterprise pattern — one ArgoCD instance manages dev, staging, production, and regional clusters.
Register a cluster
# Login to ArgoCD argocd login argocd.example.com # Add a new cluster (must have kubeconfig context set up) argocd cluster add production-cluster-context --name production # List registered clusters argocd cluster list
Hub-and-spoke architecture
└── ArgoCD (the hub)
├── deploys to → Dev Cluster (spoke)
├── deploys to → Staging Cluster (spoke)
├── deploys to → Production EU Cluster (spoke)
└── deploys to → Production US Cluster (spoke)
Security for multi-cluster
ArgoCD creates a ServiceAccount in each target cluster with the minimum permissions needed to deploy the resources defined in Applications. The credentials are stored as Kubernetes Secrets in the ArgoCD namespace. Use ArgoCD Projects to restrict which Applications can deploy to which clusters — Production project can only deploy to production cluster, accessed only by the release team.