ArgoCD

How it works

Argo CD is a declarative GitOps continuous delivery tool for Kubernetes and a CNCF project. It runs as a set of controllers and services inside a cluster. You define an Application resource that points at a source (a Git repository path containing plain manifests, a Helm chart or Kustomize overlay) and a destination (a cluster and namespace).

Argo CD continuously compares the desired state in Git with the live state in the cluster. An application is either in sync or out of sync, and its health is reported separately. Syncing applies the manifests so that the cluster matches Git.

Automated sync is not on by default. When you enable it, two options matter:

• prune: allows automated sync to delete resources that no longer exist in Git. By default, automated sync does not delete resources.
• selfHeal: triggers a sync when live state drifts from Git, for example after a manual kubectl edit.

Other features include managing several clusters from one instance, and ApplicationSets, which generate many Applications from a template, for instance one per environment or cluster.

A practical example

An Application with automated sync, pruning and self healing enabled:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: web
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://git.example.com/org/deploy-repo.git
    targetRevision: main
    path: apps/web
  destination:
    server: https://kubernetes.default.svc
    namespace: web
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

The repository URL and path are placeholders for your own repository.

Common mistakes

• Enabling prune without understanding what Git currently defines, which can delete live resources.
• Keeping plain secrets in the Git repository instead of using an encrypted approach such as Sealed Secrets.
• Mixing application source code and deployment manifests in one repository, which makes every code commit trigger deployment noise.
• Allowing people to change the cluster by hand while self heal is off, so drift goes unnoticed.
• Giving every team admin access instead of using Argo CD projects and RBAC.

When to use it and when not to

Argo CD works well when you want Git to be the audited source of truth for cluster state, with easy rollback by reverting a commit. It is more than you need for a single small cluster deployed rarely. It also does not build images or run tests, so pair it with a CI system. Flux is the main alternative.

See our GitOps with Helm, Argo CD and Flux service and the Argo CD technology page.

See also

• GitOps
• Flux GitOps
• Helm Chart