All of the catalog
Scenario
Mesh Traffic Management
Run a canary release for go-api on Istio. labctl stages two versions behind one Service and a meshed load client; you write the routing. Shift a 90/10 weighted split, rehearse a slow release with a header-matched latency fault, and lock the canary down with STRICT mTLS, then prove each one from mesh telemetry rather than from the fact that a CR exists.
NetworkingVerifiedk3dkind
Definition on GitHubWhat you'll do
- Apply a VirtualService that sends 10% of canary traffic to v2, and confirm the split in mesh telemetry
- Inject a mesh-level latency fault for opted-in requests only, without touching the application
- Enforce STRICT mTLS on the canary and prove an unmeshed client is refused
Stages
- 1mesh-enrolment
Enrol the workload namespace so pods get a sidecar
enrol - 2canary-workloads
Two versions behind one Service, plus the subsets a route can target
canary - 3canary-client
A meshed load client so the mesh has traffic to shape and report
clientmesh-dashboard
Prerequisites
--deploy-prereqs installs these into the lab for you. They are listed so you know what the scenario depends on.
ingressmesh/istiomonitoring/metricsgo-api
Related scenarios
- 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.
- Cost & Capacity: Right-Sizing Over-Provisioned Resourcesgo-api arrives reserving 2000m CPU and 1Gi of memory - forty times what it uses. Drive real traffic, read the gap between reserved and used on the dashboard and in OpenCost, then right-size the requests. Grading has two sides: a request over the waste ceiling fails, and so does one under the peak the workload actually reached, because under-provisioning is how workloads get throttled and OOM-killed.