Module 01

Introduction to ArgoCD

From Git push to production deploy -- the GitOps way

Use arrow keys or click sides to navigate

The Story Begins

The Deployment Problem

It is Friday afternoon. A developer pushes a hotfix to Git. Someone manually runs kubectl apply. The staging cluster has one version, production has another, and nobody is sure which YAML was actually applied. Sound familiar?

This is the world before GitOps -- and it is a world of uncertainty.

Core Concept

What is GitOps?

GitOps is an operational framework where Git is the single source of truth for your infrastructure and application deployments.

In simple terms: Whatever is in Git is what runs in your cluster. If it is not in Git, it does not exist.

Coined by Weaveworks in 2017, GitOps applies DevOps best practices to infrastructure automation.

The Four Principles of GitOps

1. Declarative

The entire system is described declaratively -- not scripts, not imperative commands, but desired state.

2. Versioned & Immutable

The desired state is stored in Git, giving you a full audit trail and the ability to roll back.

3. Pulled Automatically

Agents pull the desired state from Git and apply it -- no CI pipeline pushing credentials into the cluster.

4. Continuously Reconciled

Agents continuously compare actual state vs desired state and correct any drift automatically.

Why GitOps?

Push vs Pull Model

Push-based (Traditional CI/CD)

  • CI pipeline runs kubectl apply
  • Cluster credentials stored in CI
  • No drift detection
  • Fire-and-forget

Pull-based (GitOps)

  • Agent inside cluster watches Git
  • No credentials leave the cluster
  • Continuous drift detection
  • Self-healing reconciliation

ArgoCD is a pull-based GitOps tool that lives inside your Kubernetes cluster.

Quiz Time

Check Your Understanding

1. What is the single source of truth in a GitOps workflow?

Correct! In GitOps, the Git repository is the single source of truth. Whatever is declared in Git is the desired state of the system.

2. Which deployment model does ArgoCD use?

Correct! ArgoCD uses a pull-based model. An agent running inside the cluster watches the Git repository and pulls changes, meaning cluster credentials never leave the cluster.

3. Which is NOT a core GitOps principle?

Correct! GitOps requires a declarative approach, not imperative scripts. The system must be described as desired state, not as a sequence of commands.
The Hero Arrives

What is ArgoCD?

ArgoCD is a declarative, GitOps continuous delivery tool for Kubernetes.

Think of ArgoCD as a guardian that sits inside your cluster, constantly watching your Git repo and ensuring your cluster matches what is declared there. If someone manually changes something in the cluster, ArgoCD notices and can fix it automatically.

How ArgoCD Works

Git Repository
→
ArgoCD (in-cluster)
→
Kubernetes Cluster

1. ArgoCD watches your Git repo for changes
2. It compares desired state (Git) vs live state (cluster)
3. It visualizes differences and can sync automatically

The reconciliation loop runs every 3 minutes by default (configurable).

ArgoCD Architecture

API Server
Repo Server
Application Controller
Redis (Cache)
Dex (SSO)
Notification Controller

All components run as pods inside the argocd namespace in your cluster.

Component: API Server

The API Server is the front door to ArgoCD -- everything goes through it.

Think of the API Server as the receptionist -- it greets every request, checks credentials, and routes it to the right place.

Component: Repo Server

The Repo Server is the translator -- it turns your manifests into Kubernetes-ready YAML.

If you use Helm charts, the Repo Server runs helm template internally. For Kustomize, it runs kustomize build.

Component: Application Controller

The Application Controller is the brain of ArgoCD -- it does the actual reconciliation.

The controller is a Kubernetes controller itself -- it watches Application CRDs and reconciles them, just like a Deployment controller reconciles pods.

Supporting Components

Redis

In-memory cache used by ArgoCD to store:

  • Application state cache
  • Git repository metadata
  • Cluster info cache

Reduces load on the Kubernetes API and Git servers. Loss of Redis means temporary slowness, not data loss.

Dex (Optional)

OpenID Connect (OIDC) provider for SSO:

  • Integrates with Azure AD, GitHub, LDAP
  • Federated authentication
  • Maps external identities to ArgoCD RBAC

Optional -- you can use ArgoCD's built-in authentication or configure OIDC directly.

Quiz Time

Architecture Check

1. Which ArgoCD component generates Kubernetes manifests from Helm charts?

Correct! The Repo Server clones Git repos and generates Kubernetes manifests from Helm, Kustomize, Jsonnet, or plain YAML.

2. What is the primary role of the Application Controller?

Correct! The Application Controller continuously compares the live cluster state against the desired state from Git and performs sync operations to reconcile any drift.

3. What happens if the Redis pod in ArgoCD goes down?

Correct! Redis is used as a cache. If it goes down, ArgoCD will be slower because it loses cached data, but it will continue to function. No application data is lost.
Hands-On

Installing ArgoCD on AKS

Let us get ArgoCD running on your Azure Kubernetes Service cluster.

# Create the argocd namespace kubectl create namespace argocd # Install ArgoCD using the official manifests kubectl apply -n argocd -f \ https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml # Verify all pods are running kubectl get pods -n argocd

This installs the HA (High Availability) version with all core components. For production, consider the HA manifests with multiple replicas.

Accessing the ArgoCD UI

# Option 1: Port forward (development) kubectl port-forward svc/argocd-server -n argocd 8080:443 # Option 2: LoadBalancer (AKS) kubectl patch svc argocd-server -n argocd \ -p '{"spec": {"type": "LoadBalancer"}}' # Get the initial admin password kubectl -n argocd get secret argocd-initial-admin-secret \ -o jsonpath="{.data.password}" | base64 -d

Security tip: Change the default password immediately and consider setting up SSO with Azure AD. Delete the argocd-initial-admin-secret after changing the password.

