90%
90% of Kubernetes deployments are complete overkill.
I've seen teams spend 6 months setting up K8s for an app that serves 500 users.
I'm a DevOps engineer. I LOVE Kubernetes.
But I'm going to tell you why you probably shouldn't use it.
The Kubernetes Industrial Complex
Why does everyone push Kubernetes?
Resume-Driven Development
K8s looks great on LinkedIn. "Kubernetes" is the magic word that gets recruiters excited.
Engineers push for K8s not because it's the right solution, but because it's a career move.
Vendor Lock-In
Consulting firms love Kubernetes. Why?
Complexity = recurring revenue.
The more complex your infrastructure, the more you need consultants to maintain it.
Certification Industry
CKA certification: ~$400 CKS certification: ~$400 CKAD certification: ~$400
Training courses, boot camps, practice exams... Kubernetes education is a billion-dollar industry.
Nobody profits from teaching you that Docker Compose is enough.
Cloud Provider Margins
Managed Kubernetes costs 2-3x more than simpler solutions.
EKS, GKE, AKS — they all want you on K8s because it increases your cloud bill.
The Honest Checklist
You DON'T need Kubernetes if:
1. Your App Has Fewer Than 100K Daily Users
At this scale, a single VM with Docker handles everything. Kubernetes adds operational overhead that isn't justified by the scale.
2. Your Team Is Smaller Than 5 Engineers
Kubernetes requires dedicated attention. If nobody has time to become a K8s expert, you're setting up a ticking time bomb.
3. You're Not Deploying Multiple Times Per Day
K8s shines with continuous deployment. If you deploy weekly, the complexity isn't worth it.
4. Your Traffic Is Predictable
K8s auto-scaling is amazing for variable load. If your traffic is stable, you're paying complexity tax for nothing.
5. You Don't Have Multiple Services
One monolith? K8s is overkill. The orchestration benefits kick in with multiple services.
What To Use Instead
Azure Container Apps / AWS App Runner
- Dead simple
- Auto-scaling built in
- No YAML manifests to maintain
- Pay per request, not per cluster
Docker Compose on a VM
I know this sounds crazy.
For most apps, a single VM with Docker Compose works. It's boring. It's simple. It ships features.
Boring is a feature, not a bug.
Platform-as-a-Service
Railway, Render, Fly.io — these platforms handle infrastructure so you don't have to.
Zero infrastructure management. Ship features instead of maintaining clusters.
Serverless
For suitable workloads (event-driven, stateless), Lambda/Azure Functions are simpler and cheaper than maintaining containers.
The Real Cost of Kubernetes
Before choosing K8s, calculate the TRUE cost:
Direct Costs
- Managed K8s service: $200-2000/month minimum
- Worker nodes: $500-5000/month depending on scale
- Load balancers, storage, networking: $200-1000/month
Hidden Costs
- Learning curve: 2-6 months for team to be proficient
- Maintenance time: 5-10 hours/week of cluster care
- Incident complexity: K8s issues are HARD to debug
- Hiring: K8s engineers command premium salaries
Opportunity Cost
Every hour spent on K8s is an hour NOT spent on:
- Product features
- Customer problems
- Business value
Is your Kubernetes cluster a competitive advantage? Or is it complexity for complexity's sake?
When Kubernetes DOES Make Sense
I'm not anti-K8s. I use it professionally. Here's when it's the right choice:
100+ Microservices
When you have genuine orchestration needs across many services, K8s pays for itself.
Multi-Cloud Requirements
Need to run the same workload on AWS, Azure, AND GCP? K8s provides genuine portability.
Unpredictable Scale
If you experience 10x traffic spikes, K8s auto-scaling is worth the complexity.
Dedicated Platform Team
If you have engineers whose JOB is maintaining infrastructure, K8s is a great tool for them.
Notice the Pattern
These are BIG company problems. Not startup problems.
If you're a 10-person startup with Kubernetes, you're probably optimizing the wrong thing.
The Decision Framework
Do you have 100+ microservices?
├── Yes → Consider K8s
└── No → Do you have unpredictable 10x scale?
├── Yes → Consider K8s
└── No → Do you need multi-cloud?
├── Yes → Consider K8s
└── No → Do you have a dedicated platform team?
├── Yes → K8s might be fine
└── No → USE SOMETHING SIMPLER
The Conversation to Have
Next time someone proposes Kubernetes, ask:
- What problem does K8s solve that simpler solutions don't?
- Who will maintain the cluster long-term?
- What's the total cost of ownership over 3 years?
- What features could we ship with that time/money instead?
If the answers are vague, the proposal is resume-driven.
My Confession
I've set up Kubernetes clusters that didn't need to exist.
I did it because it was fun. Because I wanted to learn. Because it looked good on my resume.
Looking back, simpler solutions would have served those projects better.
The best infrastructure is the one you don't have to think about.
Sometimes that's Kubernetes. Usually, it's not.
The Takeaway
Kubernetes is an incredible tool for the problems it solves.
But it solves big company problems.
If you're not a big company, you might be importing big company complexity without big company benefits.
Choose boring technology. Ship features. Let someone else maintain the cluster.
Sometimes the best architecture is the simplest one.