We've covered GitOps principles, Tekton for CI, and how to build a complete build pipeline. Now it's time for the other half of the equation: continuous delivery. This is where Argo CD comes in.
Argo CD is the most widely adopted GitOps CD tool in the Kubernetes ecosystem. Let's break down its core concepts and architecture.
1. Core Concepts
Before diving into architecture, you need to speak Argo CD's language. Here are the key terms:
| Concept | Definition |
|---|---|
| Application | A CRD that represents a group of Kubernetes resources defined in a source repository. The fundamental unit Argo CD manages. |
| Application Source Type | The type of source repository. Argo CD currently supports Git and Helm. |
| Target State | The desired state of the application as declared in the source repository (Git/Helm). |
| Live State | The actual running state of the application in the target cluster right now. |
| Sync Status | Whether Live State matches Target State. Synced = in sync. OutOfSync = drift detected. |
| Sync | The process of applying changes to make the cluster match the Target State — essentially, deploying to Kubernetes. |
| Repository | A configured source repository connection, including URL, type, and access credentials. |
| Credentials | Authentication details used to access a source repository. |
| Clusters | The Kubernetes clusters that Argo CD is configured to connect to and manage. |
The most important mental model: Target State lives in Git. Live State lives in the cluster. Argo CD's job is to keep them in sync.
2. What Argo CD Does — Feature Overview
Argo CD is a Kubernetes Operator at its core. It continuously watches application state and compares it against the declared state in Git. When drift is detected, it visualizes the diff in the UI and offers manual or automatic reconciliation.
Here's the full feature set:
Deployment & Multi-Cluster:
- ✅ Automated application deployment to target clusters
- ✅ Multi-cluster application management and deployment
- ✅ Supports multiple config/templating tools: Kustomize, Helm, Ksonnet, plain YAML
Security & Access Control:
- ✅ SSO integration: OIDC, OAuth2, LDAP, SAML 2.0, GitHub, GitLab
- ✅ Multi-tenancy with RBAC (Role-Based Access Control)
- ✅ Access tokens for remote access and CI/CD integration
Observability & Operations:
- ✅ Real-time application health status analysis
- ✅ Visual diff detection between live and target state
- ✅ Web UI with live application state dashboard
- ✅ Audit trail for application events and API calls
- ✅ Prometheus metrics endpoint
Delivery Workflows:
- ✅ Rollback to any historical Git revision
- ✅ Manual or automated sync policies
- ✅ PreSync / Sync / PostSync hooks for advanced release strategies (blue-green, canary)
- ✅ Webhook integration: GitHub, GitLab, BitBucket
- ✅ CLI for third-party CI/CD system integration
- ✅ Parameter overrides for Helm/Ksonnet applications
3. Architecture: Three Core Components
Argo CD's architecture is built around three components. Each has a distinct responsibility.
┌─────────────────────────────────────────────────────────────┐
│ Argo CD │
│ │
│ ┌──────────────┐ ┌──────────────────┐ ┌──────────────┐ │
│ │ API Server │ │Repository Server │ │ App │ │
│ │ (gRPC/REST) │ │ (Git cache) │ │ Controller │ │
│ └──────┬───────┘ └────────┬─────────┘ └──────┬───────┘ │
│ │ │ │ │
└─────────┼───────────────────┼────────────────────┼──────────┘
│ │ │
Web UI / CLI Git Repo K8s Cluster
External CI/CD (manifests) (live state)
3.1 API Server
The API Server is a gRPC/REST API layer — the single entry point for all external interactions with Argo CD.
Consumers:
- Argo CD Web UI
- Argo CD CLI (
argocd) - External CI/CD systems (e.g. Tekton, Jenkins)
Responsibilities:
- Application management and status reporting
- Executing application operations: sync, rollback, refresh
- Managing repository and cluster credentials (stored as Kubernetes Secrets)
- External identity provider authentication and delegation
- Enforcing RBAC policies
- Receiving and forwarding Git webhook events
3.2 Repository Server
The Repository Server is an internal service responsible for one thing: generating Kubernetes manifests from source repositories.
It maintains a local cache of pulled Git content to avoid redundant fetches, and generates manifests based on four inputs:
| Input | Example |
|---|---|
| Repository URL | https://github.com/org/app-configs.git |
| Revision |
main, a commit SHA, or a tag |
| Application path |
examples/demo (subdirectory) |
| Template parameters | Helm values.yaml overrides |
The Repository Server supports all major templating tools — Helm, Kustomize, Ksonnet, Jsonnet, and plain YAML — and returns rendered Kubernetes manifests to the Application Controller.
3.3 Application Controller
The Application Controller is the heart of Argo CD. It is a standard Kubernetes CRD controller that runs a continuous reconciliation loop:
┌─────────────────────────────────────────────────┐
│ Reconciliation Loop │
│ │
│ Fetch Target State ──► Fetch Live State │
│ ↓ ↓ │
│ Git Repo K8s Cluster │
│ └──────── Compare ────┘ │
│ ↓ │
│ Diff detected? │
│ ├── No → Status: Synced ✅ │
│ └── Yes → Status: OutOfSync ⚠️ │
│ ↓ │
│ Sync policy = Auto? │
│ ├── Yes → Auto-apply changes │
│ └── No → Notify, wait for manual │
└─────────────────────────────────────────────────┘
Key behaviors:
- Continuously monitors both Git (target state) and the cluster (live state)
- Detects drift in real time — even from manual
kubectlchanges - Applies changes automatically or waits for manual approval, depending on sync policy
- Drives the entire GitOps feedback loop
4. How It All Works Together
Here's the end-to-end flow when a developer pushes a config change to Git:
1. Developer pushes updated manifest to Git
↓
2. Git webhook fires → API Server receives event
↓
3. Repository Server fetches updated manifests, renders them
↓
4. Application Controller compares rendered manifests vs live cluster state
↓
5. Diff detected → Status set to OutOfSync
↓
6a. Auto-sync enabled → Application Controller applies changes to cluster
6b. Manual sync → Operator reviews diff in UI, approves sync
↓
7. Cluster updated → Status returns to Synced ✅
↓
8. Application Controller continues monitoring for future drift
This loop runs continuously. Any deviation from Git — whether from a bad deployment, a manual change, or a node restart — is detected and surfaced immediately.
5. Argo CD vs Traditional Push-Based CD
| Dimension | Traditional Push CD | Argo CD (Pull/GitOps) |
|---|---|---|
| Trigger | CI pipeline pushes to cluster | Agent polls Git continuously |
| Credentials | Stored in CI (external) | In-cluster only |
| Drift detection | ❌ None | ✅ Continuous |
| Rollback | Manual re-deploy | Git revert → auto-sync |
| Audit trail | CI logs | Git history + Argo CD events |
| Multi-cluster | Complex, credential sprawl | Native, centralized |
6. Summary
Argo CD's architecture is elegantly simple: three focused components, each doing one thing well.
| Component | Role |
|---|---|
| API Server | External interface — UI, CLI, webhooks, RBAC |
| Repository Server | Manifest generation and Git cache |
| Application Controller | Continuous reconciliation — the GitOps engine |
Together, they implement the complete GitOps feedback loop: declare in Git → detect drift → reconcile automatically.
In the next article, we'll get hands-on with Argo CD installation and configuration — connecting it to a Git repository, registering a cluster, and deploying your first Application.
Next in this series: Argo CD Installation & Configuration: Getting Started in Practice (Part 8)
Follow the series — we're building toward a complete GitOps pipeline: Tekton for CI, Argo CD for CD, all wired together.
Top comments (0)