Changing CPU and memory settings is easy to express in a deployment manifest. Deciding whether the change is appropriate takes more context. A useful review connects the configuration to workload behavior, customer experience and the cost of running the service.

Start with the distinction

Kubernetes uses resource requests when deciding where to schedule a Pod. A request is not a usage ceiling: a container may use more when resources are available. On Linux, CPU limits are enforced through throttling; memory limit enforcement can terminate a container through an out-of-memory kill.

CPU quantities also have specific units: 250m means one quarter of a CPU unit, while 500m means one half. These quantities are not percentages of the entire node. The Kubernetes documentation explains these behaviors in Resource Management for Pods and Containers.

Those distinctions matter when interpreting a chart. Low average usage alone does not tell you which request or limit to choose.

Gather evidence for one workload

Start with a service whose owner can explain what normal operation looks like. Record its current configuration and collect observations over a period that includes ordinary traffic, busy periods, startup and any scheduled work.

Put the following questions in the review ticket:

• What are the current CPU and memory requests and limits for each container?
• When does resource demand peak, and what is happening at that time?
• Have there been restarts, out-of-memory events or CPU throttling?
• What does the customer experience during those periods?
• Which other containers or dependencies are involved?

Keep the time ranges aligned. Comparing this morning's latency with last month's average CPU usage makes a decision harder to defend.

Write a hypothesis before changing values

An example hypothesis might be: “This worker appears to request more CPU than it needs during representative processing runs. We will test a lower request while keeping the completion-time target unchanged.”

That is a testable proposal, not proof of waste. Record what evidence would support it and what would make you reject it. Avoid selecting a universal CPU-to-memory ratio and applying it to every workload.

Test performance and recovery together

Use an appropriate test environment and representative traffic or jobs. Observe completion times, response times, error rates and resource behavior. Agree on the rollback criteria and retain the previous configuration before making a production change.

Review scaling behavior and placement constraints with the service owner as part of the change. A configuration can look reasonable in isolation while interacting poorly with the way the rest of the system operates.

Verify the cost outcome separately

A smaller resource request is a configuration change. A lower infrastructure bill is a measured outcome. Check whether the underlying provisioned capacity and billed usage actually changed, and account for differences in traffic and reporting periods.

Close the review with the observed service result, the measured cost result and the next review date. If the experiment did not help, retain the evidence: it can prevent the next person from repeating an unsuccessful change.

CloudForge Consulting helps teams with Kubernetes optimization, FinOps, DevOps and cloud reliability across AWS, Azure and Google Cloud. More about the practice: CloudForge Consulting.