Kubernetes in 2026: What Works, What Doesn't, and What We Got Wrong

Stop 3AM Pages

Free K8s Audit

I spent last Tuesday helping a founder untangle a Kubernetes cluster that was hemorrhaging $47,000 a month.

Not because Kubernetes is bad. Because they'd built a fleet of oil tankers to deliver pizzas.

This is the story I see every week. Teams adopt Kubernetes for the promise — auto-scaling, portability, resilience — and end up with a $400,000 annual bill for infrastructure they don't need, maintained by engineers who'd rather be building product.

Let me be direct: Kubernetes isn't dead. But how most teams use it? That's what's dying in 2026.

I'm Nishaant Dixit, founder of SIVARO. We build data infrastructure and production AI systems. We've run Kubernetes in production since 2019. We've also deleted it from stacks where it didn't belong. This guide is what I've learned — the hard way, with real money on the line.

You'll learn when Kubernetes makes sense, when it doesn't, how to stop hemorrhaging cash on it, and the specific tools (like Karpenter) that fix its worst cost problems. And yes, I'll tell you the exact numbers.

The Kubernetes Hangover of 2024-2026

Here's what happened.

Between 2018 and 2023, Kubernetes became the default answer to every infrastructure question. "How do we deploy?" Kubernetes. "How do we scale?" Kubernetes. "What's for lunch?" Kubernetes.

Then came the reckoning.

In 2024, Ona announced they were leaving Kubernetes. Not because it's bad — because for their use case, it was an anchor. They weren't running microservices at scale. They were running a handful of applications. Kubernetes was adding complexity, not removing it.

By 2025, the pendulum swung hard. A team at a mid-stage fintech deleted Kubernetes from 70% of their services in 2026, saved $416K, and their engineers finally stopped quitting (source). Their story isn't unique.

I've seen the DevOps survey data. Companies leaving Kubernetes cite three things consistently:

Cost overruns (40-60% above projected)
Engineering overhead (2-3 full-time people just to keep it running)
It doesn't solve the actual problem (their apps didn't need it)

But here's the contrarian take: Kubernetes isn't dead. You just misused it.

The tool isn't the problem. The cargo-cult adoption is.

When Kubernetes Actually Makes Sense

Let me save you six months of pain.

Use Kubernetes when:

You run 10+ microservices that need independent scaling
Your traffic varies by 10x or more daily (think SaaS, e-commerce, ad tech)
You have 3+ engineers who understand distributed systems
You need multi-cloud or hybrid cloud portability
Your deployment frequency is multiple times per day

Don't use Kubernetes when:

You have 1-5 services (use a simple VM or serverless)
Your traffic is predictable (use reserved instances, save 50%)
You have one engineer trying to do everything (Kubernetes will break them)
You're a startup trying to move fast (Kubernetes slows you down early)

Startups: I get it. You want to build like Google. But Google had 50,000 engineers when Borg (Kubernetes's ancestor) was born. You have five.

The real play? Start simple. Move to Kubernetes when it hurts not to. Not before.

The Cost Problem Nobody Talks About Honest

Let's talk money.

The typical Kubernetes cluster I see wastes 35-50% of provisioned capacity. Not because of bad engineering — because of bad defaults.

Standard Kubernetes comes with the Cluster Autoscaler. It works. Kinda. It scales up when pods are pending, scales down when nodes are underutilized. But here's the problem: it's reactive. It takes 2-5 minutes to provision new nodes. And it can't choose the cheapest instance type — it only works with node groups you pre-define.

This matters because:

You over-provision "just in case" (and pay for idle capacity)
You can't use spot instances effectively (Cluster Autoscaler won't diversify across instance types)
You waste money on large nodes (because you sized node groups for peak demand)

We ran a 30-node cluster at SIVARO using standard Cluster Autoscaler. Monthly compute cost: $21,000. After switching, we dropped to $8,400. I'll show you how.

Enter Karpenter

Karpenter is the open-source node provisioning tool from AWS. It fixes the fundamental design flaw of Cluster Autoscaler: instead of managing node groups, it manages nodes directly.

Here's the difference in practice.

Cluster Autoscaler: "I see pending pods. I'll add another node to the 'general-purpose' node group. Hope the instance type fits."

Karpenter: "I see pending pods. I need exactly 2.7 CPUs and 4GB RAM. I'll pick the cheapest Spot instance across 47 instance types that satisfies this. And I'll consolidate existing nodes first."

The savings come from three things:

Bin packing (15-25% improvement) — Karpenter packs pods tighter, leaving less waste
Spot diversification (30-50% savings) — It uses spot instances without the fear of mass termination because it spreads across types
Right-sizing (10-15% savings) — It picks the instance that fits your workload, not a pre-sized group

For the full comparison, check karpenter vs cluster autoscaler cost comparison — the research shows Karpenter users typically see 30-55% cost reduction.

