Argo CD

TL;DR: Argo CD continuously compares the desired state stored in Git with the live state in Kubernetes and synchronizes them.

Before diving into Argo CD, it is essential to understand Argo as a whole. Argo CD is not a standalone tool operating in isolation; it is part of a broader, Kubernetes-native suite designed for application delivery and workflow automation.

1. What is Argo?

The Argo Project is a set of open-source, Kubernetes-native tools for application delivery, workflow orchestration, and event-driven automation.

Instead of building external, imperative automation systems around Kubernetes, Argo extends Kubernetes directly using Custom Resource Definitions (CRDs) and custom controllers.

Core Philosophy

Define what you want as native Kubernetes declarative resources, then let internal controllers continuously reconcile toward that desired state.

Argo consists of four distinct, independent projects—each tailored to a specific operational challenge.

2. The Four Pillars of Argo

                             [ The Argo Project ]
                                      |
         +-----------------+----------+----------+-----------------+
         |                 |                     |                 |
         v                 v                     v                 v
  [ Argo Workflows ] [ Argo Events ]     [ Argo Rollouts ]    [ Argo CD ]
  Workflow Engine    Event Automation    Progressive Delivery  GitOps Delivery

These projects can operate independently or collaborate seamlessly. For example, Argo CD can deploy an Argo Workflow definition, while Argo Rollouts manages how an application is progressively released across production pods.

3. Deep Dive into Argo CD

Argo CD solves a fundamentally different problem from workflow engines:

• Argo Workflows executes tasks (ephemeral, step-by-step logic).
• Argo CD manages continuous state (permanent, declarative infrastructure).

The core principle behind Argo CD is GitOps: Git serves as the single source of truth for the desired state of an application.

Reconciliation Mechanics

[ Git Repository ]                            [ Kubernetes Cluster ]
 (Desired State)                                 (Actual Live State)
        |                                                 |
        +------------------> [ Argo CD ] <----------------+
                                   |
                             Compare State
                                   |
                        +----------+----------+
                        |                     |
                     [ Match ]             [ Drift ]
                        |                     |
                    Do Nothing           Synchronize

1. Continuous Observation: Argo CD continuously monitors both the Git repository and the live Kubernetes cluster.
2. Drift Detection: If a human manually modifies a resource via kubectl, or if a new commit is pushed to Git, Argo CD detects the divergence (OutOfSync).
3. Automated Reconciliation: Depending on its policy configuration, Argo CD automatically applies the Git configuration back to the cluster or alerts operators of the drift.

4. How Argo CD Integrates into Kubernetes

Argo CD runs natively inside your Kubernetes cluster as a set of controllers and interacts directly with the Kubernetes API Server. It does not replace the control plane; it extends it.

The Application Custom Resource Definition (CRD)

Argo CD uses its own CRD—the Application resource—to represent a deployment target.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-application
  namespace: argocd
spec:
  project: default
  source:
    repoURL: 'https://github.com/example/my-app-manifests.git'
    targetRevision: HEAD
    path: overlays/production
  destination:
    server: 'https://kubernetes.default.svc'
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

The Application manifest instructs Argo CD where the desired YAML manifests are located (Git URL/Path) and where they should be applied (Cluster API/Namespace).

5. Deployment Models: Without Argo CD vs. With Argo CD

Traditional Push Model (Without Argo CD)

A traditional CI/CD runner (e.g., Jenkins, GitHub Actions) executes imperative commands to push changes into Kubernetes.

[ Developer ] ---> [ Git Repo ] ---> [ CI/CD Pipeline ] --- (kubectl apply) ---> [ k8s API Server ]

• Security Risk: The CI system requires administrative kubeconfig credentials stored externally.
• Lack of Visibility: The CI pipeline runs once and exits; it cannot detect subsequent state drift or unauthorized cluster edits.

GitOps Pull Model (With Argo CD)

Responsibility is strictly separated: CI handles building/testing, while Argo CD handles state reconciliation.

[ Developer ] ---> [ Git Repo ] ---> [ CI/CD Pipeline ] ---> Updates Git Tag
                                                                 |
                                                                 v
[ k8s Cluster ] <--- (Continuous Sync) <--- [ Argo CD ] <--- [ Git Repo ]

Process Comparison

Traditional Push CI/CD:
Code  --->  Build  --->  Test  --->  Deploy  --->  Kubernetes (Imperative Push)

GitOps Model (Argo CD):
Code  --->  Build  --->  Test  --->  Commit to Git  --->  Argo CD Syncs  --->  Kubernetes

The key advantage is not merely replacing kubectl. The fundamental shift is moving from a one-time pipeline trigger to a continuous reconciliation engine.

6. How Argo Projects Work Together

Understanding how Argo tools collaborate highlights the modularity of the ecosystem. Consider an Argo Workflow manifest stored inside a Git repository:

[ Git Repository ]
        |
        | (Workflow YAML)
        v
    [ Argo CD ]
        |
        | (Deploys Manifest)
        v
[ k8s API Server ]
        |
        | (Instantiates CRD)
        v
[ Argo Workflow Controller ]
        |
        | (Executes Steps)
        v
   [ Step Pods ]

Division of Responsibilities

• Git: Stores the canonical specification of the Workflow.
• Argo CD: Ensures the Workflow manifest exists in the cluster.
• Kubernetes: Maintains the active custom objects in etcd.
• Argo Workflows Controller: Executes the pod orchestration logic defined by the workflow.

7. The Core Mental Model

Argo CD can be distilled into a simple equation:

$$ ext{Git (Desired State)} \quad \Longleftrightarrow \quad ext{Argo CD (Reconciliation)} \quad \Longleftrightarrow \quad ext{Kubernetes (Live State)}$$

Instead of executing a deployment script once and assuming success, Argo CD constantly asks:

“Does the live cluster state match what Git specifies?”

• If YES: Do nothing.
• If NO: Identify the drift and synchronize the cluster.

Back to Certified Cloud Native Platform Engineering Associate Preparation