Installing the ArgoCD CLI

# macOS brew install argocd # Linux curl -sSL -o argocd-linux-amd64 \ https://github.com/argoproj/argo-cd/releases/latest/download/argocd-linux-amd64 chmod +x argocd-linux-amd64 sudo mv argocd-linux-amd64 /usr/local/bin/argocd # Login to ArgoCD argocd login localhost:8080 # Change default password argocd account update-password

The Application CRD

In ArgoCD, everything revolves around the Application custom resource.

An ArgoCD Application is a Kubernetes custom resource that defines: where to find manifests (source), and where to deploy them (destination).

Source

  • Git repository URL
  • Branch, tag, or commit
  • Path within the repo
  • Helm values, Kustomize overlays

Destination

  • Kubernetes cluster URL
  • Target namespace
  • Can target remote clusters

Your First Application

apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: my-first-app namespace: argocd spec: project: default source: repoURL: https://github.com/your-org/k8s-manifests.git targetRevision: main path: apps/my-app destination: server: https://kubernetes.default.svc namespace: my-app syncPolicy: automated: prune: true selfHeal: true

Creating an App via CLI

# Create an application using the CLI argocd app create my-first-app \ --repo https://github.com/your-org/k8s-manifests.git \ --path apps/my-app \ --dest-server https://kubernetes.default.svc \ --dest-namespace my-app \ --sync-policy automated \ --auto-prune \ --self-heal # Check application status argocd app get my-first-app # Manually trigger a sync argocd app sync my-first-app

The ArgoCD Dashboard

Applications List

Overview of all apps with sync and health status

Resource Tree

Visual graph of all K8s resources in the app

Diff View

Side-by-side comparison of desired vs live state

The UI gives you real-time visibility into your deployments -- no more guessing what is running where.

Sync Status

Sync status tells you whether the live cluster state matches the desired state in Git.

Synced

The live state matches the desired state in Git. Everything is as it should be.

OutOfSync

The live state differs from Git. Someone may have made a manual change, or a new commit was pushed.

Key insight: "OutOfSync" is not always bad -- it might just mean a new commit was pushed and ArgoCD has not synced yet. With auto-sync enabled, it will be resolved automatically.

Health Status

Health status tells you if the application resources are actually working correctly.

Quiz Time

Application Lifecycle

1. An ArgoCD Application resource defines which two key things?

Correct! An ArgoCD Application CRD defines a source (Git repo, path, revision) and a destination (cluster URL and namespace).

2. What does "OutOfSync" status mean?

Correct! OutOfSync means the live state in the cluster does not match what is declared in Git. This could be due to manual changes in the cluster or new commits in Git.

3. Which health status indicates a pod is in CrashLoopBackOff?

Correct! Degraded indicates something is wrong with the resource. A pod in CrashLoopBackOff would cause the application's health to show as Degraded.

Application Lifecycle

1

Create

Define the Application resource via YAML, CLI, or the UI

2

Detect

ArgoCD clones the repo, generates manifests, and compares with live state

3

Sync

Apply the desired state to the cluster (manual or automatic)

4

Monitor

Continuously check health and sync status

5

Reconcile

Detect and correct drift on every reconciliation loop

The Reconciliation Loop

ArgoCD continuously runs this loop:

Fetch from Git
→
Generate Manifests
→
Compare with Live
→
Report Status

Default polling interval: 3 minutes
Can be triggered instantly via webhooks from GitHub/GitLab/Bitbucket

Faster Syncs with Webhooks

Instead of waiting for the 3-minute polling cycle, configure Git webhooks for instant detection.

# In your Git provider, add a webhook pointing to: # https://argocd.yourcompany.com/api/webhook # ArgoCD supports webhooks from: # - GitHub # - GitLab # - Bitbucket Server / Cloud # - Gogs # When a push event is received, ArgoCD immediately # refreshes all applications that use that repository.

Best practice: Always configure webhooks in production. The 3-minute polling is a safety net, not the primary detection mechanism.

Real-World Scenario

A Day with ArgoCD

Imagine you just pushed a change to Git -- you updated the image tag of your API service from v1.2.3 to v1.2.4. Within seconds, a webhook notifies ArgoCD. The dashboard shows "OutOfSync" in yellow. If auto-sync is enabled, ArgoCD applies the change automatically. Within minutes, your new version is rolling out. If the health check fails, the dashboard turns red immediately. You can see exactly what changed, who pushed the commit, and roll back with a single click. This is the power of GitOps.

Essential CLI Commands

# List all applications argocd app list # Get detailed app info argocd app get my-app # Sync an application argocd app sync my-app # View app history argocd app history my-app # Rollback to a previous sync argocd app rollback my-app 2 # Delete an application (keeps resources by default) argocd app delete my-app # Delete app AND its resources argocd app delete my-app --cascade
Quiz Time

Final Review

1. What is the default polling interval for ArgoCD to check Git repositories?

Correct! ArgoCD polls Git repositories every 3 minutes by default. You can configure webhooks for near-instant detection of changes.

2. When you delete an ArgoCD Application with argocd app delete my-app (no flags), what happens to the deployed resources?

Correct! By default, deleting an ArgoCD Application does not delete the deployed Kubernetes resources. Use the --cascade flag to also delete the resources.

3. Where must the ArgoCD Application CRD be created?

Correct! ArgoCD Application resources are created in the argocd namespace by default. The Application Controller watches this namespace for Application CRDs. (Applications-in-any-namespace is an opt-in feature available in newer versions.)
Summary

Module 01 Recap

Next up: Module 02 -- Applications and Projects Deep Dive

Module 01 Complete

You now understand the foundations of GitOps and ArgoCD

Continue to Module 02 to master Applications and Projects

← Back