This content originally appeared on DEV Community and was authored by tracywhodoesnot
Why We Don’t Need Kubernetes for Services That Only Require a Couple of Servers
In the world of modern software infrastructure, Kubernetes has become synonymous with "scalable, production-grade deployment." It’s often seen as the gold standard for orchestrating containerized applications. However, for many teams and applications—especially those that only need a couple of servers—adopting Kubernetes can be overkill. It often introduces unnecessary complexity, operational overhead, and cost without delivering proportional benefits.
This post dives deep into the granular reasons why Kubernetes is not just unnecessary but often counterproductive for small-scale services, and why simpler, more direct approaches are not only sufficient but usually superior.
1. Kubernetes Scales Complexity, Not Just Infrastructure
Kubernetes was designed to solve problems at scale—orchestrating hundreds or thousands of containers across dozens of nodes, handling rolling updates, self-healing, service discovery, and load balancing in dynamic, large-scale environments.
But if you're running just 2–4 servers, you're not facing those challenges. The complexity of Kubernetes doesn’t scale down gracefully. Instead, it brings:
- A control plane (API server, etcd, scheduler, controller manager) that requires at least 3–5 nodes to be highly available.
- Networking overhead (CNI plugins, service meshes, ingress controllers).
- Persistent storage abstractions (PVs, PVCs, storage classes).
- RBAC, service accounts, and security policies.
- Monitoring and logging stacks just to keep the cluster itself alive.
All of this infrastructure is needed even if your actual application workload is trivial—say, a web API and a database.
Granular Example:
Running a simple Flask app with PostgreSQL on two servers? With Kubernetes, you’d need at a minimum:
- 3 control plane nodes (for HA).
- 2 worker nodes (your original servers, now just part of a larger cluster).
- A CNI like Calico or Flannel.
- An ingress controller (e.g., Nginx Ingress).
- A load balancer (either cloud-based or MetalLB).
- Persistent volumes for the database.
- Helm or Kustomize to manage deployments.
Suddenly, your two-server app requires five or more servers and a team to maintain them. That’s not scaling efficiently.
2. Operational Overhead Outweighs Benefits
Kubernetes demands deep expertise. You’re not just deploying an app—you’re managing a distributed system. This means:
- Cluster upgrades must be carefully orchestrated.
- Node failures require understanding of kubelet, taints, tolerations, and node lifecycle.
- Networking issues are more complicated to debug due to overlay networks and iptables rules.
- Security updates must be applied at both the node OS and Kubernetes component levels.
- Monitoring requires Prometheus, Grafana, Loki, and custom dashboards just to observe cluster health.
For a small team or solo developer, this is a massive distraction from building actual product value.
Granular Example:
A single server outage in a non-Kubernetes setup might mean restarting a service or failover to a backup. In Kubernetes, the same outage could trigger pod evictions, rescheduling delays, persistent volume detachment issues, and cascading failures if the control plane is co-located.
The time to recovery (MTTR) can be longer in Kubernetes for small setups due to the layers of abstraction.
3. Cost Multiplier Without ROI
Kubernetes clusters consume significant resources just to run the control plane and system components. On small servers (e.g., 4GB RAM, two vCPUs), you might lose 1–2GB of RAM and 0.5+ vCPU to kube-system pods.
Granular Cost Breakdown (using AWS as an example):
- 3x t3.medium control plane nodes: $70/month
- 2x t3.medium worker nodes: $50/month
- Load balancer: $20/month
- Monitoring/logging: $30/month
- Total: ~$170/month
Compare that to:
- 2x t3.large (8GB RAM, two vCPUs) running Docker + app + DB: $100/month
- Plus a simple load balancer: $20/month
- Total: $120/month
And the non-Kubernetes setup is easier to manage, debug, and secure.
Even on-prem, the electricity, cooling, and maintenance for extra hardware add up. For a small service, that $50–$100/month difference is meaningful.
4. Deployment Simplicity Is Lost
With Kubernetes, deploying a change involves:
- Building a Docker image.
- Pushing to a registry.
- Updating a YAML manifest or Helm chart.
- Applying via
kubectl. - Waiting for rollout, checking events, logs, etc.
With a simple server setup, you can:
- Use
rsyncorscpto copy new code. - Run a script to restart the service.
- Or use a lightweight CI/CD pipeline with SSH and systemd.
Granular Example:
Updating an API endpoint:
-
Non-Kubernetes:
git pull && systemctl restart myapp— done in 10 seconds. -
Kubernetes:
docker build,docker push,helm upgrade,kubectl rollout status— 2+ minutes, assuming no image pull errors or config drift.
The feedback loop is slower, and the tooling is heavier.
5. Resilience ≠ Kubernetes
A common argument for Kubernetes is "self-healing" and "high availability." But for a 2-server setup, true high availability is often better achieved with simpler tools:
- Keepalived + HAProxy for failover and load balancing.
- Pacemaker/Corosync for cluster management.
-
Docker Compose with restart policies (
restart: unless-stopped). - Systemd to restart services on crash.
- Backups and monitoring (e.g., Prometheus Node Exporter, Alertmanager).
These tools are battle-tested, lightweight, and don’t require a PhD to operate.
Granular Example:
If your web server crashes:
- On systemd: it restarts in seconds.
- On Kubernetes: kubelet detects it, schedules a new pod, waits for image pull, mounts volumes, passes readiness probe — could take 30+ seconds.
For many applications, that extra latency isn’t worth the abstraction.
6. Security Surface Area Increases
Kubernetes adds dozens of new attack surfaces:
- The kube-apiserver (exposed or not).
- etcd (stores all cluster state).
- kubelet on every node.
- Ingress controllers with misconfigurable rules.
- Service accounts with excessive permissions.
Each component must be hardened, patched, and monitored. A single misconfiguration (e.g., overly permissive RBAC) can lead to full cluster compromise.
In contrast, a minimal server setup with:
- SSH key authentication
- Uncomplicated firewall (UFW/iptables)
- Regular OS updates
- Application-level logging
It is far easier to secure and audit.
7. Better Alternatives Exist for Small Scales
For 1–4 servers, consider:
- Docker Compose + Traefik/Nginx: Run multiple services with networking and TLS.
- Nomad by HashiCorp: Lightweight scheduler, simpler than Kubernetes, supports containers and binaries.
- Systemd + Supervisord: For long-running processes.
- Fly.io, Render, or DigitalOcean App Platform: Managed platforms that give you Kubernetes-like benefits (scaling, CI/CD, HTTPS) without the ops burden.
- Traditional VMs with Ansible/Puppet: Predictable, version-controlled, and easy to replicate.
These tools are proportionate to the problem size.
8. Team Size and Skill Mismatch
If you’re a startup with two engineers or a solo founder, spending 20% of your time on Kubernetes upkeep is unsustainable. You need to ship features, not debug CrashLoopBackOff.
Kubernetes is a team-scale solution. It assumes:
- Dedicated DevOps/SRE resources.
- CI/CD pipelines.
- Incident response processes.
- Budget for training and tooling.
Without those, it becomes a liability.
Conclusion: Use the Right Tool for the Job
Kubernetes is a powerful tool for managing hundreds of microservices across dozens of teams and regions. But for a couple of servers running a monolith, API, or internal tool? It’s like using a nuclear reactor to power a flashlight.
You don’t need Kubernetes if:
- You have fewer than five servers.
- Your team is small (<5 engineers).
- Your app isn’t mission-critical with strict SLAs.
- You value simplicity, speed, and low cost over "enterprise readiness."
Instead, embrace simplicity:
- Use proven, lightweight tools.
- Automate deployments with scripts or simple CI.
- Monitor what matters.
- Scale only when you need to.
Remember: The best infrastructure is the one you don’t have to think about. For small services, that’s rarely Kubernetes.
TL;DR: Kubernetes adds massive complexity, cost, and operational burden for minimal benefit at a small scale. Simpler solutions like Docker Compose, systemd, or managed platforms are faster, cheaper, and more reliable for services running on a couple of servers. Save Kubernetes for when you need it—when your infrastructure problems are truly large-scale.
This content originally appeared on DEV Community and was authored by tracywhodoesnot
tracywhodoesnot | Sciencx (2025-08-07T17:00:00+00:00) Why We Don’t Need Kubernetes for Services That Only Require a Couple of Servers. Retrieved from https://www.scien.cx/2025/08/07/why-we-dont-need-kubernetes-for-services-that-only-require-a-couple-of-servers/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.