Argo CD: CAPA practice questions

Argo CD is a declarative GitOps delivery tool for Kubernetes: the desired state of an application lives in Git, and Argo CD keeps the cluster in line with it. Three components do the core work. The API server is a gRPC and REST server used by the web UI, the CLI and CI systems; it manages applications and reports their status, triggers operations such as sync and rollback, holds repository and cluster credentials, authenticates users, enforces RBAC and receives Git webhook events. The repository server keeps a local cache of the Git repositories and, given a repository URL, a revision, a path and template settings, generates the Kubernetes manifests. The application controller continuously compares the live state of each application with the target state from the repository, detects when it is OutOfSync, optionally corrects it, and runs hooks for the sync lifecycle.

An Application resource names a project, a source and a destination. The source has a repoURL, a targetRevision and a path, or a chart for a Helm repository; the destination has either a server or a name for the cluster, not both, plus a namespace. Applications, AppProjects and the settings objects must be created in the Argo CD namespace, argocd by default. An AppProject groups applications and restricts which repositories, destination clusters and namespaces they may use. General settings are kept in the argocd-cm ConfigMap, RBAC in argocd-rbac-cm and secrets such as the signing key in argocd-secret. Repositories and clusters are registered declaratively as Secrets labelled argocd.argoproj.io/secret-type: repository or cluster. Deleting an Application only removes the resources it manages when it carries the resources-finalizer.argocd.argoproj.io finalizer.

Argo CD detects the tool for a source path itself: a Chart.yaml means Helm, a kustomization file means Kustomize, and anything else is treated as a plain directory of manifests, unless the Application sets the tool explicitly.

Automated sync is enabled with spec.syncPolicy.automated or argocd app set with --sync-policy automated. It only syncs when the application is OutOfSync, and it is conservative by default: prune is off, so resources removed from Git stay in the cluster, and selfHeal is off, so manual changes in the cluster do not trigger a sync. allowEmpty permits pruning down to no resources at all. Git is polled every 120 seconds with up to 60 seconds of jitter, and an application with automated sync cannot be rolled back.

Sync options refine how resources are applied, either for the whole application under syncPolicy.syncOptions or per resource with the argocd.argoproj.io/sync-options annotation. Examples are CreateNamespace=true, PruneLast=true, ApplyOutOfSyncOnly=true, ServerSideApply=true, Replace=true, which can be destructive, Prune=false or Prune=confirm, and FailOnSharedResource=true. When a field is changed by something other than Git, ignoreDifferences excludes it from the comparison using jsonPointers, jqPathExpressions or managedFieldsManagers, and RespectIgnoreDifferences=true extends that to the sync itself.

Ordering uses phases and waves. The argocd.argoproj.io/hook annotation places a resource in PreSync, Sync, PostSync, SyncFail or PostDelete, and argocd.argoproj.io/sync-wave orders resources from the lowest number up, with 0 as the default. For many clusters or repositories, the ApplicationSet controller, bundled since Argo CD 2.3, renders an Application per parameter set from generators such as List, Cluster, Git and Matrix.