ArgoCD
Topics in this category
App of Apps Applications GitOps Principles Multi-cluster RBAC Sync & Health Sync Waves & Hooks
ArgoCD

Applications

29 question(s)

What is an ArgoCD Application?

Beginner
An Application is a custom resource (CRD) that represents a deployed app in ArgoCD. It declares the source (Git repo, path, revision, or Helm chart), the destination (cluster and namespace), and the sync policy. ArgoCD uses it to fetch manifests, compare to the live state, and keep them in sync.
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: guestbook
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/org/repo
    path: guestbook
    targetRevision: HEAD
  destination:
    server: https://kubernetes.default.svc
    namespace: guestbook
Real-world example Each microservice is represented by an Application CR pointing at its manifests path and target namespace.

Common follow-ups: What are the required fields of an Application? | What is the destination server?

Sync & Health GitOps Principles Applications

What are the source and destination in an Application spec?

Beginner
The source defines where the desired manifests come from: repoURL, path (for plain/Kustomize/Helm-in-repo), and targetRevision (branch, tag, or commit). The destination defines where to deploy: the cluster (server URL or name) and the target namespace. Together they map 'what to deploy' to 'where to deploy it'.
source:
  repoURL: https://github.com/org/repo
  path: apps/web
  targetRevision: main
destination:
  server: https://kubernetes.default.svc
  namespace: web
Real-world example An Application pulls from the main branch's apps/web path and deploys into the web namespace of the local cluster.

Common follow-ups: What can targetRevision be? | How do you target a remote cluster?

Multi-cluster GitOps Principles Applications

What manifest formats/tools does ArgoCD support for an Application source?

Beginner
ArgoCD natively supports plain Kubernetes YAML/JSON, Helm charts (from Git or a Helm repo), Kustomize overlays, and Jsonnet. It can also use config management plugins for other tools. It auto-detects the tool from the source (e.g., a Chart.yaml or kustomization.yaml) or you specify it explicitly.
source:
  repoURL: https://charts.example.com
  chart: nginx
  targetRevision: 15.1.0
  helm:
    values: |
      replicaCount: 2
Real-world example One team uses Helm charts, another Kustomize overlays; ArgoCD handles both through the same Application abstraction.

Common follow-ups: How does ArgoCD detect the tool? | What is a config management plugin?

Sync & Health GitOps Principles Applications

How do you deploy a Helm chart with ArgoCD and override values?

Intermediate
Point the source at a Helm repo (chart + targetRevision) or a Git path containing the chart, then supply overrides via helm.values (inline), helm.valueFiles, or helm.parameters. ArgoCD renders the chart with `helm template` (it doesn't use Tiller) and applies the resulting manifests, tracking them like any other resource.
source:
  repoURL: https://github.com/org/charts
  path: web
  helm:
    valueFiles: [values-prod.yaml]
    parameters:
      - name: image.tag
        value: v1.4.2
Real-world example Production overrides the image tag and replica count via a values-prod.yaml, while staging uses values-staging.yaml.

Common follow-ups: Does ArgoCD use Tiller? | valueFiles vs parameters vs inline values?

Sync & Health Multi-cluster Applications

How do you use Kustomize with an ArgoCD Application?

Intermediate
Point the source path at a directory containing a kustomization.yaml; ArgoCD runs `kustomize build` to render manifests. You can set images, name prefixes/suffixes, and common labels via the kustomize section, and structure base + overlays per environment so each Application references the right overlay.
source:
  path: overlays/production
  kustomize:
    images:
      - myapp=myrepo/myapp:v2.0
    namePrefix: prod-
Real-world example The production Application points at overlays/production, which patches the shared base with prod-specific replicas and image tags.

Common follow-ups: What is a base vs overlay? | How do you override the image with Kustomize?

GitOps Principles Multi-cluster Applications

What is the difference between manual and automated sync policy?

Intermediate
With manual sync, ArgoCD detects differences and marks the app OutOfSync but waits for a user (or API/CI) to trigger the sync. With automated sync, ArgoCD applies changes automatically when Git changes or drift is detected. Automated can add prune and selfHeal for full continuous reconciliation.
syncPolicy:
  automated:
    prune: true
    selfHeal: true
Real-world example Dev uses automated sync for fast iteration, while production uses manual sync so a human approves each promotion.

Common follow-ups: What do prune and selfHeal add? | Why might production use manual sync?

Sync & Health GitOps Principles Applications

What does the prune option do in a sync policy?

Intermediate
Prune deletes live resources that no longer exist in Git, keeping the cluster exactly matching the desired state. Without prune, removing a manifest from Git leaves the resource running (orphaned). Prune is powerful but should be used carefully; resources can be protected from pruning with annotations.
syncPolicy:
  automated:
    prune: true
# Protect a resource from pruning:
metadata:
  annotations:
    argocd.argoproj.io/sync-options: Prune=false
Real-world example After a service is deleted from Git, prune removes its Deployment and Service from the cluster automatically.

Common follow-ups: What happens without prune? | How do you protect a resource from pruning?

Sync & Health Sync Waves & Hooks Applications

What is selfHeal and when should you use it?

Intermediate
selfHeal makes ArgoCD automatically revert live changes that deviate from Git, even if the change wasn't via Git (e.g., a manual kubectl edit). It enforces Git as the source of truth and prevents drift, but can fight tools that legitimately mutate resources, so it's used where Git should fully own the state.
syncPolicy:
  automated:
    selfHeal: true
Real-world example A manual replica change is reverted within a reconciliation cycle because selfHeal restores the Git-defined value.

Common follow-ups: When can selfHeal cause conflicts? | How does it relate to drift?

GitOps Principles Sync & Health Applications

How do you pin an Application to a specific Git revision or tag?

Intermediate
Set targetRevision to a branch, tag, or commit SHA. Using a tag or SHA pins to an immutable revision for reproducible, controlled deployments (common in production), while a branch like main tracks the latest. Promotion then means updating targetRevision (often via PR) to the new tag.
source:
  targetRevision: v1.4.2   # tag or commit SHA for immutability
Real-world example Production pins to tag v1.4.2 so it never changes until a reviewed PR bumps the tag, unlike staging which tracks main.

Common follow-ups: Why pin to a tag in production? | How is promotion done with pinned revisions?

GitOps Principles Sync & Health Applications

What are ApplicationSets and what problem do they solve?

Advanced
ApplicationSet is a controller that templates and generates many Applications from a single spec using generators (list, cluster, Git directory/file, matrix, pull request, SCM). It removes the toil of hand-writing an Application per environment/cluster/team and keeps a fleet of apps consistent and automatically updated as inputs change.
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
spec:
  generators:
    - clusters: {}
  template:
    metadata: { name: '{{name}}-guestbook' }
    spec:
      destination:
        server: '{{server}}'
        namespace: guestbook
Real-world example One ApplicationSet with a cluster generator deploys the same app to all 20 registered clusters automatically.

Common follow-ups: What generators are available? | How does ApplicationSet differ from App of Apps?

Multi-cluster App of Apps Applications