Kubernetes Cost Optimization: Rightsizing, FinOps and Unit Economics

Start with useful work and a reliability budget

The client’s ordering platform pairs its $240,000 compute bill with successful orders and the reliability budget.

A lower monthly bill does not necessarily mean a more efficient platform. Fewer customers, a backlog of unfinished reports, or newly rejected requests can all make spending fall. Define the denominator before changing infrastructure: successful orders, completed reports of a comparable size, or another unit that represents delivered value. Keep workload classes separate when their resource profiles differ substantially.

Build a baseline spanning normal traffic, peaks, deployments, and recovery events. Pair allocated compute and actual resource use with request latency, errors, queue age, and dependency saturation. Include shared services, storage, network egress, and reserved-capacity commitments in the cost boundary. Otherwise, moving work from application nodes into a database can look like a saving even when total cost increases.

For the stated SLO, classify a request as good only when it is both successful and fast enough. Watch error-budget consumption while testing a change. Capacity reserved for a node failure is not automatically waste: it buys a specific recovery property. Record that property so an optimization does not quietly remove it.

Requests schedule capacity; limits constrain consumption

Quiet nodes lead you to their resource requests. The scheduler’s view of capacity is not the same as the process’s current consumption.

Kubernetes schedules pods using resource requests rather than their current consumption. Oversized requests can strand otherwise usable capacity. Undersized requests can pack workloads together that compete precisely when they are busiest. A request is not a ceiling: a container may consume more when capacity is available. CPU limits are enforced through throttling, while memory limits can result in an out-of-memory kill.

Choose CPU requests from representative demand and latency behavior, not simply a historical average. For memory, investigate working sets, cache growth, garbage collection, initialization spikes, and the largest valid request. Memory reclaimed by killing a process has a different operational cost from CPU throttling. Repeated restarts also create extra work and can make a seemingly cheaper allocation more expensive.

The following fragment uses the starting values from this engagement, not universal recommendations. Its CPU limit may be appropriate for isolation, but a latency-sensitive service should explicitly test whether that limit causes throttling during bursts. Omitting a CPU limit is a policy decision requiring contention controls, not a blanket performance trick.

resources:
  requests:
    cpu: "500m"
    memory: "512Mi"
  limits:
    cpu: "2"
    memory: "1Gi"

Coordinate pod scaling with node scaling

A smaller request changes the HPA calculation. Kubernetes cost optimization now has to consider pod and node scaling together.

For four replicas observed at 90% of their CPU request and a 60% target, the raw formula is ceil(4 × 90 / 60) = 6. If each pod uses 450m against a 500m request, the observation is 90%. Halving that request to 250m makes the same usage 180%, yielding a raw recommendation of 12 before controller policy. The traffic did not double; the denominator changed.

Real HPA behavior also accounts for tolerance, missing or not-yet-ready metrics, replica limits, stabilization history and scaling policies. With multiple metrics, a valid larger recommendation can win; unavailable metrics can inhibit a scale-down. A PodDisruptionBudget constrains supported voluntary eviction paths, not ordinary HPA or Deployment replica reduction. Do not use it as a minimum-replica setting.

Right-sizing and autoscaling need a joint review. Validate the actual scaling signal, and ensure every relevant container has the requests required by the selected metric.

The HPA changes desired replicas; node autoscaling supplies somewhere to run them. Node provisioning, image pulls, and application warmup all add delay before capacity serves traffic. Maintain a suitable replica floor or prepare capacity ahead of predictable demand. For report workers, queue age or backlog per worker may describe demand better than CPU, especially when external storage is the bottleneck.

Scale-down deserves equal attention. Stabilization reduces oscillation, while topology placement and disruption budgets shape voluntary eviction safety. A disruption budget does not reserve spare nodes or protect against every failure. Test whether consolidation can actually move pods given affinity rules, attached volumes, minimum replicas, and available destinations. Savings remain theoretical until billable capacity is genuinely released.

Choose the controller that owns the constraint

Controller ownership matters because a lower request can change the replica recommendation without removing any charge.

Avoid two independent controllers writing the same desired state. HPA changes replicas, while VPA can recommend or adjust resource requests under its configured policy. Changing the request also changes a CPU-utilization HPA denominator, so test the combined behavior rather than tuning each in isolation.

Event-driven scaling can expose queue or external demand through an autoscaling integration, but a longer queue may reflect a saturated dependency rather than too few workers. Node autoscaling addresses schedulability and capacity; it cannot make an overloaded database faster. Trace the bottleneck before adding more consumers.

Change one constraint and rehearse failure

The proposed saving reaches a representative workload. Failure rehearsal tests whether the removed headroom had a purpose.

Roll out a resource adjustment to a representative subset, then compare it against an unchanged baseline under equivalent demand. Hold the application version steady when possible. A concurrent database migration or caching change makes attribution difficult. Explicit stop conditions should include elevated budget burn, increasing queue age, OOM kills, and sustained pending pods, not just high utilization.

Exercise a node loss, a traffic step, and a deployment that temporarily overlaps old and new replicas. These events consume different forms of headroom. Check downstream connection limits before raising worker concurrency: faster queue consumption can overwhelm a database and shift the failure elsewhere. Interruptible capacity belongs first on restartable work with durable checkpoints, not wherever its discount looks largest.

Measure savings without hiding service degradation

The $72,000 monthly difference held because real billable capacity retired at the same useful output.

As a separate compute-only example, eight nodes at $0.48 per node-hour for 730 hours cost $2,803.20. Five equivalent nodes cost $1,752.00, a gross difference of $1,051.20 before commitments, other bill items or operating changes. The hourly rate and node reduction are planning inputs, not a provider quote. Free space inside eight still-billed nodes is not that cash saving.

Compare cost per successful unit over equivalent workload windows, alongside absolute spending and service-level results. Separate effective invoice savings from reduced allocation: existing commitments can delay cash savings even when resource demand falls. Include any extra telemetry, operational work, and cross-zone transfer introduced by the new placement.

A defensible decision record contains the workload, changed constraint, baseline, failure exercise, SLO result, and observed cost boundary. Keep the previous resource settings available for rollback. Repeat measurement after the next demand shift rather than assuming a one-time right-sizing exercise stays correct. The objective is less cost for the same useful service and recovery behavior, not the smallest possible cluster.