Container Resource Sizing: CPU & Memory Requests, Node Packing & Cost

What you'll build

What you will be able to do

Each lab ends with a concrete result that you build yourself and the checker confirms, cell by cell.

• Convert the CPU and memory requests of six Larkspur Labs containers, written the way they appear in a manifest, into cores and MiB, and total the memory in GiB.
• Compare the CPU requests and limits of six Larkspur Labs services with their measured usage, find the reserved CPU that sits idle and check how far the limits overcommit the cluster.
• Turn a week of p95 usage into new CPU and memory requests for eight services, rounded up to clean steps, and total how much CPU the cluster gets back.
• Work out the allocatable CPU and memory of four node types, how many orders-api pods fit on each and whether CPU or memory runs out first.
• Total the right-sized requests of all eight services and calculate how many 8×32 nodes Larkspur Labs needs, after DaemonSets, a target fill and one spare node.
• Place ten pods, largest first, onto four nodes with the first-fit rule, then measure how many nodes you used, how well they are packed and how close you got to the lower bound.
• Split the monthly node bill of the Larkspur Labs cluster into a price per vCPU and per GiB, charge each service for what it requests, show the idle cost and chart the result.
• Apply the horizontal autoscaler's scaling formula, plan the orders-api replicas for every two-hour slot of a busy day between a minimum and a maximum, total the replica-hours and chart load against replicas.