Introduction to Argo CD

What sets GitOps apart from traditional CI/CD, and why are more teams adopting the pull model? This module covers the core principles: Git as Single Source of Truth, declarative configuration and automatic reconciliation. You compare Argo CD with Flux CD, place both tools within the CNCF ecosystem and understand when each approach fits.

You install Argo CD via Helm chart on your own Kubernetes cluster and explore the architecture: Application Controller, Repo Server, API Server and Redis as cache. Then you navigate the web UI and the argocd CLI, create your first projects and connect your Git repository. By the end of this block, your Argo CD instance is running and ready for the first deployment.

Time to get hands-on: you create an Application resource, link it to a Git repository and watch Argo CD reconcile the desired state in your cluster. You configure sync policies (manual and automatic), define health checks and learn the difference between OutOfSync and Degraded. After this block, you can independently deploy applications via Git and monitor their status in the UI.

What happens when someone manually changes a resource via kubectl? Here you enable self-healing and observe how Argo CD detects drift and corrects it. You configure pruning (automatic deletion of orphaned resources), work with sync waves and resource hooks for ordered deployments and test retry strategies for failed syncs. This way you understand how Argo CD guarantees the desired state without manual intervention.

A broken deployment needs to be reverted quickly. You compare three approaches: rollback via the Argo CD history, Git revert followed by sync and manual override. Which approach fits which situation? Additionally, you back up the Argo CD state (application definitions, projects, repository credentials) and practice restoring an Argo CD instance on a fresh cluster.

Helm is the de facto standard for Kubernetes package management, and Argo CD supports Helm-based applications natively. You create applications with values files per environment, use chart repositories and the new OCI registry support (since v3.1). Using a concrete example, you see how Helm parameters are overridden in Argo CD and when values files in the Git repo are the cleaner approach.

Not every project needs Helm templates. With Kustomize you work with overlays that adapt base manifests per environment without duplicating them. You create a kustomization with patches for dev, staging and production, test the output with kustomize build and deploy the result via Argo CD. At the end, you compare Helm and Kustomize and can make an informed decision about which tool fits your projects better.

Mono-repo or multi-repo? App repo and config repo separate or combined? This decision shapes your entire deployment workflow. You analyze the pros and cons of both approaches using concrete scenarios, design an environment promotion pipeline (dev → staging → production) and set up a PR-based workflow where changes only reach the cluster after review.

When managing more than a handful of applications, you need automation. With ApplicationSets you generate applications dynamically from templates. You work with the key generators: List (static cluster list), Cluster (automatic discovery), Git (directory and file based) and PullRequest (preview environments per PR). At the end, you deploy an application to multiple clusters simultaneously and control the rollout with the progressive rollout strategy.

How do you bootstrap an entire cluster with all applications from a single Git commit? The App of Apps pattern solves exactly this problem: a root application defines and manages all child applications. You build this pattern hands-on, discuss its limitations (dependencies between apps, sync ordering) and compare it with ApplicationSets. After this block, you know when App of Apps and when ApplicationSets are the better choice.

In production environments, different teams need different permissions. You configure AppProjects for namespace isolation, define RBAC policies with fine-grained permissions (who can sync, who can only read?) and set up SSO via OIDC with Dex. You also leverage the new OIDC token auto-refresh (v3.3) that prevents unexpected logouts during work.

Secrets don't belong in a Git repo, but GitOps requires everything to live in Git. How do you resolve this contradiction? You test three approaches hands-on: Sealed Secrets (encryption in the repo with kubeseal), External Secrets Operator (connecting to AWS Secrets Manager, HashiCorp Vault or Azure Key Vault) and SOPS with age encryption. For each approach, you evaluate complexity, security and maintainability.

Kubernetes Deployments only support rolling updates. For controlled releases you need Argo Rollouts. You install the controller, create your first canary rollout strategy with percentage-based traffic steering and define AnalysisTemplates that automatically pause or abort the rollout when metrics exceed thresholds. Then you configure a blue-green deployment with preview service and manual promotion step.

Who gets notified when a sync fails or a rollout pauses? You configure Argo CD Notifications for Slack, Microsoft Teams and webhooks, defining triggers for sync failures, health degradation and successful deployments. On the monitoring side, you scrape Argo CD's Prometheus metrics and build a Grafana dashboard that visualizes sync duration, application health and reconciliation cycles.

GitOps complements your CI pipeline with automated continuous deployment to Kubernetes. You integrate Argo CD with GitLab CI and GitHub Actions: the CI builds and pushes the image, updates the manifest in the config repo, and Argo CD rolls out the change in the cluster. Additionally, you configure the Argo CD Image Updater for automatic image tag updates. Finally, you discuss production best practices: shallow git fetches (v3.3) for large repos, resource exclusions, diff customization and performance tuning.