Track 23: Performance and Load Testing
Back in 03-kubernetes module 09
you configured a Horizontal Pod Autoscaler, watched a CPU-burning demo pod
trigger it, and moved on. In 06-azure-container-apps module 03
you wired KEDA scale rules and pushed a few thousand curls at them. Both
times you proved the mechanism can scale — but not that your real app
scales the way production traffic would actually drive it, and not that the
thresholds you picked are the right ones. "It scaled when I hammered it with
a loop" is a demo, not a performance strategy.
This track closes that loop. You'll learn to design and run real load tests with k6, run them at scale from Azure Load Testing, model traffic that looks like real users instead of a uniform flood, and use those tests to validate the HPA/KEDA autoscaling you configured earlier — watching pods scale in real time on track 12's Grafana dashboards, and catching the common case where a config that looks right never actually triggers. Then you'll go deeper: reading results to find where a system really breaks (CPU limits, the database connection pool from track 14, a downstream rate limit), profiling to tell an infra problem from a code problem, and wiring a lightweight load test into a track 10 pipeline as a regression gate.
What this assumes
This is one of the last tracks, and it leans on several earlier ones:
- 03-kubernetes — Deployments, Services,
HPA,
kubectl top, metrics-server (module 09 especially). - 06-azure-container-apps — KEDA scale rules, min/max replicas, scale-to-zero (module 03 especially).
- 07-aks — running a real, billable managed cluster with Ingress, and the Cluster Autoscaler from module 05.
- 12-observability-deep-dive —
Prometheus, PromQL, and Grafana dashboards; you'll watch scaling happen
through them here, not just via
kubectl get hpa -w.
It also forward-references the SLOs you define in 20-sre-practices (a load test's pass/fail thresholds should be derived from your SLOs, not invented), the connection pooling from track 14, and the CI pipelines from track 10.
Cost warning: exercises here run load against real AKS clusters and Container Apps, and provision an Azure Load Testing resource. Load testing deliberately drives autoscaling, which means real replicas (and possibly real nodes via the Cluster Autoscaler) spin up and bill while the test runs. Nothing here is expensive if you clean up promptly, but a load test left running, or a cluster left scaled-up overnight, is a real way to get a real bill. Every module ends with an explicit cleanup step — don't skip it.
Modules
| # | Module | What it covers | Rough time |
|---|---|---|---|
| 00 | performance-testing-concepts | Load vs. stress vs. soak vs. spike testing; what question each answers; why "it feels fast" isn't a strategy; tying tests to SLOs | 45-60 min |
| 01 | k6-fundamentals | Writing a k6 script, virtual users, stages/ramping, thresholds, checks; running locally against a real app | 60-90 min |
| 02 | azure-load-testing | The managed service: provisioning, running a k6 script at scale, engine instances, comparing to self-run k6 | 60-90 min |
| 03 | designing-a-realistic-load-test | Modeling real traffic, think time, data parameterization, avoiding an unrealistically uniform test | 60-90 min |
| 04 | proving-autoscaling-works | Load-testing the track-03/06 HPA/KEDA setups; watching pods scale via Grafana; catching config that looks right but never fires | 75-90 min |
| 05 | identifying-bottlenecks | Reading results to find where a system breaks: CPU/memory limits, DB connection pool exhaustion, downstream rate limits | 75-90 min |
| 06 | profiling-and-application-performance | A survey of profiling; hot code paths, N+1 queries; infra scaling vs. code-level fixes | 60-90 min |
| 07 | performance-testing-in-cicd | A lightweight load test as a pipeline gate; catching a regression before ship; thresholds that don't cause flakiness | 60-90 min |
| 08 | capstone-project | End-to-end: realistic k6 test on AKS/ACA, proof of HPA/KEDA scaling via Grafana, one real bottleneck + fix, a CI performance gate | 4-6 hours |
How this track works
- Go in order — module 04 assumes you can write a k6 script (module 01) and design a realistic one (module 03); module 07 assumes you can find a bottleneck (module 05).
- Every module (except this index and the capstone) follows the same shape: Why this matters → Concepts → Command reference → Hands-on exercises → Independent challenge → Common mistakes & troubleshooting → Checkpoint quiz → Next. Two modules also carry a Cumulative review.
- Exercises run real k6 tests against a real app on Kubernetes or Container Apps — not a simulator. Each ends with a cleanup step.
- Module 08 is the capstone: no quiz, no new concepts — it asks you to combine everything into one real, load-tested, scaling-proven, bottleneck-diagnosed, CI-gated system.
Prerequisites
- Everything from the four dependency tracks above, plus an active Azure subscription (already confirmed for this curriculum).
- k6 installed in your WSL2 environment (module 01 covers this).
Start here → 00-performance-testing-concepts/README.md