GitOps & CI/CD (ArgoCD)
Run a real GitOps loop against a Git repository you can actually push to. The lab serves its own repo in-cluster; ArgoCD reconciles it. You clone it, change the declared image and replica count, push, and watch the cluster follow, then prove the three things that make GitOps different from kubectl: self-heal reverts a change you make by hand, prune deletes a resource you remove from Git, and a release that syncs perfectly can still be broken - the lab ships one that is, and you repair it in Git.
What you'll do
- Read an Application CRD as a contract: a Git path bound to a cluster destination
- Clone the repository ArgoCD actually watches, over a port-forward to the in-cluster Git server
- Change declared state in Git, bump the image tag and the replica count, commit and push it
- Watch ArgoCD reconcile your commit into the cluster without you touching the cluster
- Prove self-heal: scale the Deployment with kubectl and watch ArgoCD revert you
- Prove prune: delete a manifest from Git and watch the resource leave the cluster
- Diagnose a failed sync from the Application's conditions and repair it in Git
Stages
- 1gitops-controller
Make sure ArgoCD is running, adopting the platform's release if it already is
argocd - 2git-source
Serve the lab's own Git repository in-cluster, seeded with the demo app's manifests
git-server - 3gitops-telemetry
Scrape ArgoCD's controller, server and repo-server metrics, and plot sync state
argocd-servicemonitorsgitops-dashboard - 4bind-application
Point ArgoCD at the lab repo and wait for the first reconcile
gitops-demo-app
Prerequisites
--deploy-prereqs installs these into the lab for you. They are listed so you know what the scenario depends on.
Related scenarios
- Multi-Env Promotion (Dev → Staging → Prod)Run a real release pipeline by hand: build versioned go-api images, deploy one to dev, and promote it forward to staging then prod with plain kubectl. Promotion here is a genuine image rollout (new ReplicaSet), not a ConfigMap edit - you build vNEXT, roll it out per environment, and watch each env's /version change as the release moves down the pipeline.
- Autoscaling Under LoadWatch KEDA scale go-api on Prometheus RPS: a spike drives it from 1 to several replicas, then cooldown brings it back. The flagship 'autoscaling actually works' demo, verified under traffic from the load generator.
- Chaos EngineeringRun the chaos engineering loop against go-api with Chaos Mesh: establish a steady state under load, form a hypothesis, inject a failure (pod kill, network delay, CPU and memory stress) and measure the blast radius on a Grafana dashboard. go-api ships as a single replica behind a PodDisruptionBudget, so it starts out with disruptionsAllowed=0: a node drain would block forever while a pod kill is still a full outage. Your job is to find that with an experiment and fix it, then prove the same experiment no longer hurts.