Here's the provisioning config we use:

yaml
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      requirements:
        - key: "karpenter.sh/capacity-type"
          operator: In
          values: ["spot", "on-demand"]
        - key: "node.kubernetes.io/instance-type"
          operator: In
          values: ["m5.large", "m5.xlarge", "m6i.large", "m6i.xlarge", "c5.xlarge", "c6i.xlarge"]
      nodeClassRef:
        name: default
  limits:
    cpu: 1000
  disruption:
    consolidationPolicy: WhenUnderutilized
    expireAfter: 720h

That consolidationPolicy: WhenUnderutilized line? That's the magic. Karpenter will actively replace nodes with cheaper/fewer nodes if it can. Cluster Autoscaler never does this.

Why "Kubernetes Cost Optimization Karpenter" Is the Best Search You'll Run This Year

I'm serious. If you're running Kubernetes on AWS and not using Karpenter, you're burning money.

We implemented kubernetes cost optimization karpenter in August 2025. By September, our compute costs dropped from $21K to $12K. By December, we hit $8,400 after tuning.

The biggest single change? Letting Karpenter use all available spot instance types instead of limiting to three. We saw an immediate 28% drop.

Here's a script to estimate your savings:

bash
#!/bin/bash
# Quick savings estimator for Karpenter vs Cluster Autoscaler
# Run against current cluster state

echo "=== Current Cluster Analysis ==="
echo "Node count: $(kubectl get nodes --no-headers | wc -l)"
echo "Total CPU: $(kubectl get nodes -o json | jq '[.items[].status.capacity.cpu | tonumber] | add')"
echo "Total Memory (GB): $(kubectl get nodes -o json | jq '[.items[].status.capacity.memory | split("Ki")[0] | tonumber / 1048576] | add')"

echo ""
echo "=== Estimated Savings ==="
echo "Bin packing improvement: 15-25%"
echo "Spot savings: 30-50% (if <50% currently spot)"
echo "Right-sizing savings: 10-15%"
echo "Total estimated reduction: 35-55%"

