Argo CD and GitOps Bootcamp with Helm and Kustomize

Breaks down Argo CD's three core components — the API server (authentication and dashboard), repository server (fetches and renders manifests), and application controller (syncs your cluster to match Git) — and walks through the complete sync workflow end to end.

A hands-on walkthrough of installing the four tools you'll need for this course — Docker, Kind, kubectl, and Helm — with install commands for macOS, Linux, and Windows.

Shows how to create your local Kubernetes cluster using Kind — by writing a kind-config.yaml file, running the create command, and verifying that the cluster and its nodes are up and running.

Install Argo CD on your Kind cluster using Helm, then access the Argo CD dashboard through port-forwarding and log in with the default admin credentials. You'll also install the Argo CD CLI, explore the core components running as pods (server, repo server, Redis, application controller), and connect to Argo CD from the command line.

A quick preview of this module — deploying the Finovra app with Argo CD. You'll get an overview of what's ahead: cloning the repositories, understanding the Application resource file, manual vs. automated sync, sync and health status, and the prune and self-heal features.

A walkthrough of the GitOps repository — cloning it locally, exploring the Kubernetes manifest files (deployment and service YAML) for each microservice, and cross-checking the image tags in those files against the actual versions available on Docker Hub.

Learn the three key parts of an Argo CD Application resource file — source (where your manifests live), destination (which cluster and namespace to deploy to), and sync policy (manual or automated). You'll then create the actual Application file for the Finovra app.

Apply the Application resource file with kubectl and see it appear in Argo CD as Missing and OutOfSync. Learn why that happens with manual sync, trigger a sync from the GUI, and understand the difference between Sync Status (does Git match the cluster) and Health Status (is the app actually running fine).

A tour of the rest of the Argo CD dashboard — viewing differences, sync history, and rollback; deleting and refreshing applications; and checking Events and Logs for individual resources. Also covers key Settings sections like Repositories, Clusters, Projects, and Accounts, and wraps up by accessing the live Finovra app through port-forwarding.

Deliberately deploy a broken image tag that doesn't exist in Docker Hub, and see how Argo CD handles it — the app shows Synced but Unhealthy, stuck in an ImagePullBackOff error. Learn how to check the failure details using both the Argo CD GUI (Events) and kubectl commands, and understand why sync status and health status can disagree.

Compares manual sync (you trigger it, safer for production) with automated sync (Argo CD syncs automatically when Git changes, faster for dev/staging). You'll fix the broken deployment, then enable automated sync in the Application file so future changes deploy on their own.

Learn how the prune option automatically deletes cluster resources when their manifest file is removed from Git. You'll test this by creating and then deleting a sample ConfigMap — first without prune (the resource is left behind as orphaned), then with prune enabled (it gets cleaned up automatically).

Learn how self-heal automatically reverts manual changes made directly on the cluster (like a kubectl edit) back to match what's defined in Git. You'll test this by manually scaling a deployment — first without self-heal enabled (the change sticks until you sync manually), then with self-heal on (Argo CD reverts it automatically).

A preview of this module on deployment sources — the three ways to define what gets deployed: plain YAML, Helm charts, and Kustomize. You'll learn what each one is, when to use it, and get hands-on labs for both Helm and Kustomize.

Understand why plain YAML manifests become hard to manage as you add more environments, and how Helm solves this using templated files and a values.yaml file to fill in the differences. Includes a comparison table covering templating support, learning curve, best-fit use cases, and duplication for plain YAML, Helm, and Kustomize.

A hands-on walkthrough of switching the Finova app's deployment source to Kustomize — building the base and overlays folder structure, customizing values like replica count per environment, and updating the Application file to point to the new source. Includes real troubleshooting when the deployment path is misconfigured.

A hands-on walkthrough of switching the Finovra app's deployment source to Helm charts — exploring the chart's templates, values.yaml, and environment-specific values files, then updating the Application file to use Helm as the source. Also covers adding environment-specific overrides on top of the default values.

A preview of this module on rollback and failure recovery. You'll first deploy a faulty release to see what breaks, then learn three different ways to recover from it: a native Argo CD rollback, a direct kubectl fix, and a Git revert.

Deliberately deploy a buggy version of the dashboard microservice to set up the rollback exercises ahead. You'll see an important real-world lesson here — the pods report healthy at the Kubernetes level, but the application itself is broken, showing why infrastructure health and application correctness aren't the same thing.

