All of the catalog
Scenario
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.
DeliveryVerifiedk3dkind
Definition on GitHubWhat you'll do
- Understand environment separation as Kubernetes namespace isolation (env-dev / env-staging / env-prod)
- Build multiple immutable, versioned images (go-api:v1.0.0, v1.1.0, …) and load them into the cluster
- Deploy a new version to dev only, and prove the other environments are unchanged
- Promote a version dev → staging → prod with 'kubectl set image' + 'kubectl rollout status' - a real rollout
- Roll back a bad promotion with 'kubectl rollout undo'
- Verify the pipeline: every environment's running image matches its declared tag
Stages
- 1seed-baseline
Build the go-api:v1.0.0 baseline image and load it into the cluster
baseline-image - 2dev-env
Deploy go-api:v1.0.0 into the dev environment (namespace env-dev)
dev-environment - 3staging-env
Deploy go-api:v1.0.0 into the staging environment (namespace env-staging)
staging-environment - 4prod-env
Deploy go-api:v1.0.0 into the prod environment (namespace env-prod)
prod-environmentpromotion-dashboard
Prerequisites
--deploy-prereqs installs these into the lab for you. They are listed so you know what the scenario depends on.
ingressmonitoring/metricsgo-api
Related scenarios
- 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.
- 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.