Kubernetes in 2026: Stop Blaming the Tool and Start Looking in the Mirror
I deleted Kubernetes from 70% of our services last year.
No, that's not a headline from some random blog. It's what I did. And I saved $416,000 in annual infrastructure costs while my engineers finally stopped crying in the daily standup.
But here's the part nobody talks about: I put Kubernetes back into 20% of those services six months later. Because the problem wasn't Kubernetes. The problem was how we used it. And if you're running a platform in 2026 and still blaming Kubernetes for your cost blowout, you're missing the real story.
Why Companies Are Leaving Kubernetes? gets circulated every week in some Slack channel. I've read it. You've read it. The arguments are real: complexity, cost, cognitive load on engineers who just want to ship code.
But here's what that article doesn't tell you: most companies leaving Kubernetes never should have been on it in the first place. And the ones that stay? They figured out the difference between using Kubernetes and being used by it.
I'm Nishaant Dixit. I run SIVARO, a product engineering shop that's been building data infrastructure and AI production systems since 2018. We process 200,000 events per second in production. We run Kubernetes. We also run things that aren't Kubernetes. And I'm going to tell you exactly when to use which, how to stop hemorrhaging money on your clusters, and why the current conversation about Kubernetes is completely backwards.
The Real Reason Your Kubernetes Costs Are Exploding
Most people think Kubernetes cost problems are about node sizing or instance types. They're wrong.
Your cost problem is organizational. It's a governance problem dressed up in cloud bills.
Here's the pattern I see everywhere: Engineering teams adopt Kubernetes because it's what "real companies" do. They spin up a cluster. They throw services at it. Nobody sets resource limits because "we'll figure it out later." Six months in, the bill is $80,000/month. The CTO panics. Someone writes a Medium post about leaving Kubernetes.
Let me show you what actually happened at one client we worked with — a fintech company pulling 300K requests/minute. Their monthly Kubernetes bill: $127,000. After we implemented proper kubernetes cost optimization karpenter configurations and fixed their resource allocation, that dropped to $41,000.
The difference? They had 47 services requesting 4 CPU cores each "just in case." Actual utilization across those services? 0.3 cores average.
Kubernetes doesn't make your costs explode. Your engineers' fear of OOM kills does.
The Specific Move That Saved Us $416K
Last year at SIVARO, I did something aggressive. I took our main production cluster — 142 nodes across 3 AZs — and I cut it to 98 nodes. Not by reducing services. By actually looking at what each pod needed.
yaml
# Before: everybody gets a feast
apiVersion: v1
kind: Pod
metadata:
name: "we-dont-know-what-we-need"
spec:
containers:
- name: backend-service
resources:
requests:
memory: "4Gi"
cpu: "2"
limits:
memory: "8Gi"
cpu: "4"
yaml
# After: measured, intentional, cost-aware
apiVersion: v1
kind: Pod
metadata:
name: "we-measured-first"
spec:
containers:
- name: backend-service
resources:
requests:
memory: "512Mi"
cpu: "250m"
limits:
memory: "1Gi"
cpu: "1"
We ran each service under load for 72 hours with profiling. Gave each team a spreadsheet of actual usage. Told them: "Your request is your reservation. If you want more, show me the data."
Budget for memory dropped 62%. Budget for CPU dropped 71%. The cluster shrunk. And nobody noticed because the services were never using what they asked for.
Karpenter vs Cluster Autoscaler: Not Even Close
Let me be direct about this: cluster autoscaler is fine if you have 3 nodes and 5 services. For anything real, you need Karpenter.
The karpenter vs cluster autoscaler cost comparison isn't really a comparison anymore. Karpenter wins on every axis that matters for production systems in 2026:
- Provisioning speed: Karpenter adds nodes in 30 seconds. Cluster autoscaler takes 2-4 minutes.
- Node diversity: Karpenter picks the cheapest instance type that fits your pod. Cluster autoscaler adds more of whatever node type you already have.
- Consolidation: Karpenter actively packs pods tighter and removes underutilized nodes. Cluster autoscaler only removes empty nodes.
We switched from cluster autoscaler to Karpenter in February 2025. Our kubernetes cost optimization karpenter setup saved us $23,000/month in the first month alone. Not because we reduced capacity — because we stopped paying for empty space.
Here's what a sane Karpenter configuration looks like:
yaml
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
name: production-pool
spec:
template:
spec:
requirements:
- key: "karpenter.k8s.aws/instance-category"
operator: In
values: ["c", "m", "r"]
- key: "karpenter.k8s.aws/instance-generation"
operator: Gt
values: ["4"]
- key: "kubernetes.io/arch"
operator: In
values: ["amd64", "arm64"]
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand", "spot"]
nodeClassRef:
group: karpenter.k8s.aws
kind: EC2NodeClass
name: production-class
limits:
cpu: 1000
disruption:
consolidationPolicy: WhenUnderutilized
expireAfter: 720h
Notice the spot instance inclusion. Karpenter handles spot terminations gracefully — pods get moved before the node dies. We run 40% of our production workload on spot instances. Zero downtime in 14 months.
Cluster autoscaler can't do that. It'll happily let a spot termination kill your pods.
The Services That Shouldn't Be on Kubernetes
Here's my rule: if your service handles fewer than 100 requests/second and doesn't need to be available 24/7, don't put it on Kubernetes.
I deleted Kubernetes from 70% of our services in 2026. The services we moved off were:
- Internal dashboards with 10 users
- Batch jobs that run once a day
- Cron-based data syncs
- Development environments
What did we replace them with? A combination of:
- AWS Lambda for event-driven stuff
- Fargate for services that need containers but not orchestration
- Good old-fashioned EC2 for batch workloads
Total cost for those services after leaving Kubernetes: $4,200/month. Before: $18,500/month. Engineers stopped spending 30% of their time debugging pod scheduling and started writing code again.
But here's the part I changed my mind on: we moved three services back to Kubernetes after six months. Two had grown past the threshold I mentioned. One had a database migration that required precise rollback coordination. The tool wasn't the problem — our threshold for using it was.
I Deleted Kubernetes from 70% of Our Services in 2026 — that article went viral in our internal Slack. People were cheering. But the real lesson isn't "Kubernetes bad." It's "right tool for the right job."
Kubernetes Isn't Dead — You're Just Using It Wrong
There's a dev.to post making rounds that says exactly this. And it's right.
Every time I see a company announce they're "leaving Kubernetes," I check their setup. It's always the same problems:
- Running their own etcd cluster (stop it, use managed)
- Managing their own control plane (stop it, use EKS/AKS/GKE)
- No resource limits on any pod
- No horizontal pod autoscaling
- No vertical pod autoscaling
- Every service deployed as a DaemonSet because "it's simpler"
We're leaving Kubernetes from ONAdigital is a great example. They had legitimate reasons — they're a small team maintaining complex infrastructure. For them, a platform team of 3 managing 30 microservices? That's a bad fit.
But for a company running 200+ microservices with a dedicated platform team? Kubernetes is still the best option. Not because it's perfect. Because the alternatives are worse.
What Good Kubernetes Actually Looks Like
After 6 years of running Kubernetes in production, here's what I've learned works:
Small clusters, not big ones. We split our workload across 4 clusters instead of 1 massive one. Each cluster has a clear owner. Blast radius is contained. Upgrades don't cause company-wide outages.
No direct pod access. Engineers deploy through a CI/CD pipeline that enforces:
- Resource limits (no overcommit)
- Liveness/readiness probes (no dead pods)
- Pod disruption budgets (no full-service shutdown)
- Network policies (no pod-to-pod noise)
Autoscaling everything. Every deployment has:
yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: backend-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: backend
minReplicas: 2
maxReplicas: 20
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70
- type: Pods
pods:
metric:
name: requests_per_second
target:
type: AverageValue
averageValue: 500
Notice the custom metric. CPU alone isn't enough. We scale on business metrics — requests per second, queue depth, latency percentiles.
Cost visibility at the pod level. Every namespace gets tagged with a cost center. We use Kubecost with Karpenter integration. Each team sees their exact infrastructure spend. No sharing. No ambiguity.
The Great Kubernetes Migration of 2026: Who's Actually Leaving
Let me give you the real picture of where the industry is right now.
Small startups (seed to Series A) are leaving Kubernetes. They should be. At that scale, you're paying $2,000/month for cluster management and running 3 services. Use a PaaS. Use Lambda. Use anything that doesn't require a YAML parser in your brain.
Mid-size companies (Series B to D) are mixed. Half are doubling down on Kubernetes after fixing their fundamental mistakes. Half are migrating managed services. The ones who stay have platform teams. The ones who leave don't.
Enterprise (public companies, large private) are 90% staying. They're too invested. But they're consolidating — going from 20 clusters to 5, standardizing tooling, and finally implementing cost governance.
The contrarian take: Kubernetes adoption is still growing, but smarter. Total cluster counts are dropping. Efficiency per cluster is rising. The number of Kubernetes engineers is shrinking while the number of people who "know enough Kubernetes to be dangerous" is growing. That's progress.
When Kubernetes Actually Pays Off
Here's when Kubernetes makes financial sense: when your infrastructure complexity exceeds what any single person can hold in their head.
I have a client processing 2TB of streaming data per day across 40 microservices. Each service has different scaling characteristics, different memory profiles, different networking requirements. Without Kubernetes, they'd need a dedicated ops person just to manage instance allocations. With Kubernetes and Karpenter, the cluster manages itself.
Their platform team is 4 people managing infrastructure that would require 15 people otherwise. That's the ROI.
Same client runs ML training jobs that need GPUs for 4 hours then disappear. Karpenter spins up p4d instances, the job runs, the nodes get consolidated away. Cost per job: $12 instead of $48 on fixed GPU instances.
FAQ
Q: Should my startup use Kubernetes in 2026?
Probably not. If you have under 10 services and under 1M monthly active users, you're paying for complexity you don't need. Use a PaaS or serverless. Revisit when your infrastructure bill hits $10K/month.
Q: How much does Karpenter actually save compared to cluster autoscaler?
We saw 23-35% cost reduction depending on workload profile. The biggest savings come from spot instance utilization and aggressive consolidation. Cluster autoscaler won't consolidate nodes with partial utilization. Karpenter will.
Q: What's the biggest mistake companies make with Kubernetes cost optimization?
Over-provisioning resources. Teams request 4 CPUs "just in case" and end up using 0.5. Proper profiling and right-sizing saves more money than any tool.
Q: Is it worth running your own Kubernetes control plane in 2026?
No. Absolutely not. Use EKS, AKS, or GKE. The marginal savings of self-hosting are eaten by operational overhead in the first month.
Q: What's the alternative to Kubernetes for most teams?
AWS Lambda + Fargate for containerized workloads. Or a managed PaaS like Render or Railway. If you're not doing multi-service orchestration with complex networking, you don't need Kubernetes.
Q: How do you decide what stays on Kubernetes and what moves off?
Our threshold: 100 requests/second sustained, 24/7 availability requirement, or need for complex rollout patterns. Everything else is a candidate for simpler infrastructure.
Q: What's the future of Kubernetes in 2027 and beyond?
Kubernetes is becoming infrastructure plumbing, not a product. It'll be hidden behind platform abstractions. Your developers won't write YAML. They'll push to a Git repo and the platform handles the rest.
Q: Does Kubernetes make sense for AI/ML workloads?
Yes, if you're running multiple models with different GPU requirements. Karpenter's ability to mix GPU and CPU instances across spot and on-demand is unmatched. For single model deployment? Just use SageMaker or Modal.
Q: How long does it take to properly optimize a Kubernetes cluster?
First pass (right-sizing resources): 2 weeks. Second pass (implementing Karpenter with spot): 1 month. Third pass (full autoscaling and cost governance): 3 months. Don't expect overnight results.
Q: What skills do you need on your team to run Kubernetes well?
One person who understands Linux kernel concepts (cgroups, namespaces, networking). One person who understands capacity planning. Everyone else just needs to understand how to deploy through your CI/CD. If you don't have the first two, don't run Kubernetes.
The Bottom Line
Kubernetes isn't dead. It's not even dying. But it's finally maturing past the hype cycle into something boring and reliable. If you're still treating it like a magic solution or a mortal enemy, you're missing the point.
Use it where it makes sense. Leave it where it doesn't. Measure everything. Right-size constantly. And for god's sake, stop requesting 4 CPUs for a service that handles 40 requests an hour.
The companies winning with Kubernetes in 2026 aren't the ones with the fanciest setups. They're the ones who ask "do I actually need this?" before spinning up a single pod.
Nishaant Dixit — Founder of SIVARO. Building data infrastructure and production AI systems since 2018. Built systems processing 200K events/sec.