Learn the first rollback technique — using Argo CD's built-in rollback feature to revert to a previous revision through the CLI or GUI. You'll see that this requires disabling auto-sync first, and discover its key limitation: since it only changes what's running in the cluster (not what's in Git), the fix is temporary and gets undone the next time you sync.

Learn the second rollback technique — directly editing the deployment with kubectl to revert to the previous image version. Like the Argo CD rollback, this only changes the cluster, not Git, so it's a temporary fix: re-enabling auto-sync causes Argo CD to redeploy the faulty version again from Git.

Learn the third and most reliable rollback technique — using git revert to undo the bad commit in your GitOps repository. Since Argo CD syncs automatically from Git, this becomes the permanent fix: once pushed, the app redeploys cleanly and stays fully in sync, with no drift left behind.

A preview of this module on progressive delivery. You'll learn why deploying a bad update to 100% of users at once is risky, and how Argo Rollouts solves this with canary and blue-green deployment strategies that gradually test new versions before a full rollout.

Understand how canary and blue-green deployments work and how they differ. Canary gradually shifts a percentage of traffic to the new version and validates it automatically, while blue-green runs two full environments and switches all traffic at once. Includes a comparison of traffic switching, rollback behavior, and when to use each.

A hands-on walkthrough of installing Argo Rollouts on your cluster — creating a namespace, installing the controller, and setting up the Argo Rollouts CLI locally so you can manage and monitor progressive deployments.

Learn how to convert a standard Kubernetes deployment into an Argo Rollout using the canary strategy — covering the stable and canary services, the setWeight parameter that controls traffic split, and the AnalysisTemplate that automatically checks whether the new version is healthy before promoting or rolling it back.

A hands-on walkthrough of converting the dashboard microservice into an Argo Rollout and deploying a new, working version using the canary strategy. Watch as Argo Rollouts gradually shifts traffic between the old and new versions, runs automated health checks, and fully promotes the new version once it passes.

Deploy a faulty version using the canary strategy and see how Argo Rollouts automatically detects the failure through its health checks, aborts the rollout, and reverts back to the last known-good version — all without any manual intervention. You'll also update the GitOps repository to keep it in sync with what's actually running.

A preview of this module covers two major topics: promoting releases safely from dev to staging to production using a pull-request workflow, and the App of Apps pattern for managing multiple Argo CD applications from a single root file instead of applying each one manually.

Before building out staging and production environments, revert the dashboard microservice back from an Argo Rollout to a standard Kubernetes Deployment, keeping things simple for the environment promotion exercises ahead.

Learn how to create staging and production environments using Helm by adding environment-specific values files and new Argo CD Application files. Covers key real-world practices, like why production runs an older, more stable image version, and why auto-sync is typically disabled in production.

Learn the App of Apps pattern — using a single root Application file to automatically manage multiple other Application files (like dev, staging, and production), so you no longer need to manually apply each one with kubectl.

A hands-on walkthrough of setting up the App of Apps pattern — creating a root Application file, deleting the existing dev, staging, and production apps, then recreating all of them with a single command. From here on, updating any environment's file is enough; no manual kubectl apply is needed.

Learn the real-world way to promote a tested image from a lower environment to production — creating a branch, updating the production values file, and raising a pull request instead of committing directly to main. Once merged, you'll manually sync production during a planned change window to deploy the new release.

Test the power of the App of Apps pattern by adding a brand-new QA environment — just by copying and committing a new values file and Application file. See how the root Application file automatically detects and creates the new environment without any manual kubectl commands.

Understand the problem with maintaining separate, nearly identical Application files for each environment (dev, QA, staging, production). This sets up the case for ApplicationSets— a way to generate multiple Application files from a single template using variables instead of duplicating files.

A hands-on walkthrough of replacing separate Application files with a single ApplicationSet. Learn how the template and generator work together — the generator supplies environment-specific values (dev, QA, staging), and the template uses them to automatically create each Application.

Fold production into the same ApplicationSet used for dev, QA, and staging by adding a new entry to the generator list. You'll also see how to safely remove an environment's Application file without affecting its underlying pods or namespace.

A preview of this module addressing a real-world problem — running production and non-production environments on the same cluster. You'll learn the plan to create a second cluster, register it with Argo CD, and migrate production onto it.

A hands-on walkthrough of creating a second Kind cluster for production and registering it with Argo CD, including how to troubleshoot common context and authentication issues along the way.

Update the ApplicationSet to point production at the new dedicated cluster instead of the shared in-cluster destination used by dev, QA, and staging. Confirm the migration by checking that production's pods are running healthily on the new cluster.