Architecture slide shows Kubernetes: pods, ingress, Helm charts. Team has three developers, one VPS, two Docker containers, weekly deploy. Six months later, half the sprint goes to "cluster NotReady." Nobody talks product features anymore.
This scenario is not rare — it is the norm when Kubernetes is adopted by natural gravity after Docker, without objective criteria. Kubernetes is not the default next step. It is an orchestration platform for orgs that saturated simpler options — and can pay the operations tax.
Signals K8s can defend itself
Check several boxes, not one:
- 5–10+ stateless services deployed independently, multiple times daily.
- Horizontal autoscaling beyond one big VPS.
- Multi-AZ with healthchecks and strict rolling updates.
- Platform or SRE team — even part-time — or explicit managed operations contract.
- Stateful operators mastered or 100% managed databases off cluster.
| Situation | Kubernetes | Simpler |
|---|---|---|
| 1 monolith app | Oversized | VPS + Docker |
| Predictable spike | Possible | Temporary vertical scale |
| 20 microservices | Relevant | Hard without K8s |
| Team without operations | Risky | PaaS |
| Zero operations budget | No | Shared / VPS |
Adopting K8s for architect CV, not client need, is failure cause #1.
Hidden cost: human time
The infrastructure invoice is only the visible part. Training or hiring someone able to operate the cluster. Observability — metrics, logs, traces — without which you navigate blind. Friday night incidents when a node refuses to join. Unmaintained Helm chart debt blocking version upgrades.
€150/month managed cluster plus two operations days/month often beats €300 PaaS all-in for the same app — with less operational risk.
Alternatives before Kubernetes
VPS + Docker + CI — until machine saturated or HA required. This is the most common and most underestimated path.
PaaS — git deploy, built-in scaling, no nodes to patch. Ideal if nobody internally wants to learn kubectl.
Docker Swarm / Nomad — lighter; tiny team multi-container without Kubernetes control plane complexity.
Serverless — event workloads — see serverless use cases.
Compare via the comparator including operations hours, not infra invoice alone.
The peak: cluster amplifies your architecture
Decide and move forward without blind spots
List service count, deploy frequency and high availability requirements before ordering any cluster. Estimate operations hours/month without versus with Kubernetes — include training and incidents. Try PaaS or VPS Docker for six months if doubt persists. Adopt K8s only when several strong signals coexist with available skills. Read Docker beginner and PaaS or server before ordering a cluster.
Frequently asked questions
Does traffic alone justify K8s?
No. Request volume does not decide — count services, deploy frequency, need for complex horizontal autoscaling and presence of a team able to operate the cluster. A high-traffic monolith often scales vertically or behind a CDN far more simply.
Managed K8s without internal skills?
Managed control plane lightens part of the load — not all operations. Ingress, storage classes, observability, node upgrades and pod debugging stay on you. Without internal skills, budget support or an explicit managed services contract.
Compose then K8s?
A common healthy path: containerized app, Compose on single-node production, Kubernetes when one machine no longer suffices or multi-AZ HA with several stateless replicas becomes a contractual requirement.
European alternative?
PaaS, VPS with Docker, or managed Kubernetes at OVHcloud, Scaleway or Infomaniak — compare total cost including operations time in our directory, not just the monthly cluster invoice.
Kubernetes when your problem is coordination at scale — not when your problem is "install Docker on a VPS."