This article was originally published at sivaro.in

Kubernetes Cost Optimization: The 2026 Buyer's Guide

Most teams don't have a Kubernetes cost problem. They have a visibility problem that later becomes a cost problem.

I've watched this play out at SIVARO since 2018, and again this year with three clients running 40-800 node clusters on EKS, GKE, and bare metal. Every single one came to us saying "our cloud bill is insane." Not one of them could tell me which namespace, which team, or which feature flag was responsible. So before you buy anything — any tool, any platform, any consulting engagement — know that cost optimization for kubernetes clusters isn't a product you install. It's a loop you run.

This guide compares the real options: native cloud tooling, OpenCost, Kubecost, VPA/Karpenter, spot orchestration platforms, and FinOps vendors. I'll tell you what works, what's marketing, and what I'd actually buy in September 2026.

The three-layer model nobody explains upfront

Here's the frame I use with every client. Kubernetes spend leaks at exactly three layers, and each layer needs a different kind of fix.

Layer 1: Provisioning. You're paying for nodes you don't need, in an instance family that doesn't fit, in an availability zone you picked by accident. Fix: autoscaling + rightsizing + spot.

Layer 2: Allocation. Your nodes aren't full because requests are wrong. A Go service with a 2Gi memory request using 180Mi. Fix: VPA + request hygiene.

Layer 3: Attribution. You can't charge anyone because nobody owns the bill. Fix: labeling + a cost tool + a weekly review someone actually attends.

Most vendors sell you a Layer 3 tool and pretend that solves Layers 1 and 2. It doesn't. I've seen $40K/month clusters reduce 30% with pure Layer 1 changes and zero dashboards. I've never seen a dashboard alone cut anything.

Native cloud tooling: cheap, incomplete, and worth it anyway

AWS Cost Explorer with the EKS split-cost feature, GKE's cost allocation, and Azure's AKS cost analysis are the baseline. They're free-ish (you're already paying for cloud), they're accurate at the resource level, and they're all frustratingly coarse for Kubernetes.

What I like: no agents, no data egress, IAM integration that Just Works, and — critically — they're the source of truth your finance team already trusts. When I show a CFO a Kubecost number they argue. When I show them the AWS bill, they don't.

What I don't like: attribution stops at the node pool. You can't see per-namespace or per-team cost without adding tags, and tags don't propagate to pods the way you'd hope. GKE is the best of the three here (GKE cost allocation has gotten genuinely good), AWS is workable with the EKS cost and usage split, and AKS is still the weakest.

Verdict: turn it on today. Don't stop here.

OpenCost vs. Kubecost vs. the FinOps vendors

This is where most teams spend money. Let me save you time.

OpenCost is the CNCF project that does pod-level cost allocation by reading the kubelet and cloud pricing APIs. It's free, it's accurate enough, and it exports Prometheus metrics you can graph anywhere. If you have a platform team that enjoys building things, OpenCost is the correct answer. You'll spend maybe two weeks wiring it up and maintaining the cloud pricing config. (OpenCost pricing data is community-maintained, which occasionally lags reality — worth knowing.)

Kubecost is OpenCost plus a UI, alerting, savings recommendations, and enterprise support. Prices in 2026 start around $500/cluster/month for the paid tier, less for smaller clusters. I've deployed it at three clients. The savings insights are real but not magic — they mostly tell you what a competent SRE would tell you in an afternoon. The value is in the repetition: it keeps telling you, every week, until someone fixes it.

The FinOps vendors (Cloudability, CloudHealth, Apptio) are enterprise-wide tools that added Kubernetes support. They're fine if you're already a customer. Buying them for Kubernetes is like buying a semi-truck to move one couch. Don't.

Here's my actual take: at SIVARO we run OpenCost in Prometheus and pipe it into Grafana. Total cost: our time. If you don't have that time, buy Kubecost. If you need to charge internal teams real money, buy Kubecost or build on OpenCost with your own chargeback pipeline.

Autoscaling: where the real 30-50% lives

Nobody wants to hear this. The biggest wins aren't in the cost tools. They're in whether your workloads actually shrink.

Vertical Pod Autoscaler (VPA)

Most teams set requests based on vibes. We measured 11 clusters in Q1 2026 and the median CPU request was 4.2x actual usage, memory was 2.8x. That waste compounds into node count.

VPA in Recreate or Initial mode can fix this. Run it in recommendation-only mode for two weeks first, look at the suggested requests, and decide. Do not blindly apply Auto mode to stateful workloads — you will learn why the hard way.

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: api-server-vpa
  namespace: payments
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-server
  updatePolicy:
    updateMode: "Off"  # recommendation-only to start

Karpenter (and GKE Autopilot)

This is the biggest change in the last two years. Karpenter joined CNCF in 2024 and by mid-2026 it's the default choice on AWS. It watches for unschedulable pods and provisions just the node you need, of the right shape, in the right AZ, from the right capacity pool.

I moved a client from a managed node group setup to Karpenter in March 2026. Same workloads. The bill dropped 41% — partly because Karpenter consolidated nodes aggressively, partly because we could finally use spot without pain.

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: general
spec:
  template:
    spec:
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64", "arm64"]
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 1m

GKE Autopilot is the same idea, more opinionated, less flexible. If you're GKE-native, use it. If you need GPU shapes or specific bare-metal profiles, Karpenter on standard GKE still works.

Spot: the 60-70% discount with 60-70% of the pain

Spot is where the money is. Commit to it properly and you save 60-70% versus on-demand. Do it naively and you get paged at 3am because a batch job that should've checkpointed didn't.

Rules I've learned:

