Argo CD
Argo CD is a declarative GitOps continuous delivery tool for Kubernetes. It watches a Git repository for desired application state and automatically synchronizes the live cluster to match, providing drift detection and a visual interface for deployment status.
itCloud native tools and technologies | OpenSkills.info
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Don't Panic
Don't Panic — Argo CD
Argo CD is a Kubernetes delivery controller with one persistent question: does the cluster still look like the version of the application described in Git? That is less theatrical than launching a deployment pipeline, but it is much more difficult to ignore at three in the morning. Git supplies the desired version. Kubernetes supplies the unruly evidence. Argo CD compares them until somebody decides what happens next.
The thing it replaces is the familiar arrangement where a build system carries cluster credentials, applies manifests once, and declares the matter closed. Here the build still tests code and makes artifacts. A change to configuration records which artifact and settings belong in an environment. The Application, which joins a source, destination, project, and sync policy, gives Argo CD a bounded piece of that declaration to watch.
The useful distinction is between target state and live state. Target state is what Argo CD renders from the selected repository revision, path, chart, or other supported source. Live state is what it finds in the destination cluster. A sync moves live resources toward target resources; a refresh only recalculates the comparison. The vocabulary is calm. The consequences of confusing the two are notably less calm.
There is also health, which is not another spelling of Synced. An Application can match Git exactly while its Pods fail to become ready. It can be OutOfSync while an existing workload still serves traffic. The course slides map the controller, repository server, and API server if you want the machinery; the cheatsheet keeps the commands, status meanings, hooks, waves, and AppProject controls close at hand.
Automation deserves the same suspicion normally reserved for a robot holding a large pair of scissors. Automated sync applies qualifying target changes. Prune permits deletion when resources vanish from target state. Self-heal corrects live-only drift. Allow-empty permits a target with no resources to remove everything it manages. Each control is separate because its failure mode is separate.
Argo CD also does not perform every task that happens to be near deployment. It does not build images, prove a change safe, replace a secret store, or turn an unsafe database migration into a safe one by arranging it in a charming sequence of sync waves. Read the intro for the full operating boundary, then use the practice reference and exercise to make one Application report, diff, sync, and become healthy in an isolated cluster.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://argo-cd.readthedocs.io/en/stable/
Supports
- Argo CD is a declarative GitOps continuous delivery tool for Kubernetes
- The application controller compares live state with target state from Git and reports OutOfSync differences
- Supported inputs include Kustomize, Helm, Jsonnet, plain YAML or JSON, and config management plugins
- Argo CD supports manual or automated sync, multiple clusters, health assessment, SSO, RBAC, hooks, audit trails, and metrics
- Rollback targets application configurations recorded in Git
- https://argo-cd.readthedocs.io/en/stable/core_concepts/
Supports
- Application, target state, live state, sync status, sync, refresh, and health definitions
- Sync status and health status describe separate aspects of an Application
- https://argo-cd.readthedocs.io/en/stable/operator-manual/health/
Supports
- Argo CD assesses health for standard Kubernetes resource types
- Application health is derived from the health of immediate child resources
- Healthy, Progressing, Degraded, Suspended, Missing, and Unknown describe runtime health rather than sync status
- https://argo-cd.readthedocs.io/en/stable/getting_started/
Supports
- Current official installation and guestbook Application commands
- CLI login, cluster registration, Application creation, status inspection, and manual sync flow
- External cluster registration creates controller credentials whose permissions can be narrowed
- Production installations should pin a release instead of tracking the stable branch
- https://argo-cd.readthedocs.io/en/stable/operator-manual/architecture/
Supports
- API server responsibilities for interfaces, operations, credentials, authentication, RBAC, and webhooks
- Repository server responsibility for source caching and manifest generation
- Application controller responsibility for comparison, OutOfSync detection, corrective action, and hooks
- https://argo-cd.readthedocs.io/en/stable/user-guide/auto_sync/
Supports
- Automated sync behavior and configuration
- Automated pruning is disabled until explicitly enabled
- Allow-empty protects against automatically pruning every target resource
- Self-heal controls automatic reconciliation of live-only drift
- ApplicationSet-managed Applications must change automation through the controlling ApplicationSet
- https://argo-cd.readthedocs.io/en/stable/user-guide/sync-waves/
Supports
- PreSync, Sync, PostSync, SyncFail, and Skip hook behavior
- Sync waves use integer annotations and run from lower to higher values
- Phases provide coarse ordering and waves provide ordering within a phase
- https://argo-cd.readthedocs.io/en/stable/user-guide/projects/
Supports
- AppProjects group Applications for multi-team use
- AppProjects restrict source repositories, destinations, and allowed or denied resource kinds
- AppProjects can define roles and sync windows
- The default project begins with broad permissions and can be restricted
- https://argo-cd.readthedocs.io/en/stable/operator-manual/rbac/
Supports
- Global RBAC and AppProject roles control authorization through Argo CD
- Every authenticated user receives the configured default policy
- Official guidance recommends a minimum-permission authenticated default role
- https://argo-cd.readthedocs.io/en/stable/user-guide/application-set/
Supports
- ApplicationSet generates Applications from a template and generator parameters
- ApplicationSet supports repeated multi-cluster and multitenant application patterns
- Template changes update generated Applications
- https://argo-cd.readthedocs.io/en/stable/operator-manual/applicationset/Generators/
Supports
- List, Cluster, Git, Matrix, Merge, SCM Provider, Pull Request, Cluster Decision Resource, and Plugin generator roles
- Generator parameters are rendered into ApplicationSet template fields
- https://argo-cd.readthedocs.io/en/stable/operator-manual/secret-management/
Supports
- Argo CD recommends populating application secrets in the destination cluster
- Destination-side population reduces Argo CD access to secret values
- Destination-side population decouples secret updates from application sync
- https://argo-cd.readthedocs.io/en/stable/operator-manual/high_availability/
Supports
- Argo CD persists data as Kubernetes objects and uses Redis as a disposable cache
- Official high-availability manifests add replicas and Redis high availability
- Repository server and application controller workloads require workload-specific scaling
- https://argo-cd.readthedocs.io/en/stable/operator-manual/disaster_recovery/
Supports
- The official disaster recovery process exports and imports Argo CD configuration
- Backup and restore must account for the key used to encrypt sensitive exported data
- The documented export contains Argo CD configuration rather than managed application data
- https://argo-cd.readthedocs.io/en/stable/user-guide/commands/argocd_app/
Supports
- The argocd app command groups Application create, diff, get, set, sync, wait, history, and rollback operations
- https://argo-cd.readthedocs.io/en/stable/user-guide/commands/argocd_app_diff/
Supports
- The argocd app diff command compares an Application's live and target state
- https://github.com/argoproj/argo-cd/blob/master/CHANGELOG.md
Supports
- Argo CD v1.5 added Helm 3 support in April 2020
- Argo CD v1.8 was released in December 2020
- Argo CD v2.1 introduced Argo CD Core in August 2021
- https://www.cncf.io/blog/2021/04/07/argo-cd-2-0-released/
Supports
- Argo CD 2.0 was announced in April 2021
- https://www.cncf.io/announcements/2022/12/06/the-cloud-native-computing-foundation-announces-argo-has-graduated/
Supports
- The Argo project entered the CNCF incubator in April 2020 and graduated in December 2022
- The announcement describes Argo CD use across hundreds of applications and tens of clusters
- https://argo-cd.readthedocs.io/en/release-3.0/developer-guide/release-process-and-cadence/
Supports
- The release cadence documents v2.10 through v2.14 releases from February 2024 through February 2025
- https://docs.aws.amazon.com/prescriptive-guidance/latest/eks-gitops-tools/use-cases.html
Supports
- AWS guidance compares Argo CD and Flux as GitOps tools and distinguishes application-centric visual management from lighter-weight multi-tenancy needs
