Kubernetes is orchestration for running containers at scale across multiple machines. For most teams, it’s overkill. Use Kubernetes when you have enough traffic to need multiple servers, enough complexity to justify the operational overhead, and enough money to run it. Most startups should use managed platforms (Heroku, Railway, Vercel) instead. When Kubernetes makes sense, it’s powerful. When it doesn’t, it’s a headache you didn’t need.
The Talk That Made Me Nervous
A CTO stood up and said their startup with 50 daily active users was switching to Kubernetes. “Industry standard,” he said. “Everyone uses it.”
Six months later, they’d spent 2 developers’ time on Kubernetes operations, still had 50 daily active users, and a critical bug shipped because the team was busy debugging cluster networking instead of writing features.
That’s when I learned: Kubernetes solves a real problem. But most teams don’t have that problem yet.
What Kubernetes Actually Is (And Isn’t)
Kubernetes is a platform for orchestrating containerized applications across multiple machines. It handles deployment, scaling, networking, storage, and recovery automatically. The key benefit is that you describe what you want to run, and Kubernetes makes it happen—managing resources, replacing failed containers, distributing load.
Kubernetes is NOT:
- A requirement for Docker (you can run Docker without Kubernetes)
- A hosting platform (you need servers to run it on)
- Simple (it’s notoriously complex)
- Necessary for most teams (it’s overkill until you’re big)
Kubernetes IS:
- A way to run many containers across many servers
- A way to handle failures automatically (if a container dies, another starts)
- A way to scale automatically (if traffic spikes, more containers start)
- A way to manage updates with zero downtime
For teams with one server running 10 containers, you don’t need Kubernetes. For teams with 50 servers running 500 containers handling millions of requests, Kubernetes makes your life easier (even though it’s complex).
The Problem Kubernetes Solves
Imagine you have an app that needs to handle variable traffic. During the day, 1,000 requests per second. At night, 50. Without Kubernetes:
- You run 20 servers 24/7 to handle peak traffic (expensive)
- When one server fails, someone has to manually restart it
- Deploying a new version means stopping old containers and starting new ones (downtime)
- You manually configure networking between servers (fragile)
With Kubernetes:
- You say “I want 5 instances of my app running at all times”
- Kubernetes starts 5 containers, distributes them across servers, monitors them
- If one fails, Kubernetes automatically starts a replacement
- If traffic spikes, Kubernetes starts more instances automatically
- If traffic drops, Kubernetes shuts down excess instances (saves money)
- To deploy, you push a new image; Kubernetes replaces old containers with new ones (zero downtime)
That’s powerful. But the operational cost is also high.
When Kubernetes Makes Sense
You should consider Kubernetes when:
- You have high traffic. If you’re running 10+ servers, Kubernetes saves operational burden. If you’re running 2 servers, it’s not worth it.
- You have multiple services. Monoliths are simpler on traditional servers. Microservices benefit from Kubernetes’s networking and orchestration.
- You’re cloud-native. If you’re on AWS, GCP, or Azure, they have Kubernetes services (EKS, GKE, AKS) that handle much of the operational burden.
- You need autoscaling. If traffic is unpredictable and you want to scale automatically based on load, Kubernetes excels.
- You need high availability. If your uptime is critical (financial systems, healthcare), Kubernetes’s automatic recovery is valuable.
You should NOT use Kubernetes when:
- You have a monolith running on 1-3 servers. Keep it simple. Use traditional servers or managed platforms.
- Your team is small. Kubernetes adds operational complexity. If you’re a team of 5, you probably don’t have 2 people to dedicate to Kubernetes.
- You’re moving fast and experimenting. Kubernetes adds friction. You want to iterate quickly, not manage clusters.
- You don’t have budget for DevOps infrastructure. Kubernetes requires server costs plus operational cost. A managed platform (Heroku, Railway) might be cheaper overall.
The honest assessment: most startups shouldn’t run Kubernetes. They should use Heroku, Railway, Render, or Fly.io until they’re big enough to justify the operational cost.
Kubernetes Basics: Concepts You Need to Know
If you do decide to use Kubernetes, here are the core concepts:
Pods
A Pod is the smallest unit. It’s usually one container (but can be multiple). Pods are ephemeral—they can be created and destroyed at any time.
You don’t create Pods directly. You create Deployments that manage Pods.
Deployments
A Deployment describes how many Pods you want running, which image to use, and how to update them.
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app-deployment
spec:
replicas: 3 # Run 3 Pods
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: my-app
image: myusername/my-app:1.0
ports:
- containerPort: 3000
env:
- name: DATABASE_URL
value: "postgres://db:5432"