How do you keep Kubernetes resource requests from becoming permanent guesses?

Start with the largest deployments and compare requests with CPU and memory usage over the past month. A P95 comparison is a useful way to spot candidates for review, not a target to apply blindly.

Look at the shape of the usage too. A short daily CPU spike may not justify reserving peak capacity all day, but those spikes still need to be understood before changing anything. Memory deserves separate attention, especially if the request was raised after an OOM.

Sometimes the slack is deliberate. A service may need predictable capacity more than it needs a smaller allocation, so treating every gap between usage and requests as waste misses the point. Ask what reliability requirement the reservation is meant to cover before trimming it.

The incentive problem is real. If a team gets paged for a failure but never sees the cost of an oversized deployment, the safe-looking number tends to win.

One option is to assign namespaces to owners and cost centers, then make resource costs visible to those owners. Charging based on pod limits and storage is one approach, though that's not the same thing as charging based on requests, so the policy needs to match what you're trying to change.

Vendor defaults are another place to look. They may be conservative because the vendor doesn't know how a customer will use the software. Treat them as a starting point, not evidence that those values fit your workload.

In-place pod resizing may make adjustments easier on clusters that support it. It doesn't solve the sizing decision for you, but it gives teams another way to act on usage data instead of leaving the original settings alone.