Do you need Kubernetes? A decision guide
Respuesta rápida
Not automatically. Kubernetes earns its complexity when you need auto-scaling, rolling updates, self-healing and service discovery across a real number of moving parts, roughly the point where you're managing 20 or more containers. Below that, docker-compose on one or two VPS or dedicated instances is often genuinely enough. Add Kubernetes when you feel the specific pain it solves, not by default.
Start from "no", and let the workload argue you out of it
It's tempting to reach for Kubernetes because it's the default answer in a lot of tutorials and job listings. In practice, for a small stack, running docker-compose on one or two VMs works well. The point to add Kubernetes is when you need automated scaling, self-healing, and standardised rollouts, not before.
That's a deliberately conservative starting position. Kubernetes doesn't do anything for a workload that a well-configured VPS or dedicated server with docker-compose can't already do at small scale. What it adds is a control plane that manages scheduling, restarts, and rollout coordination for you, once the number of moving pieces makes doing that by hand painful.
What Kubernetes actually buys you
Kubernetes can help with scheduling and isolation, but it adds complexity. If your team isn't fluent in day-to-day k8s operations, keeping the platform simpler and more predictable is usually the better trade.
The features that make the added complexity worth it tend to show up together, not one at a time:
- Auto-scaling, adding or removing capacity based on load without someone watching a dashboard.
- Rolling updates, deploying new versions without a hard cutover or downtime window.
- Service discovery, services finding each other by name as instances come and go.
- Self-healing, failed containers get rescheduled automatically rather than paged about at 3am.
When you need those together, and you're running enough services (a rough rule of thumb is 20 or more containers) that manual coordination has become the bottleneck, that's when container orchestration is worth reaching for. For smaller deployments, docker-compose is often sufficient.
The overhead you're signing up for
Kubernetes isn't free even before your workloads start. A cluster's control plane needs roughly 2 to 4GB of RAM per master node, plus 100 to 300MB per worker node for system pods (kube-proxy, CNI agents, and the rest). As a planning rule, budget around 20% extra capacity for the platform itself, etcd, control plane, and system pods, on top of whatever your applications need. That's capacity you're paying for and operating, not capacity your application gets to use.
There's an operational cost too, separate from the resource cost: someone on your team needs to understand upgrades, node draining, RBAC, and the failure modes of a distributed scheduler. That skill requirement doesn't show up on an invoice, but it's real, and it's the main reason "do I need Kubernetes?" is worth asking honestly instead of assuming yes.
A simple checklist
| Signal | Simpler footprint is probably right | Kubernetes is probably worth it |
|---|---|---|
| Number of services | A handful, running on one or two hosts | Enough that manual restarts and rollouts are a bottleneck |
| Deployment pattern | Occasional releases, some downtime is acceptable | Frequent releases, rolling updates matter |
| Scaling needs | Fixed or manually adjusted capacity is fine | Load varies enough that automated scaling pays for itself |
| Team's k8s fluency | Limited, nobody owns cluster operations | Someone can own upgrades, RBAC, and incident response |
| State | Databases and other stateful services dominate the stack | Mostly stateless services, with state handled deliberately |
If you land mostly in the left column, docker-compose on Flexible VPS or a dedicated server is a reasonable, boring choice, and boring is usually what you want in production. If you land mostly in the right column, see Sizing a Kubernetes cluster for high availability for what a minimum viable cluster looks like.