Kubernetes without the bill shock: cost and reliability together
27 June 2026 · 8 min read · Nintech Infrastructure
Most Kubernetes bills are not high because Kubernetes is expensive. They are high because the default posture of every team on a shared cluster is to over-ask and never look back. Requests get set by copy-paste, limits by superstition, and node pools by whatever was provisioned in month one. The uncomfortable finding from nearly every cluster we have reviewed: 20 to 40 per cent average CPU utilisation is normal, and the gap is pure spend. The good news is that cost and reliability are not in tension here — the same discipline fixes both.
Right-size from measured usage, not folklore
Resource requests are a promise to the scheduler, and most of them are lies. A pod requesting 2 CPU and using 150 millicores does not just waste money — it makes the scheduler pack fewer pods per node, which forces more nodes, which is the bill. The fix starts with data: run something like Vertical Pod Autoscaler in recommendation mode, or pull P95 usage from your metrics store over a representative window (include your busiest day, not just a quiet fortnight), and reset requests to observed P95 plus sensible headroom. In practice this alone commonly recovers 30 to 50 per cent of compute spend on a neglected cluster.
Limits deserve equal care because they are a reliability lever, not a cost one. CPU limits cause throttling — often invisible throttling that shows up as mysterious tail latency, because CFS quota enforcement kicks in per 100ms period. Many teams now run with CPU requests set honestly and no CPU limit at all, letting burstable workloads use idle cycles. Memory is different: it is not compressible, so a memory limit is your defence against one leaky pod OOM-killing its neighbours. Set memory request equal to limit for anything you care about, so the pod lands in the Guaranteed QoS class and is last in line for eviction.
Autoscale at both layers, and make spot survivable
Pod-level and cluster-level autoscaling only work as a pair. Horizontal Pod Autoscaler adds replicas when load rises; Cluster Autoscaler or Karpenter adds nodes when pending pods cannot schedule. Each is nearly useless alone — HPA scaling into a full cluster just creates pending pods, and node autoscaling without pod scaling has nothing to react to. Get the signals right: CPU-based HPA is a blunt instrument for request-driven services, and scaling on requests-per-replica or queue depth via custom metrics tracks reality far better. And keep honest headroom — if your scale-up takes 90 seconds and your traffic doubles in 30, autoscaling is not your surge strategy; pre-provisioned buffer is.
Spot and preemptible instances offer 60 to 90 per cent discounts in exchange for two minutes or less of termination notice, and they are safe for far more workloads than most teams assume — if you do the work. That means handling SIGTERM properly and finishing within the grace period, PodDisruptionBudgets so evictions cannot take out a whole deployment at once, topology spread across instance types and zones so one capacity event does not correlate across your fleet, and keeping genuinely stateful or singleton workloads on on-demand nodes. Karpenter makes the mixed-fleet approach considerably less painful by provisioning from a wide instance-type palette. The caveat: spot capacity evaporates exactly when everyone wants it, so test the all-spot-reclaimed scenario before it tests you.
Nobody optimises a bill they cannot see
A single cluster invoice attributed to 'platform' is a tragedy of the commons with a monthly billing cycle. The mechanism that changes behaviour is per-team, per-namespace cost allocation: tools like OpenCost or Kubecost apportion node costs to workloads by their requests and usage, so a team can see that their staging environment costs more than their production one. Enforce labelling (team, service, environment) at admission — a policy controller rejecting unlabelled workloads costs an afternoon to set up and makes every subsequent cost conversation possible. Idle cost, the gap between what nodes cost and what workloads request, deserves its own line: it is the platform team's number to own.
Visibility only matters if someone acts on it. The lightweight version that works: a monthly review where each team sees their trend line, and the platform team flags the top three anomalies. What you are looking for is rarely exotic — orphaned PersistentVolumes, oversized dev environments running 24/7 that could scale to zero overnight, a forgotten load-test namespace, cross-zone traffic charges from a chatty service mesh. Showback (visibility without internal billing) captures most of the behavioural benefit of chargeback without the accounting overhead, and is the right place to start.
The question nobody asks: do you need it at all?
Kubernetes earns its keep when you have many services, multiple teams shipping independently, and workloads that genuinely benefit from bin-packing and a common operational substrate. If you are running six containers for one product team, the platform tax — upgrades every few months, ingress and certificate plumbing, network policy, the observability stack, and at least a fraction of an engineer who genuinely understands it — can exceed the cost of the workloads themselves. Managed container platforms (Cloud Run, Fargate, and their peers) delete most of that tax, and for a large class of stateless HTTP services they are simply the better engineering decision.
The honest framing is that Kubernetes is a platform for building platforms, and its costs are mostly organisational rather than computational. If you already run it and it works, this is not an argument for a migration — churn has costs too, and a well-run boring cluster is a fine asset. But if you are choosing today, size the decision by team count and operational appetite, not by what the job adverts say. The cheapest cluster is the one you did not need, and the second cheapest is the one where every request field tells the truth.
Working on something like this? Talk to an engineer.