The Real Reason Teams Are Leaving (It's Not What You Think)

I read Why Companies Are Leaving Kubernetes and nodded at every point. But the surface reasons — cost, complexity — miss the deeper problem.

Kubernetes forces you to solve problems you don't have.

You don't have a service mesh problem? Too bad — everyone's blog says you need Istio. You don't have a multi-cluster problem? Doesn't matter — you're now managing RBAC across namespaces. You don't need sidecars? Sorry, that's how we do observability here.

The Kubernetes ecosystem is a solution in search of problems. And it's good at creating those problems.

At SIVARO, we run Kubernetes for exactly two patterns:

Stateless microservices that scale independently
Batch ML inference jobs that need ephemeral compute

Everything else — databases, caches, queues — runs outside Kubernetes. On VMs or managed services. Because running Postgres on Kubernetes is an exercise in masochism that only makes sense if you have the SRE team of Netflix.

The teams leaving Kubernetes successfully? They kept it for the services that needed it. Moved everything else to simpler platforms.

The Stuff That Actually Makes Kubernetes Work

Enough theory. Here's the playbook we follow at SIVARO.

Pod Resource Requests: The Single Most Expensive Mistake

Most teams set requests too high (waste) or don't set limits (unpredictable). Here's what we do:

yaml
apiVersion: v1
kind: Pod
metadata:
  name: api-server
spec:
  containers:
  - name: app
    image: sivaro/api-server:latest
    resources:
      requests:
        cpu: "500m"    # Based on P99 usage over 7 days
        memory: "512Mi"
      limits:
        cpu: "1"       # Burst up to 2x request
        memory: "1Gi"  # Hard limit, no swap

The trick: use the Vertical Pod Autoscaler in "recommender" mode for 7 days. It tells you the actual resource usage. Then set requests to the P99. Not the average — the P99.

We cut resource requests by 40% across our cluster doing this. No performance impact.

Spot Instances: The 50% Savings You're Leaving on the Table

Most teams are scared of spot instances. They shouldn't be.

The fear: "What if my spot gets reclaimed?" The reality: AWS gives you 2 minutes notice. If you handle pod eviction gracefully, it's a non-issue.

Here's how we run 70% spot:

yaml
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: spot-default
spec:
  template:
    spec:
      requirements:
        - key: "karpenter.sh/capacity-type"
          operator: In
          values: ["spot"]
      taints:
        - key: "spot"
          value: "true"
          effect: "NoSchedule"
  disruption:
    consolidationPolicy: WhenUnderutilized
    expireAfter: 720h
---
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: on-demand
spec:
  template:
    spec:
      requirements:
        - key: "karpenter.sh/capacity-type"
          operator: In
          values: ["on-demand"]
---
# Pod Disruption Budgets
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: api-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: api-server

Spot for batch workloads, stateless services. On-demand for critical control planes and stateful stuff. Karpenter handles the rest.

The Cluster Autoscaler vs Karpenter Decision

Let's settle this.

If you're on AWS and have more than 10 nodes, use Karpenter. Full stop.

The karpenter vs cluster autoscaler cost comparison is not even close at scale. Karpenter is faster, cheaper, and more flexible. The only reason to stick with Cluster Autoscaler is if you're heavily invested in Terraform-managed node groups and can't change.

But even then — migrate. It's a weekend project. The ROI is 30-50% monthly savings.

When Kubernetes Fails: The Warning Signs

I can tell within 15 minutes if a team should drop Kubernetes.

You have a "Kubernetes team" of 3+ people. That's your first sign. If you need multiple full-time people just to operate the infrastructure, you're not getting value from it. The platform should be invisible.

Your deployment process takes 30+ minutes. Kubernetes should make deploys faster, not slower. If you're wrestling with Helm charts and YAML sprawl, something is wrong.

You have more than 5 CRDs. Custom Resource Definitions are a drug. They feel powerful. But every CRD is a dependency you're now maintaining. Kill them.

Your CI/CD pipeline does "kubectl apply" to 50+ manifests. You've created a configuration management problem, not solved one. Use Kustomize or Helm to template things, but keep it simple.

I saw a team with 47,000 lines of YAML across 200+ files. They had three people whose only job was maintaining that YAML. That's not Kubernetes working — that's Kubernetes as a job creation scheme.

The Future: What Kubernetes Looks Like in Late 2026

We're seeing the normalization of Kubernetes.

The hype is dead. The anti-hype is also dying. What's left is a tool that solves a specific set of problems — distributed, scalable service orchestration — and does it well.

The trends I'm watching:

Serverless Kubernetes is eating the market. GKE Autopilot, EKS Fargate, Azure Container Instances — these remove node management entirely. You lose some control, but for 80% of workloads, you don't need that control.

Sidecars are dying. The new generation of eBPF-based observability and mesh tools doesn't need sidecars. Cilium, Istio ambient mesh, Envoy's new proxy model — all moving to sidecarless patterns. This cuts resource usage 20-30%.

Kubernetes cost optimization is becoming its own discipline. Tools like Karpenter, Kubecost, and automation for rightsizing are standard now. The teams that don't adopt them are the ones leaving Kubernetes.

FAQ: What I Actually Tell Founders and CTOs

Q: Should my startup use Kubernetes?
Probably not. Not until you have 10+ services and 3+ backend engineers. Before that, use a simple PaaS or container service. I recommend Fly.io or Railway for startups.

Q: How do I reduce my Kubernetes bill right now?
Three steps: (1) Install Karpenter, (2) Switch to 70% spot instances, (3) Use VPA recommender to right-size requests. Do this in the next week. Expect 30-55% savings.

Q: Kubernetes vs ECS for AWS-only workloads?
ECS is simpler. Kubernetes is more portable. If you're never leaving AWS, ECS is probably better. We use Kubernetes because we run across AWS and GCP for latency.

Q: Should I run stateful workloads on Kubernetes?
Only if you have the team. Running Postgres or Kafka on Kubernetes is doable but requires deep expertise. For most teams, use managed databases. We do.

Q: Is Karpenter worth the migration from Cluster Autoscaler?
Yes. We saw a 60% reduction in node count while running the same workloads. The migration took 2 days. The savings pay for a month of a senior engineer.

Q: What about multi-cluster Kubernetes?
Don't. Until you need it. Multi-cluster adds massive complexity. The teams that succeed with it have dedicated platform teams. For everyone else, one cluster with good namespace isolation is fine.

Q: How do I convince my team to simplify our Kubernetes setup?
Show them the numbers. Run Kubecost for a month. Show the waste. Then show them how much simpler life is without unnecessary CRDs, service meshes, and complex deployment pipelines.

Q: Is Kubernetes dead in 2026?
No. But the cargo-cult adoption is. Kubernetes for the right reasons — distributed scaling, portability, ecosystem — is still valuable. Kubernetes because "that's what big companies use" is a path to pain.

The Takeaway

I've built systems processing 200K events per second on Kubernetes. I've also deleted clusters that were costing startups $30K/month for no benefit.

The pattern is always the same: teams adopt Kubernetes before they need it. They add complexity before they have the skills to manage it. They burn money on over-provisioned infrastructure.

Then they blame Kubernetes.

But Kubernetes isn't the problem. It's a tool. A powerful one with sharp edges. If you use it correctly — for the workloads that need it, with the right cost optimization tools like Karpenter, and only when you've outgrown simpler options — it's incredibly effective.

If you don't? You'll join the exodus.

My advice: be honest about what you need. Run the numbers. And for the love of everything, stop running databases on Kubernetes.

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