Cost & Capacity: Right-Sizing Over-Provisioned Resources
Deploy go-api with deliberately over-provisioned CPU and memory requests, observe the inflated cost in OpenCost, then right-size the requests to a realistic baseline. Checks verify that requests were reduced to the target thresholds while go-api stays healthy under traffic. Teaches the observe-measure-reduce loop that keeps platform costs rational.
What you'll do
- Observe go-api's inflated cost in OpenCost and relate it to over-provisioned CPU/memory requests
- Right-size the CPU request from 2000m to ≤100m and memory request from 1Gi to ≤256Mi
- Verify go-api stays healthy under steady traffic with the reduced requests
- Understand that requests drive scheduling and billing, while limits cap usage
Stages
- 1inflate
Over-provision go-api's CPU/memory requests 40×/32× (the 'before' state to observe in OpenCost)
go-api-overprovisioned
Prerequisites
These are installed into the lab cluster for you — listed so you know what the scenario actually depends on.
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 EngineeringFailure injection with Chaos Mesh — pod kills, network delays, CPU/memory stress, partitions. Correlate chaos experiments with application metrics via Grafana dashboard.
- Day-2 Drill: Namespace Backup & RestoreBack up a namespace's resources to a manifest archive, simulate accidental data loss (delete a resource — or the whole namespace), then restore from the backup and verify the round-trip with checks. A stateful data-writer on a PersistentVolume makes the crucial lesson concrete: the manifest backup round-trips Kubernetes OBJECTS, not the DATA on a volume. A dependency-light alternative to Velero that teaches the backup/restore loop every operator must rehearse before they need it.