Practical Kubernetes cost optimization: right-sizing, autoscaling, spot and preemptible nodes, and namespace-level cost allocation for DevOps teams.
TL;DR
- The scheduler reserves whatever a pod requests, so an inflated request bills you whether the workload uses it or not.
- Right-sizing requests and limits comes first, because autoscaling and capacity purchasing inherit the numbers it sets.
- Spot and preemptible nodes carry up to 90% off on-demand rates, the steepest discount available to a cluster.
- Without per-namespace allocation, savings get quietly spent again next quarter by a team that never saw the bill.
What is Kubernetes cost optimization?
Kubernetes cost optimization is matching reserved cluster resources to real usage, urgent now that 70% of organizations expect AI-generated code to inflate cloud spend.
- Right-size CPU and memory requests from observed usage.
- Let HPA, VPA, and Karpenter scale to demand.
- Attribute spend per namespace so your teams own it.
Two years ago somebody gave a deployment two CPUs and four gigabytes of memory. It was a guess. Nothing broke, so nobody checked it again.
That guess now runs across three hundred pods. The scheduler reserves every core of it whether the container burns 200 millicores or 2,000. Your cloud provider bills you for the reservation, not the usage, and no alert will ever let you know.
Kubernetes cost optimization, or k8s cost optimization as it is usually shortened, is mostly finding numbers like that one, correcting them, and keeping them corrected while the cluster changes underneath you.
Why is Kubernetes cost management so hard?
Kubernetes has never seen your invoice. It is a scheduler. It knows requests, limits, and how much room a node has left. It places pods without any concept of what a node costs per hour or which cost center is paying for it.
Your cloud provider has the opposite blind spot. It knows the price of everything it sold you and nothing about what ran on it. A node arrives as one line item. The eleven workloads that shared it, owned by four teams across two business units, do not arrive at all.
Namespaces look like they should close that gap. They are an access and quota boundary, though, and nothing in a default install maps spend onto them. The FinOps Foundation treats calculating container costs as a discipline of its own: one-to-one allocation, the model the rest of cloud finance runs on, does not survive a shared cluster. That is why Kubernetes cost management is its own practice rather than a subheading under the cloud bill.
What are the core levers for Kubernetes cost optimization?
Four levers move the number, and they work best in order. Each one scales whatever the one before it left behind.
How do you right-size requests and limits?
Requests are the bill. Limits are the ceiling. A request reserves capacity on a node for the life of the pod, while a limit only caps what the container can grab before the kernel throttles or kills it. Teams inflate requests because under-requesting wakes somebody up at night, and over-requesting never does.
Set requests from observed usage across several weeks rather than from the value sitting in the deployment template. Google Cloud's guide to cost-optimized Kubernetes applications on GKE walks the same sequence: get requests close to real consumption, then let autoscaling work against honest numbers.
Which autoscaler solves which problem?
Three autoscalers, three different jobs. The Horizontal Pod Autoscaler adds replicas when demand rises. The Vertical Pod Autoscaler adjusts a workload's requests for you. The Cluster Autoscaler, or Karpenter on AWS, adds and removes nodes underneath both and packs workloads onto fewer of them.
Capacity purchasing sits at this layer too. AWS puts spot savings at up to 90% off on-demand for stateless, fault-tolerant workloads. Steepest discount on the menu. The AWS best-practice guidance reduces to two habits: stay flexible across instance types and availability zones, and handle the two-minute interruption notice gracefully.
How do you split the bill for a shared cluster?
Split shared cluster cost proportionally, so four namespaces each consuming a quarter of the cluster carry a quarter of the bill apiece. Settle on a labeling convention first, because allocation is only ever as good as the tags underneath it.
Where the money leaks in a typical cluster
Every leak below looks healthy from the outside. Nothing is down and nothing is throttling. The bill is just bigger than the work. These five are where k8s cost optimization usually starts.
By the numbers: Inefficient code has never been cheaper to ship or more expensive to run. In Harness research, 70% of organizations say they are worried AI assistants could push cloud costs out of control, because it is so easy to deploy inefficient code.
What should you track to reduce Kubernetes costs?
Five numbers cover most of it, tracked per namespace and per workload.
- Cost per namespace. The smallest unit a team can be handed and asked to own.
- Cost per workload. Where right-sizing decisions get made, and where a bad request shows up first.
- Idle spend. The distance between requested and used, and the most actionable line on the page.
- Unallocated spend. Capacity attributable to nobody. If it climbs month over month, your labels are drifting.
- Cost per unit of work. Per deployment, per tenant, per thousand transactions. The only view that tells a growing bill apart from a wasteful one.
What should you look for in a Kubecost alternative?
A Kubecost alternative comes from one of four camps: open source collectors, dedicated cost products, the cloud providers' own billing consoles, and delivery platforms that carry FinOps next to deployment. Most read the same metrics from the same API, so the real question isn't which number they show you, it's where that number lands. The first three camps stop at reporting: a human still has to open a ticket, track down the deployment, and make the fix. The Harness Cost Management Agent is built as the fourth camp instead: it puts cost data next to the workload that created it, inside the platform that deploys it, so the number lands with someone who can already act on it, at whatever autonomy level you choose.
How Harness approaches Kubernetes cost optimization
The challenge
The engineer who can change a resource request is rarely the person who opens the invoice, and roughly thirty days sit between them.
By the time a spike surfaces in a finance report, the deployment that caused it has shipped a dozen more times, and the conversation has turned into an audit of last month instead of a fix for this week.
The approach
Harness Cost Management Agent closes that gap by putting cost data inside the delivery platform. An engineer sees spend per namespace, workload, and pod next to their deployments, with right-sizing recommendations that propose request values and show the estimated saving. AutoStopping suspends idle non-production on demand; the cluster orchestrator handles node bin-packing and spot placement on EKS; anomaly detection flags a spike while the month is still running. Acting on any of it is a code change, not a ticket. The agent adds Ask Anything on top of all this: an engineer can ask, in plain English, why a namespace's spend spiked or what to right-size next.
The outcome
Cost becomes a number teams see while they can still act on it. A namespace shows its spend beside its deployments, a right-sizing suggestion arrives with the saving already calculated, and non-production quits charging rent overnight. The monthly review stops being where the surprise lands. It becomes a check on decisions the team already made.
How teams cut what Kubernetes actually costs them
How did ConsumerTrack onboard 24 Kubernetes services in 72 hours?
ConsumerTrack's DevOps team had been hand-scripting a Jenkins pipeline for every new Kubernetes service, at roughly two weeks of work for two engineers apiece. Onboarding the next 24 services projected out to 96 weeks of effort and $290,000. Automating the path instead brought that to 72 hours, cut deployment effort by 16 hours a day, and produced $580,000 in first-year savings. That is the half of Kubernetes cost that never shows up on a cloud invoice.
"Instead of 2 DevOps Engineers spending 96 weeks manually scripting K8 pipelines, we can do the same in Harness in one week."
Jeremy Malara, DevOps Manager, ConsumerTrack
Source: ConsumerTrack onboards Kubernetes applications in 3 hours
How did Tyler Technologies reach $1.2 million in annualized savings?
Tyler Technologies builds software for the US public sector, with 40,000 client deployments across 13,000 locations. Its team had been powering down non-production infrastructure with CloudWatch alarms on a fixed schedule. That covers nights and weekends. It misses environments that sit untouched for weeks. Moving to on-demand suspension, organized around client time zones and activity, carried the company past $1.2 million in annualized savings inside six months.
"Right away we were saving $15,000 to $20,000 a month, and in only six months, we saw our first savings topping $100,000 a month."
Chris Camire, Senior Manager of Technical Services, Tyler Technologies
Where k8s cost optimization really starts: a number with an owner
That deployment from the opening is still out there, in a template, being copied into the next service. Kubernetes cost is not a spending decision anyone made on purpose. It is the residue of defaults nobody went back to check. So the fastest way to reduce Kubernetes costs is to shorten the distance between the number and the person who can change it.
Harness has a walkthrough of Intelligent Cloud AutoStopping. Or book a platform demo and bring a month of your own cluster data.
