Transit wants to rightsize GIS worker requests after observing that pods request far more CPU than they use in steady state. What comparison guides that decision?

Rightsizing GIS worker requests means comparing each container’s resource requests to observed usage from metrics—for example kubectl top—over a representative steady-state window. Transit teams then lower chronic over-requests or raise under-requests so the scheduler’s accounting matches reality, improving bin-packing and leaving headroom for county peak load. Setting every request equal to the node’s total CPU forces poor packing, often effectively one pod per node, and is not guided by observed usage patterns. Ignoring usage data and doubling all limits weekly regardless of top samples is cargo-cult capacity management, not disciplined rightsizing based on evidence. Removing all requests so HPA can infer perfect sizes from Ingress status codes breaks scheduling predictability and misuses HTTP status or latency signals that are not CPU or memory usage. Exam caveat: Prefer peaks and percentiles over a single quiet minute; remember requests drive scheduling fit while limits enforce throttling and OOM behavior. Document municipal change windows when altering production GIS requests. Operational check: Collect metrics over multiple days, compute request-to-usage ratios, patch Deployment resources carefully, and re-check Pending rates and node utilization after the rightsizing change lands.