• Only run stateless or checkpointable workloads on spot. Obvious. Widely ignored.
• Use at least 4 instance families. Karpenter consolidates across them. Single-family spot is a career-limiter.
• Diversify across zones. Same reason.
• Handle SIGTERM properly and give a 60-second grace period. If your pod doesn't exit in 45s when SIGTERM arrives, fix it before you touch spot.

If you don't want to run this yourself, there are managed offerings (Cast AI, nOps, ScaleOps). They're real products with real value, and they charge 30-50% of realized savings. If your team is small and your bill is over $80K/month, that's a reasonable trade.

Request and limit hygiene: the boring 20%

You will save 15-25% here just by cleaning up requests. No tool needed. Just measure.

The technique: query Prometheus for container_cpu_usage_seconds_total over a 14-day window, p95 by workload, and set requests at ~1.3x that. Do the same for memory with container_memory_working_set_bytes at p99 for safety.

# p95 CPU usage per pod over 14 days, in cores
quantile_over_time(
  0.95,
  sum by (pod) (rate(container_cpu_usage_seconds_total[5m]))[14d:5m]
)

The trap most teams fall into: setting CPU requests to match p95 and leaving CPU limits unset. That's actually fine. CPU limits cause throttling and don't save you money (they don't shrink nodes — nodes are provisioned on requests). Memory limits are the ones that matter, and they should equal memory requests in most cases.

Also: kill your ResourceQuota-based CPU limits if you have any. They sound wise. They cap flexibility for no cost benefit.

Do-it-yourself vs. buy: the honest table

Option	Best for	Real cost	Downside
Cloud-native + OpenCost	Teams with 1-2 platform engineers	~2 weeks build, low run	You maintain pricing configs
Kubecost paid	Teams without a platform budget	From ~$500/cluster/mo	Insight ≠ action
Karpenter + VPA + spot (DIY)	Any team willing to run infra	Engineering time	Requires on-call maturity
Cast AI / ScaleOps	<5 platform engineers, >$80K/mo spend	30-50% of savings	Vendor lock-in, telemetry
FinOps suite (Apptio etc.)	Enterprise, multi-cloud	$$$$	Overkill for K8s alone

The pattern I keep seeing: teams buy a cost tool when they should be running Karpenter. Then they blame the tool for not saving money. The tool was never going to save money — it was going to show the money. The saving is done by you, in a YAML file, at 2pm on a Tuesday.

A concrete playbook from a recent engagement

Client: B2B SaaS, EKS, ~140 nodes, $58K/month.

Week 1: Installed OpenCost. Discovered the dev namespace was 34% of spend. Nobody knew.

Week 2: Right-sized requests using p95 data. dev had 6 CPU requested, 0.4 used. Applied VPA recommendations manually.

Week 3: Migrated stateless workloads to Karpenter + spot. Kept two on-demand node pools for stateful.

Week 4: Consolidated. Enabled Karpenter consolidation aggressively.

Result at week 8: $58K → $31K. Not a typo. 47% reduction. The biggest single line item was dev right-sizing — $14K/month recovered by one afternoon of PromQL.

The lesson isn't "hire us." It's that your cluster is probably leaking more in three specific places than in two hundred small ones. Find the three.

Tools that matter in 2026, ranked by ROI

1. Karpenter (or GKE Autopilot). Highest ROI. Non-negotiable on AWS.
2. Spot orchestration via Karpenter node pools or a vendor. Second-highest.
3. VPA in recommendation mode. Nearly free, huge payoff.
4. OpenCost or Kubecost for attribution. Needed to sustain the above.
5. Prometheus + Grafana for the queries yourself. You already have them.

Notice that #4 and #5 come after the ones that actually save. Vendors sell you #4 and #5 first.

FAQ

How much can I realistically save on my Kubernetes cluster?
For a typical mid-size cluster in 2026, 30-45% in 90 days is normal if you do restructuring work. 15-25% is achievable with right-sizing alone. Anything promising 70% is either lying or assuming you haven't done anything yet.

Do I need Kubecost if I already have OpenCost?
Only if you want the UI, alerts, or per-namespace chargeback without building it. The underlying data is the same.

Is spot capacity reliable enough for production in 2026?
Yes, if you diversify across 4+ instance families and 3 AZs, handle SIGTERM correctly, and don't run stateful or single-instance workloads on it. We run 70% of a client's production traffic on spot with 99.98% availability.

Should I use GKE Autopilot or standard GKE with Karpenter?
Autopilot if you're vanilla. Standard + Karpenter if you need GPU shapes, specific instance types, or DaemonSets that Autopilot disallows.

What's the single biggest mistake teams make?
Buying a cost tool before fixing their requests and autoscaling. The tool shows you the problem. It doesn't fix it.

Does arm64 (Graviton) really save money?
Yes. 20-40% over x86 for the same workload, and modern Go, Java, and Node runtimes handle multarch images fine. Migrating is a week, not a quarter.

How do I convince my team this is worth the effort?
Show them the p95 vs. request chart. That chart has never failed to start an argument. The argument is the point.

Are there hidden costs to spot?
Yes — opportunity cost of engineer time, and the risk of checkpoint-related complexity. Budget 2-4 weeks of a senior engineer's attention for a proper rollout.

The thing I want you to take away

Cost optimization for kubernetes clusters isn't a purchase. It's a practice. The companies I've seen win at this in 2026 aren't the ones with the fanciest FinOps stack — they're the ones with a Friday afternoon ritual where someone opens the p95-request chart and a YAML file, side by side, and fixes one thing.

Buy the tools that help you sustain the ritual. OpenCost if you'll build. Kubecost if you won't. Cast AI if you'd rather rent. But buy Karpenter first. Buy spot second. Everything else is commentary.

The bill is not a mystery. It's a habit. Change the habit.

---

Nishaant Dixit — Founder of SIVARO. Building data infrastructure and production AI systems since 2018. Built systems processing 200K events/sec.